r275949 - [driver][mips] Support MIPS targets in modern Android NDK

[Simon Atanasyan via cfe-commits]

Author: atanasyan
Date: Tue Jul 19 02:09:48 2016
New Revision: 275949

URL: http://llvm.org/viewvc/llvm-project?rev=275949&view=rev
Log:
[driver][mips] Support MIPS targets in modern Android NDK

Initial patch provided by Duane Sand.

Added:

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/32/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/32/mips-r1/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/32/mips-r1/crtbegin.o
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtbegin.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/32/mips-r1/crtend.o
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtend.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/32/mips-r2/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/32/mips-r2/crtbegin.o
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtendS.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/32/mips-r2/crtend.o
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtend.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/32/mips-r6/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/32/mips-r6/crtbegin.o
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtbeginT.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/32/mips-r6/crtend.o
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtend.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/crtbegin.o
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtbeginS.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/crtend.o
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtend.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/include/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/lib/gcc/mips64el-linux-android/4.9/include/.keep
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtendS.o
cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mips64el-linux-android/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mips64el-linux-android/bin/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mips64el-linux-android/bin/.keep
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtendS.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mips64el-linux-android/lib/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mips64el-linux-android/lib/.keep
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtendS.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mips64el-linux-android/lib64/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mips64el-linux-android/lib64/.keep
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtendS.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mips64el-linux-android/libr2/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mips64el-linux-android/libr2/.keep
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtendS.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mips64el-linux-android/libr6/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mips64el-linux-android/libr6/.keep
  - copied, changed from r275947, 
cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/crtendS.o

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mipsel-linux-android/libr2/

cfe/trunk/test/Driver/Inputs/basic_android_ndk_tree/mipsel-l

r275951 - [driver][mips] Remove empty folder from test inputs

[Simon Atanasyan via cfe-commits]

Author: atanasyan
Date: Tue Jul 19 02:23:15 2016
New Revision: 275951

URL: http://llvm.org/viewvc/llvm-project?rev=275951&view=rev
Log:
[driver][mips] Remove empty folder from test inputs

Removed:

cfe/trunk/test/Driver/Inputs/basic_android_tree/lib/gcc/mipsel-linux-android/4.4.3/mips-r6/

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

Re: [PATCH] D22408: [clang-rename] add support for overridden functions

[Manuel Klimek via cfe-commits]

klimek accepted this revision.
klimek added a comment.
This revision is now accepted and ready to land.

lg


https://reviews.llvm.org/D22408



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

Re: [PATCH] D22408: [clang-rename] add support for overridden functions

[Kirill Bobyrev via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL275958: [clang-rename] add support for overridden functions 
(authored by omtcyfz).

Changed prior to commit:
  https://reviews.llvm.org/D22408?vs=64293&id=64453#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22408

Files:
  clang-tools-extra/trunk/clang-rename/USRFindingAction.cpp

Index: clang-tools-extra/trunk/clang-rename/USRFindingAction.cpp
===
--- clang-tools-extra/trunk/clang-rename/USRFindingAction.cpp
+++ clang-tools-extra/trunk/clang-rename/USRFindingAction.cpp
@@ -8,64 +8,128 @@
 //===--===//
 ///
 /// \file
-/// \brief Provides an action to rename every symbol at a point.
+/// \brief Provides an action to find USR for the symbol at , as well as
+/// all additional USRs.
 ///
 //===--===//
 
 #include "USRFindingAction.h"
 #include "USRFinder.h"
 #include "clang/AST/AST.h"
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Basic/FileManager.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/FrontendAction.h"
 #include "clang/Lex/Lexer.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "clang/Tooling/Refactoring.h"
 #include "clang/Tooling/Tooling.h"
+#include 
 #include 
+#include 
 #include 
 
+
 using namespace llvm;
+using namespace clang::ast_matchers;
 
 namespace clang {
 namespace rename {
 
-// Get the USRs for the constructors of the class.
-static std::vector getAllConstructorUSRs(
-const CXXRecordDecl *Decl) {
-  std::vector USRs;
-
-  // We need to get the definition of the record (as opposed to any forward
-  // declarations) in order to find the constructor and destructor.
-  const auto *RecordDecl = Decl->getDefinition();
-
-  // Iterate over all the constructors and add their USRs.
-  for (const auto *CtorDecl : RecordDecl->ctors())
-USRs.push_back(getUSRForDecl(CtorDecl));
-
-  // Ignore destructors. GetLocationsOfUSR will find the declaration of and
-  // explicit calls to a destructor through TagTypeLoc (and it is better for the
-  // purpose of renaming).
-  //
-  // For example, in the following code segment,
-  //  1  class C {
-  //  2~C();
-  //  3  };
-  // At line 3, there is a NamedDecl starting from '~' and a TagTypeLoc starting
-  // from 'C'.
+namespace {
+// \brief NamedDeclFindingConsumer should delegate finding USRs of given Decl to
+// AdditionalUSRFinder. AdditionalUSRFinder adds USRs of ctor and dtor if given
+// Decl refers to class and adds USRs of all overridden methods if Decl refers
+// to virtual method.
+//
+// FIXME: It's better to match ctors/dtors via typeLoc's instead of adding
+// their USRs to the storage, because we can also match CXXConversionDecl's by
+// typeLoc and we won't have to "manually" handle them here.
+class AdditionalUSRFinder : public MatchFinder::MatchCallback {
+public:
+  explicit AdditionalUSRFinder(const Decl *FoundDecl, ASTContext &Context,
+ std::vector *USRs)
+: FoundDecl(FoundDecl), Context(Context), USRs(USRs), USRSet(), Finder() {}
+
+  void Find() {
+USRSet.insert(getUSRForDecl(FoundDecl));
+addUSRsFromOverrideSetsAndCtorDtors();
+addMatchers();
+Finder.matchAST(Context);
+USRs->insert(USRs->end(), USRSet.begin(), USRSet.end());
+  }
 
-  return USRs;
-}
+private:
+  void addMatchers() {
+const auto CXXMethodDeclMatcher =
+cxxMethodDecl(isVirtual()).bind("cxxMethodDecl");
+Finder.addMatcher(CXXMethodDeclMatcher, this);
+  }
+
+  // FIXME: Implement hasOverriddenMethod and matchesUSR matchers to make
+  // lookups more efficient.
+  virtual void run(const MatchFinder::MatchResult &Result) {
+const auto *VirtualMethod =
+Result.Nodes.getNodeAs("cxxMethodDecl");
+bool Found = false;
+for (const auto &OverriddenMethod : VirtualMethod->overridden_methods()) {
+  if (USRSet.find(getUSRForDecl(OverriddenMethod)) != USRSet.end()) {
+Found = true;
+  }
+}
+if (Found) {
+  USRSet.insert(getUSRForDecl(VirtualMethod));
+}
+  }
+
+  void addUSRsFromOverrideSetsAndCtorDtors() {
+// If D is CXXRecordDecl we should add all USRs of its constructors.
+if (const auto *RecordDecl = dyn_cast(FoundDecl)) {
+  // Ignore destructors. Find the declaration of and explicit calls to a
+  // destructor through TagTypeLoc (and it is better for the purpose of
+  // renaming).
+  //
+  // For example, in the following code segment,
+  //  1  class C {
+  //  2~C();
+  //  3  };
+  //
+  // At line 3, there is a NamedDecl starting from '~' and a TagType

[clang-tools-extra] r275958 - [clang-rename] add support for overridden functions

[Kirill Bobyrev via cfe-commits]

Author: omtcyfz
Date: Tue Jul 19 02:37:43 2016
New Revision: 275958

URL: http://llvm.org/viewvc/llvm-project?rev=275958&view=rev
Log:
[clang-rename] add support for overridden functions

Reviewers: klimek

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

Modified:
clang-tools-extra/trunk/clang-rename/USRFindingAction.cpp

Modified: clang-tools-extra/trunk/clang-rename/USRFindingAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-rename/USRFindingAction.cpp?rev=275958&r1=275957&r2=275958&view=diff
==
--- clang-tools-extra/trunk/clang-rename/USRFindingAction.cpp (original)
+++ clang-tools-extra/trunk/clang-rename/USRFindingAction.cpp Tue Jul 19 
02:37:43 2016
@@ -8,7 +8,8 @@
 
//===--===//
 ///
 /// \file
-/// \brief Provides an action to rename every symbol at a point.
+/// \brief Provides an action to find USR for the symbol at , as well 
as
+/// all additional USRs.
 ///
 
//===--===//
 
@@ -17,6 +18,9 @@
 #include "clang/AST/AST.h"
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Basic/FileManager.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/FrontendAction.h"
@@ -25,47 +29,107 @@
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "clang/Tooling/Refactoring.h"
 #include "clang/Tooling/Tooling.h"
+#include 
 #include 
+#include 
 #include 
 
+
 using namespace llvm;
+using namespace clang::ast_matchers;
 
 namespace clang {
 namespace rename {
 
-// Get the USRs for the constructors of the class.
-static std::vector getAllConstructorUSRs(
-const CXXRecordDecl *Decl) {
-  std::vector USRs;
-
-  // We need to get the definition of the record (as opposed to any forward
-  // declarations) in order to find the constructor and destructor.
-  const auto *RecordDecl = Decl->getDefinition();
-
-  // Iterate over all the constructors and add their USRs.
-  for (const auto *CtorDecl : RecordDecl->ctors())
-USRs.push_back(getUSRForDecl(CtorDecl));
-
-  // Ignore destructors. GetLocationsOfUSR will find the declaration of and
-  // explicit calls to a destructor through TagTypeLoc (and it is better for 
the
-  // purpose of renaming).
-  //
-  // For example, in the following code segment,
-  //  1  class C {
-  //  2~C();
-  //  3  };
-  // At line 3, there is a NamedDecl starting from '~' and a TagTypeLoc 
starting
-  // from 'C'.
+namespace {
+// \brief NamedDeclFindingConsumer should delegate finding USRs of given Decl 
to
+// AdditionalUSRFinder. AdditionalUSRFinder adds USRs of ctor and dtor if given
+// Decl refers to class and adds USRs of all overridden methods if Decl refers
+// to virtual method.
+//
+// FIXME: It's better to match ctors/dtors via typeLoc's instead of adding
+// their USRs to the storage, because we can also match CXXConversionDecl's by
+// typeLoc and we won't have to "manually" handle them here.
+class AdditionalUSRFinder : public MatchFinder::MatchCallback {
+public:
+  explicit AdditionalUSRFinder(const Decl *FoundDecl, ASTContext &Context,
+ std::vector *USRs)
+: FoundDecl(FoundDecl), Context(Context), USRs(USRs), USRSet(), Finder() {}
+
+  void Find() {
+USRSet.insert(getUSRForDecl(FoundDecl));
+addUSRsFromOverrideSetsAndCtorDtors();
+addMatchers();
+Finder.matchAST(Context);
+USRs->insert(USRs->end(), USRSet.begin(), USRSet.end());
+  }
+
+private:
+  void addMatchers() {
+const auto CXXMethodDeclMatcher =
+cxxMethodDecl(isVirtual()).bind("cxxMethodDecl");
+Finder.addMatcher(CXXMethodDeclMatcher, this);
+  }
+
+  // FIXME: Implement hasOverriddenMethod and matchesUSR matchers to make
+  // lookups more efficient.
+  virtual void run(const MatchFinder::MatchResult &Result) {
+const auto *VirtualMethod =
+Result.Nodes.getNodeAs("cxxMethodDecl");
+bool Found = false;
+for (const auto &OverriddenMethod : VirtualMethod->overridden_methods()) {
+  if (USRSet.find(getUSRForDecl(OverriddenMethod)) != USRSet.end()) {
+Found = true;
+  }
+}
+if (Found) {
+  USRSet.insert(getUSRForDecl(VirtualMethod));
+}
+  }
+
+  void addUSRsFromOverrideSetsAndCtorDtors() {
+// If D is CXXRecordDecl we should add all USRs of its constructors.
+if (const auto *RecordDecl = dyn_cast(FoundDecl)) {
+  // Ignore destructors. Find the declaration of and explicit calls to a
+  // destructor through TagTypeLoc (and it is better for the purpose of
+  // renaming).
+  //
+  // For example, in the following code segment,
+  //  1  class C {
+  //  2~C();
+  //  3  };
+  //
+  // At line 3, there i

Re: [PATCH] D22465: [clang-rename] introduce better symbol finding and add few more tests

[Kirill Bobyrev via cfe-commits]

omtcyfz updated this revision to Diff 64454.
omtcyfz added a comment.

applied few stylistic fixes


https://reviews.llvm.org/D22465

Files:
  clang-rename/RenamingAction.cpp
  clang-rename/USRFinder.cpp
  clang-rename/USRLocFinder.cpp
  test/clang-rename/ClassNameInFunctionDefenition.cpp
  test/clang-rename/ComplicatedClassType.cpp
  test/clang-rename/ComplicatedClassTypeInCustomNamespace.cpp
  test/clang-rename/NestedNamespace.cpp
  test/clang-rename/TemplateTypename.cpp
  test/clang-rename/UserDefinedConversion.cpp
  test/clang-rename/UserDefinedConversionFindByConversion.cpp
  test/clang-rename/UserDefinedConversionFindByTypeDeclaration.cpp

Index: test/clang-rename/UserDefinedConversionFindByTypeDeclaration.cpp
===
--- test/clang-rename/UserDefinedConversionFindByTypeDeclaration.cpp
+++ test/clang-rename/UserDefinedConversionFindByTypeDeclaration.cpp
@@ -1,7 +1,6 @@
-// Currently unsupported test.
 // RUN: cat %s > %t.cpp
-// FIXME: while renaming class/struct clang-rename should be able to change
-// this type name corresponding user-defined conversions, too.
+// RUN: clang-rename -offset=136 -new-name=Bar %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
 
 class Foo { // CHECK: class Bar {
 //^ offset must be here
Index: test/clang-rename/UserDefinedConversionFindByConversion.cpp
===
--- test/clang-rename/UserDefinedConversionFindByConversion.cpp
+++ test/clang-rename/UserDefinedConversionFindByConversion.cpp
@@ -1,11 +1,10 @@
-// Currently unsupported test.
 // RUN: cat %s > %t.cpp
-// FIXME: clang-rename should handle conversions from a class type to another
-// type.
+// RUN: clang-rename -offset=136 -new-name=Bar %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
 
 class Foo {}; // CHECK: class Bar {};
 
-class Baz {   // CHECK: class Bar {
+class Baz {
   operator Foo() const {  // CHECK: operator Bar() const {
 Foo foo;  // CHECK: Bar foo;
 return foo;
Index: test/clang-rename/TemplateTypename.cpp
===
--- test/clang-rename/TemplateTypename.cpp
+++ test/clang-rename/TemplateTypename.cpp
@@ -1,12 +1,20 @@
-// Currently unsupported test.
 // RUN: cat %s > %t.cpp
+// RUN: clang-rename -offset=270 -new-name=U %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
+
+// Currently unsupported test.
 // FIXME: clang-rename should be able to rename template parameters correctly.
+// XFAIL: *
 
-template 
-T foo(T arg, T& ref, T* ptr) {
-  T value;
+template  // CHECK: template 
+class Foo {
+T foo(T arg, T& ref, T* ptr) {// CHECK: U foo(U arg, U& ref, U* ptr) {
+  T value;// CHECK: U value;
   int number = 42;
-  value = (T)number;
-  value = static_cast(number);
+  value = (T)number;  // CHECK: value = (U)number;
+  value = static_cast(number); // CHECK: value = static_cast(number);
   return value;
 }
+
+T member; // CHECK: U member;
+};
Index: test/clang-rename/NestedNamespace.cpp
===
--- /dev/null
+++ test/clang-rename/NestedNamespace.cpp
@@ -0,0 +1,42 @@
+// RUN: cat %s > %t.cpp
+// RUN: clang-rename -offset=274 -new-name=Bar %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
+
+// Currently unsupported test.
+// FIXME: Teach clang-rename to rename namespace in nested constructions.
+// XFAIL: *
+
+namespace Baz {
+namespace Foo { // CHECK: namespace Bar {
+class A {
+public:
+  static int aFunction() { return 0; }
+};
+int FooFunction() { return 0; }
+namespace Qux {
+class B {
+public:
+  static int bFunction() { return 0; }
+};
+int QuxFunction() { return 0; }
+} // namespace Qux
+} // namespace Foo
+} // namespace Baz
+
+int main() {
+
+  // Variable type tests.
+  Baz::Foo::A a;  // CHECK: Baz::Bar::A a;
+  Baz::Foo::Qux::B b; // CHECK: Baz::Bar::Qux::B b;
+  unsigned i = 42;
+  for (Baz::Foo::A c; i < 100; i++);  // CHECK: for (Baz::Bar::A c; i < 100; i++);
+  for (Baz::Foo::Qux::B d; i < 200; i++); // CHECK: for (Baz::Bar::Qux::B d; i < 200; i++);
+
+  // Function tests.
+  int x = Baz::Foo::A::aFunction();   // CHECK: int x = Baz::Bar::A::aFunction();
+  x = Baz::Foo::FooFunction();// CHECK: x = Baz::Bar::FooFunction();
+  x = Baz::Foo::Qux::B::bFunction();  // CHECK: x = Baz::Bar::Qux::B::bFunction();
+  x = Baz::Foo::Qux::QuxFunction();   // CHECK: x = Baz::Bar::Qux::QuxFunction();
+
+  return 0;
+}
Index: test/clang-rename/ComplicatedClassTypeInCustomNamespace.cpp
===
--- /dev/null
+++ test/clang-rename/ComplicatedClassTypeInCustomNamespace.cpp
@@ -0,0 +1,37 @@
+// RUN: cat %s > %t.cpp
+// RUN: clang-re

Re: [PATCH] D19311: [analyzer] Self Assignment Checker

[Balogh , Ádám via cfe-commits]

baloghadamsoftware added a comment.

Do I use an non-portable way to concatenate strings? "Assuming rhs == *this" 
becomes "0*this" for some strange reason. I tested it again with the latest 
master branch and all tests are passing like earlier.


Repository:
  rL LLVM

https://reviews.llvm.org/D19311



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

Re: [PATCH] D21970: Add attribute abi_tag to the release notes

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin added a comment.

Hi Hans, it seems that you've just created release branch for 3.9 and this 
patch should go directly to the branch, right? If so could you please commit 
this patch for me because I'm working with git-svn and there is no instruction 
how to work with release LLVM branches from git so I'm worry that my setup 
could break things. I'm absolutely fine with moving abi_tag above --build-id. 
Thanks!


https://reviews.llvm.org/D21970



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

Re: [PATCH] D22034: [MSVC][DLL] use local vftable mangling only exported classes with virtual destructor

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin added inline comments.


Comment at: test/CodeGenCXX/dllimport-rtti.cpp:7
@@ -6,3 +6,1 @@
 } s;
-// MSVC: [[VF_S:.*]] = private unnamed_addr constant [2 x i8*]
-// MSVC-DAG: @"\01??_SS@@6B@" = unnamed_addr alias i8*, getelementptr inbounds 
([2 x i8*], [2 x i8*]* [[VF_S]], i32 0, i32 1)

rnk wrote:
> I would've expected this to remain the same, since the implicit default ctor 
> of 'S' is constexpr by default in C++14. It seems a lot better to emit a 
> local vftable here and get static initialization for 's' than dynamic 
> initialization.
The context of evaluation of the whole expression is not constexpr so this case 
can be done both ways. But implemented approach is how MSVC behaves in this 
case. MSVC has very predictable behavior when local vftable is used - only when 
class has virtual d-tor. Current Clang behavior is also very consistent - 
always use local vftable. But this patch makes it hard to predict which table 
will be used - it becomes use context sensitive instead of depending only on 
class declaration. Therefore different translation units could use different 
tables and it could cause strange artifacts. Using dllimported classes in pure 
constexpr case in my experience is very rare case so it was kind of fine but 
implicit constructors much more common case.

Also thinking more about my patch I realized that fix in MayBeEmittedEagerly 
doesn't work if dllimported class is a member of non-imported class so actual 
fix would require traversing for all base classes and members for the type.

So my proposal is to keep things as is for now and abandon this patch if you 
have no objection.


https://reviews.llvm.org/D22034



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

Re: [PATCH] D21228: Deprecated (legacy) string literal conversion to 'char *' causes strange overloading resolution

[Alexander Makarov via cfe-commits]

a.makarov added a comment.

Richard, thank you very much! =)


https://reviews.llvm.org/D21228



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

r275967 - [mips] Correct label prefixes for N32 and N64.

[Daniel Sanders via cfe-commits]

Author: dsanders
Date: Tue Jul 19 05:49:03 2016
New Revision: 275967

URL: http://llvm.org/viewvc/llvm-project?rev=275967&view=rev
Log:
[mips] Correct label prefixes for N32 and N64.

Summary:
N32 and N64 follow the standard ELF conventions (.L) whereas O32 uses its own
($).

This fixes the majority of object differences between -fintegrated-as and
-fno-integrated-as.

Reviewers: sdardis

Subscribers: dsanders, sdardis, llvm-commits

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


Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/CodeGen/target-data.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=275967&r1=275966&r2=275967&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Tue Jul 19 05:49:03 2016
@@ -7105,9 +7105,9 @@ class MipsTargetInfo : public TargetInfo
 if (ABI == "o32")
   Layout = "m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32-S64";
 else if (ABI == "n32")
-  Layout = "m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32:64-S128";
+  Layout = "m:e-p:32:32-i8:8:32-i16:16:32-i64:64-n32:64-S128";
 else if (ABI == "n64")
-  Layout = "m:m-i8:8:32-i16:16:32-i64:64-n32:64-S128";
+  Layout = "m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128";
 else
   llvm_unreachable("Invalid ABI");
 

Modified: cfe/trunk/test/CodeGen/target-data.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/target-data.c?rev=275967&r1=275966&r2=275967&view=diff
==
--- cfe/trunk/test/CodeGen/target-data.c (original)
+++ cfe/trunk/test/CodeGen/target-data.c Tue Jul 19 05:49:03 2016
@@ -40,19 +40,19 @@
 
 // RUN: %clang_cc1 -triple mips64el-linux-gnu -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=MIPS-64EL
-// MIPS-64EL: target datalayout = "e-m:m-i8:8:32-i16:16:32-i64:64-n32:64-S128"
+// MIPS-64EL: target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128"
 
 // RUN: %clang_cc1 -triple mips64el-linux-gnu -o - -emit-llvm -target-abi n32 \
 // RUN: %s | FileCheck %s -check-prefix=MIPS-64EL-N32
-// MIPS-64EL-N32: target datalayout = 
"e-m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32:64-S128"
+// MIPS-64EL-N32: target datalayout = 
"e-m:e-p:32:32-i8:8:32-i16:16:32-i64:64-n32:64-S128"
 
 // RUN: %clang_cc1 -triple mips64-linux-gnu -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=MIPS-64EB
-// MIPS-64EB: target datalayout = "E-m:m-i8:8:32-i16:16:32-i64:64-n32:64-S128"
+// MIPS-64EB: target datalayout = "E-m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128"
 
 // RUN: %clang_cc1 -triple mips64-linux-gnu -o - -emit-llvm %s -target-abi n32 
\
 // RUN: | FileCheck %s -check-prefix=MIPS-64EB-N32
-// MIPS-64EB-N32: target datalayout = 
"E-m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32:64-S128"
+// MIPS-64EB-N32: target datalayout = 
"E-m:e-p:32:32-i8:8:32-i16:16:32-i64:64-n32:64-S128"
 
 // RUN: %clang_cc1 -triple powerpc64-lv2 -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=PS3


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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Filipe Cabecinhas via cfe-commits]

filcab added a comment.

Thanks a lot for working on this!

Filipe


https://reviews.llvm.org/D22463



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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin added inline comments.


Comment at: docs/Proposals/GitHub.rst:68
@@ +67,3 @@
+ * Collaborate with peers directly, even without access to the Internet
+ * Have multiple trees without multiplying disk space, multiple concurrent 
builds
+

vsk wrote:
> What do you mean by multiple concurrent builds?
With git worktree you can work on source code and build different things at the 
same time, but I guess this is a specific use case which is only made "easier" 
in git. I'll remove this extra comment.


Comment at: docs/Proposals/GitHub.rst:78
@@ +77,3 @@
+
+GitHub, like GitLab and BitBucket, provide FREE code hosting for open source
+projects. Essentially, they will completely replace *all* the infrastructure 
that

dberris wrote:
> nit: I see you use FREE in caps but this instance isn't *FREE* (as opposed to 
> the first mention above) -- consider making it consistent? Either remove the 
> emphasis (just "free") or emphasise consistently?
good point.


Comment at: docs/Proposals/GitHub.rst:86
@@ +85,3 @@
+for example development meetings, sponsoring disadvantaged people to work on
+compilers and foster diversity and quality in our community.
+

dberris wrote:
> Did you mean "diversity and equality" instead of "diversity and quality" here?
indeed, fixed.


Comment at: docs/Proposals/GitHub.rst:102
@@ +101,3 @@
+
+How will the new workflow look like
+===

delcypher wrote:
> s/How will/What will/
ok


Comment at: docs/Proposals/GitHub.rst:110-112
@@ +109,5 @@
+
+As with the current SVN and Git repositories, each project will be separate,
+on its own, and people will also be able to check them out in the same way
+they're already doing today.
+

dberris wrote:
> Consider rewording this sentence -- it's a little too long and is trying to 
> say too many things.
> 
> Perhaps something like:
> 
> "Each LLVM project will continue to be hosted as separate GitHub repositories 
> under a single GitHub organisation. Users can continue to choose to use 
> either SVN or Git to access the repositories to suit their current workflow."
Much better, thanks!


Comment at: docs/Proposals/GitHub.rst:136
@@ +135,3 @@
+
+We will need additional server hooks to avoid non-fast-forwards commits (ex.
+merges, forced pushes, etc) in order to keep the linearity of the history.

delcypher wrote:
> @rengolin : I know GitHub enterprise has a "protected branch" feature to 
> prevent forced pushed ( 
> https://github.com/blog/2051-protected-branches-and-required-status-checks ). 
> You might want to speak to them to see if they can offer us that feature. I 
> think there's a limited support to do a merge as a squash and rebase too ( 
> https://github.com/blog/2141-squash-your-commits )
I'm asking about protected branches (it was proposed earlier, but I can't find 
any info on it).

But we don't want to squash people's commits. They can do that on their own 
before commit.


Comment at: docs/Proposals/GitHub.rst:185
@@ +184,3 @@
+
+Are there any other upstream systems that could be affected?
+

dberris wrote:
> vsk wrote:
> > Yes, the `llvmlab bisect` functionality is affected. IMO it is invaluable 
> > for bug triage. Could you add some kind of reassurance that initially, 
> > updating it for the new VC model will just require pointing it to github's 
> > SVN view?
> Probably worth mentioning how Phabricator will need to be updated to 
> integrate with the GitHub repository once the canonical repo is changed.
Adding llvmlab bisect and Phab to the list. Both should be trivial.


Comment at: docs/Proposals/GitHub.rst:209
@@ +208,3 @@
+   well as a webhook to update the umbrella project (see below).
+3. Make sure we have an llvm-project (with submodules) setup in the official
+   account, with all necessary hooks (history, update, merges).

jyknight wrote:
> mehdi_amini wrote:
> > rengolin wrote:
> > > mehdi_amini wrote:
> > > > > Pre-commit hooks
> > > > 
> > > > Won't handle the update of the umbrella.
> > > > 
> > > > > Post-commit hooks
> > > > 
> > > > Can't handle the update of the umbrella *because of GitHub*, this could 
> > > > be possible with our own hosting of git for instance.
> > > > 
> > > Pre-commit hooks are not designed to update the umbrella. Webhooks will 
> > > be able to update the umbrella with a small external service, as proposed 
> > > in the IRC.
> > That's why I asked it to be clearly mentioned somewhere else that on top of 
> > "hooks" hosted by github, we will need to maintain our own webservice on 
> > our own server to answer updates from theses hooks and update the umbrella, 
> > because that's a non-negligible drawback in face of the motivation exposed 
> > in the "Why move at all?" section. 
> > Right now the document doe

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin updated this revision to Diff 64467.
rengolin added a comment.

More updates, following recent comments.


https://reviews.llvm.org/D22463

Files:
  docs/Proposals/GitHub.rst

Index: docs/Proposals/GitHub.rst
===
--- /dev/null
+++ docs/Proposals/GitHub.rst
@@ -0,0 +1,253 @@
+==
+Moving LLVM Projects to GitHub
+==
+
+Introduction
+
+
+This is a proposal to move our current revision control system from our own
+hosted Subversion to GitHub. Below are the financial and technical arguments as
+to why we need such a move and how will people (and validation infrastructure)
+continue to work with a Git-based LLVM.
+
+There will be a survey pointing at this document when we'll know the community's
+reaction and, if we collectively decide to move, the time-frames. Be sure to make
+your views count.
+
+Essentially, the proposal is divided in the following parts:
+
+ * Outline of the reasons to move to Git and GitHub
+ * Description on how the work flow will look like (compared to SVN)
+ * Remaining issues and potential problems
+ * The proposed migration plan
+
+Why Git, and Why GitHub?
+
+
+Why move at all?
+
+
+The strongest reason for the move, and why this discussion started in the first
+place, is that we currently host our own Subversion server and Git mirror in a
+voluntary basis. The LLVM Foundation sponsors the server and provides limited
+support, but there is only so much it can do.
+
+The volunteers are not Sysadmins themselves, but compiler engineers that happen
+to know a thing or two about hosting servers. We also don't have 24/7 support,
+and we sometimes wake up to see that continuous integration is broken because
+the SVN server is either down or unresponsive.
+
+With time and money, the foundation and volunteers could improve our services,
+implement more functionality and provide around the clock support, so that we
+can have a first class infrastructure with which to work. But the cost is not
+small, both in money and time invested.
+
+On the other hand, there are multiple services out there (GitHub, GitLab,
+BitBucket among others) that offer that same service (24/7 stability, disk space,
+Git server, code browsing, forking facilities, etc) for the very affordable price
+of *free*.
+
+Why Git?
+
+
+Most new coders nowadays start with Git. A lot of them have never used SVN, CVS
+or anything else. Websites like GitHub have changed the landscape of open source
+contributions, reducing the cost of first contribution and fostering
+collaboration.
+
+Git is also the version control most LLVM developers use. Despite the sources
+being stored in an SVN server, most people develop using the Git-SVN integration,
+and that shows that Git is not only more powerful than SVN, but people have
+resorted to using a bridge because its features are now indispensable to their
+internal and external workflows.
+
+In essence, Git allows you to:
+ * Commit, squash, merge, fork locally without any penalty to the server
+ * Add as many branches as necessary to allow for multiple threads of development
+ * Collaborate with peers directly, even without access to the Internet
+ * Have multiple trees without multiplying disk space.
+
+In addition, because Git seems to be replacing every project's version control
+system, there are many more tools that can use Git's enhanced feature set, so
+new tooling is much more likely to support Git first (if not only), than any
+other version control system.
+
+Why GitHub?
+---
+
+GitHub, like GitLab and BitBucket, provide free code hosting for open source
+projects. Essentially, they will completely replace *all* the infrastructure that
+we have today that serves code repository, mirroring, user control, etc.
+
+They also have a dedicated team to monitor, migrate, improve and distribute the
+contents of the repositories depending on region and load. A level of quality
+that we'd never have without spending money that would be better spent elsewhere,
+for example development meetings, sponsoring disadvantaged people to work on
+compilers and foster diversity and equality in our community.
+
+GitHub has the added benefit that we already have a presence there. Many
+developers use it already, and the mirror from our current repository is already
+set up.
+
+Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support)
+where people that still have/want to use SVN infrastructure and tooling can
+slowly migrate or even stay working as if it was an SVN repository (including
+read-write access).
+
+So, any of the three solutions solve the cost and maintenance problem, but GitHub
+has two additional features that would be beneficial to the migration plan as
+well as the community already settled there.
+
+
+What will the new workflow look like
+==

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin updated this revision to Diff 64468.
rengolin added a comment.

Formatting issues (bullet points)


https://reviews.llvm.org/D22463

Files:
  docs/Proposals/GitHub.rst

Index: docs/Proposals/GitHub.rst
===
--- /dev/null
+++ docs/Proposals/GitHub.rst
@@ -0,0 +1,253 @@
+==
+Moving LLVM Projects to GitHub
+==
+
+Introduction
+
+
+This is a proposal to move our current revision control system from our own
+hosted Subversion to GitHub. Below are the financial and technical arguments as
+to why we need such a move and how will people (and validation infrastructure)
+continue to work with a Git-based LLVM.
+
+There will be a survey pointing at this document when we'll know the community's
+reaction and, if we collectively decide to move, the time-frames. Be sure to make
+your views count.
+
+Essentially, the proposal is divided in the following parts:
+
+* Outline of the reasons to move to Git and GitHub
+* Description on what the work flow will look like (compared to SVN)
+* Remaining issues and potential problems
+* The proposed migration plan
+
+Why Git, and Why GitHub?
+
+
+Why move at all?
+
+
+The strongest reason for the move, and why this discussion started in the first
+place, is that we currently host our own Subversion server and Git mirror in a
+voluntary basis. The LLVM Foundation sponsors the server and provides limited
+support, but there is only so much it can do.
+
+The volunteers are not Sysadmins themselves, but compiler engineers that happen
+to know a thing or two about hosting servers. We also don't have 24/7 support,
+and we sometimes wake up to see that continuous integration is broken because
+the SVN server is either down or unresponsive.
+
+With time and money, the foundation and volunteers could improve our services,
+implement more functionality and provide around the clock support, so that we
+can have a first class infrastructure with which to work. But the cost is not
+small, both in money and time invested.
+
+On the other hand, there are multiple services out there (GitHub, GitLab,
+BitBucket among others) that offer that same service (24/7 stability, disk space,
+Git server, code browsing, forking facilities, etc) for the very affordable price
+of *free*.
+
+Why Git?
+
+
+Most new coders nowadays start with Git. A lot of them have never used SVN, CVS
+or anything else. Websites like GitHub have changed the landscape of open source
+contributions, reducing the cost of first contribution and fostering
+collaboration.
+
+Git is also the version control most LLVM developers use. Despite the sources
+being stored in an SVN server, most people develop using the Git-SVN integration,
+and that shows that Git is not only more powerful than SVN, but people have
+resorted to using a bridge because its features are now indispensable to their
+internal and external workflows.
+
+In essence, Git allows you to:
+* Commit, squash, merge, fork locally without any penalty to the server
+* Add as many branches as necessary to allow for multiple threads of development
+* Collaborate with peers directly, even without access to the Internet
+* Have multiple trees without multiplying disk space.
+
+In addition, because Git seems to be replacing every project's version control
+system, there are many more tools that can use Git's enhanced feature set, so
+new tooling is much more likely to support Git first (if not only), than any
+other version control system.
+
+Why GitHub?
+---
+
+GitHub, like GitLab and BitBucket, provide free code hosting for open source
+projects. Essentially, they will completely replace *all* the infrastructure that
+we have today that serves code repository, mirroring, user control, etc.
+
+They also have a dedicated team to monitor, migrate, improve and distribute the
+contents of the repositories depending on region and load. A level of quality
+that we'd never have without spending money that would be better spent elsewhere,
+for example development meetings, sponsoring disadvantaged people to work on
+compilers and foster diversity and equality in our community.
+
+GitHub has the added benefit that we already have a presence there. Many
+developers use it already, and the mirror from our current repository is already
+set up.
+
+Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support)
+where people that still have/want to use SVN infrastructure and tooling can
+slowly migrate or even stay working as if it was an SVN repository (including
+read-write access).
+
+So, any of the three solutions solve the cost and maintenance problem, but GitHub
+has two additional features that would be beneficial to the migration plan as
+well as the community already settled there.
+
+
+What will the new workflow look like
+
+
+

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin updated this revision to Diff 64469.

https://reviews.llvm.org/D22463

Files:
  docs/Proposals/GitHub.rst

Index: docs/Proposals/GitHub.rst
===
--- /dev/null
+++ docs/Proposals/GitHub.rst
@@ -0,0 +1,254 @@
+==
+Moving LLVM Projects to GitHub
+==
+
+Introduction
+
+
+This is a proposal to move our current revision control system from our own
+hosted Subversion to GitHub. Below are the financial and technical arguments as
+to why we need such a move and how will people (and validation infrastructure)
+continue to work with a Git-based LLVM.
+
+There will be a survey pointing at this document when we'll know the community's
+reaction and, if we collectively decide to move, the time-frames. Be sure to make
+your views count.
+
+Essentially, the proposal is divided in the following parts:
+
+* Outline of the reasons to move to Git and GitHub
+* Description on what the work flow will look like (compared to SVN)
+* Remaining issues and potential problems
+* The proposed migration plan
+
+Why Git, and Why GitHub?
+
+
+Why move at all?
+
+
+The strongest reason for the move, and why this discussion started in the first
+place, is that we currently host our own Subversion server and Git mirror in a
+voluntary basis. The LLVM Foundation sponsors the server and provides limited
+support, but there is only so much it can do.
+
+The volunteers are not Sysadmins themselves, but compiler engineers that happen
+to know a thing or two about hosting servers. We also don't have 24/7 support,
+and we sometimes wake up to see that continuous integration is broken because
+the SVN server is either down or unresponsive.
+
+With time and money, the foundation and volunteers could improve our services,
+implement more functionality and provide around the clock support, so that we
+can have a first class infrastructure with which to work. But the cost is not
+small, both in money and time invested.
+
+On the other hand, there are multiple services out there (GitHub, GitLab,
+BitBucket among others) that offer that same service (24/7 stability, disk space,
+Git server, code browsing, forking facilities, etc) for the very affordable price
+of *free*.
+
+Why Git?
+
+
+Most new coders nowadays start with Git. A lot of them have never used SVN, CVS
+or anything else. Websites like GitHub have changed the landscape of open source
+contributions, reducing the cost of first contribution and fostering
+collaboration.
+
+Git is also the version control most LLVM developers use. Despite the sources
+being stored in an SVN server, most people develop using the Git-SVN integration,
+and that shows that Git is not only more powerful than SVN, but people have
+resorted to using a bridge because its features are now indispensable to their
+internal and external workflows.
+
+In essence, Git allows you to:
+
+* Commit, squash, merge, fork locally without any penalty to the server
+* Add as many branches as necessary to allow for multiple threads of development
+* Collaborate with peers directly, even without access to the Internet
+* Have multiple trees without multiplying disk space.
+
+In addition, because Git seems to be replacing every project's version control
+system, there are many more tools that can use Git's enhanced feature set, so
+new tooling is much more likely to support Git first (if not only), than any
+other version control system.
+
+Why GitHub?
+---
+
+GitHub, like GitLab and BitBucket, provide free code hosting for open source
+projects. Essentially, they will completely replace *all* the infrastructure that
+we have today that serves code repository, mirroring, user control, etc.
+
+They also have a dedicated team to monitor, migrate, improve and distribute the
+contents of the repositories depending on region and load. A level of quality
+that we'd never have without spending money that would be better spent elsewhere,
+for example development meetings, sponsoring disadvantaged people to work on
+compilers and foster diversity and equality in our community.
+
+GitHub has the added benefit that we already have a presence there. Many
+developers use it already, and the mirror from our current repository is already
+set up.
+
+Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support)
+where people that still have/want to use SVN infrastructure and tooling can
+slowly migrate or even stay working as if it was an SVN repository (including
+read-write access).
+
+So, any of the three solutions solve the cost and maintenance problem, but GitHub
+has two additional features that would be beneficial to the migration plan as
+well as the community already settled there.
+
+
+What will the new workflow look like
+
+
+In order to move version control, we need to make sure that 

[PATCH] D22505: Access Modifier Use Normal Indent

[Loki Astari via cfe-commits]

LokiAstari created this revision.
LokiAstari added reviewers: djasper, klimek.
LokiAstari added a subscriber: cfe-commits.
Herald added a subscriber: klimek.

Access Modifiers (public/protected/private) causes standard indent.

```
class MyClass
{
int value1;// standard indent.
public:// access modifier (increases indent level)
int value2;// next item indent one more level 
private:   // access modifier goes out a level
int value3;// next item indent one more level 
};
```

https://reviews.llvm.org/D22505

Files:
  docs/ClangFormatStyleOptions.rst
  include/clang/Format/Format.h
  lib/Format/Format.cpp
  lib/Format/TokenAnnotator.h
  lib/Format/UnwrappedLineFormatter.cpp
  lib/Format/UnwrappedLineParser.cpp
  lib/Format/UnwrappedLineParser.h
  unittests/Format/CMakeLists.txt
  unittests/Format/FormatTestAccess.cpp

Index: unittests/Format/FormatTestAccess.cpp
===
--- unittests/Format/FormatTestAccess.cpp
+++ unittests/Format/FormatTestAccess.cpp
@@ -0,0 +1,150 @@
+//===- unittest/Format/FormatTestAccess.cpp - Formatting unit tests
+//-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "clang/Format/Format.h"
+
+#include "../Tooling/RewriterTestContext.h"
+#include "FormatTestUtils.h"
+
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+#include "llvm/Support/Debug.h"
+#include "llvm/Support/MemoryBuffer.h"
+#include "gtest/gtest.h"
+
+#define DEBUG_TYPE "format-test"
+
+namespace clang {
+namespace format {
+namespace {
+
+class FormatTestAccess : public ::testing::Test {
+protected:
+  std::string format(llvm::StringRef Code, bool normalFormat) {
+const FormatStyle &Style = getGoogleStyleWithColumns(normalFormat);
+DEBUG(llvm::errs() << "---\n");
+DEBUG(llvm::errs() << Code << "\n\n");
+std::vector Ranges(1, tooling::Range(0, Code.size()));
+bool IncompleteFormat = false;
+tooling::Replacements Replaces =
+reformat(Style, Code, Ranges, "", &IncompleteFormat);
+EXPECT_FALSE(IncompleteFormat) << Code << "\n\n";
+auto Result = applyAllReplacements(Code, Replaces);
+EXPECT_TRUE(static_cast(Result));
+DEBUG(llvm::errs() << "\n" << *Result << "\n\n");
+return *Result;
+  }
+
+  FormatStyle getGoogleStyleWithColumns(bool normalFormat) {
+FormatStyle Style = getLLVMStyle();
+Style.AccessModifierOffset = normalFormat ? 0 : -2;
+Style.AccessModifierStandardIndent = normalFormat;
+return Style;
+  }
+
+  void verifyFormat(llvm::StringRef Code, bool normalFormat) {
+EXPECT_EQ(Code.str(), format(test::messUp(Code), normalFormat));
+  }
+};
+
+TEST_F(FormatTestAccess, NoChangeWithoutAccess) {
+  verifyFormat("class A {\n"
+   "  int a1;\n"
+   "};",
+   false);
+  verifyFormat("class B {\n"
+   "  int b1;\n"
+   "};",
+   true);
+}
+
+TEST_F(FormatTestAccess, ChangeWithAccess) {
+  verifyFormat("class C {\n"
+   "  int c1;\n"
+   "public:\n"
+   "  int c2;\n"
+   "};",
+   false);
+  verifyFormat("class D {\n"
+   "  int d1;\n"
+   "  public:\n"
+   "int d2;\n"
+   "};",
+   true);
+}
+
+TEST_F(FormatTestAccess, MultipleAccessLevels) {
+  verifyFormat("class E {\n"
+   "  int e1;\n"
+   "public:\n"
+   "  int e2;\n"
+   "private:\n"
+   "  int e3;\n"
+   "protected:\n"
+   "  int e4;\n"
+   "};",
+   false);
+  verifyFormat("class F {\n"
+   "  int f1;\n"
+   "  public:\n"
+   "int f2;\n"
+   "  private:\n"
+   "int f3;\n"
+   "  protected:\n"
+   "int f4;\n"
+   "};",
+   true);
+}
+
+TEST_F(FormatTestAccess, NestedClass) {
+  verifyFormat("class G {\n"
+   "  int g1;\n"
+   "  class GGA {\n"
+   "int gg1;\n"
+   "  public:\n"
+   "int gg2;\n"
+   "  };\n"
+   "public:\n"
+   "  class GGB {\n"
+   "int gg1;\n"
+   "  public:\n"
+   "int gg2;\n"
+   "  };\n"
+   "  int g2;\n"
+   "private:\n"
+   "  int g3;\n"
+   "protected:\n"
+   "  int g4;\n"
+   "};",
+   false);
+  verifyFormat("class H {\n"
+   "  int h1;\n"
+   "  class HHA {\n"
+   "int hh1;\n"
+   "public:\n"
+

r275970 - Deprecated (legacy) string literal conversion to 'char *' causes strange overloading resolution

[Dmitry Polukhin via cfe-commits]

Author: dpolukhin
Date: Tue Jul 19 06:29:16 2016
New Revision: 275970

URL: http://llvm.org/viewvc/llvm-project?rev=275970&view=rev
Log:
Deprecated (legacy) string literal conversion to 'char *' causes strange 
overloading resolution

It's a patch for PR28050. Seems like overloading resolution wipes out
the first standard conversion sequence (before user-defined conversion)
in case of deprecated string literal conversion.

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

Patch by Alexander Makarov

Added:
cfe/trunk/test/SemaCXX/pr28050.cpp   (with props)
Modified:
cfe/trunk/include/clang/Sema/Overload.h
cfe/trunk/lib/Sema/SemaOverload.cpp

Modified: cfe/trunk/include/clang/Sema/Overload.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Overload.h?rev=275970&r1=275969&r2=275970&view=diff
==
--- cfe/trunk/include/clang/Sema/Overload.h (original)
+++ cfe/trunk/include/clang/Sema/Overload.h Tue Jul 19 06:29:16 2016
@@ -428,8 +428,11 @@ namespace clang {
 };
 
 ImplicitConversionSequence()
-  : ConversionKind(Uninitialized), StdInitializerListElement(false)
-{}
+: ConversionKind(Uninitialized), StdInitializerListElement(false) {
+  Standard.First = ICK_Identity;
+  Standard.Second = ICK_Identity;
+  Standard.Third = ICK_Identity;
+}
 ~ImplicitConversionSequence() {
   destruct();
 }

Modified: cfe/trunk/lib/Sema/SemaOverload.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOverload.cpp?rev=275970&r1=275969&r2=275970&view=diff
==
--- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOverload.cpp Tue Jul 19 06:29:16 2016
@@ -1199,7 +1199,6 @@ TryUserDefinedConversion(Sema &S, Expr *
   case OR_Success:
   case OR_Deleted:
 ICS.setUserDefined();
-ICS.UserDefined.Before.setAsIdentityConversion();
 // C++ [over.ics.user]p4:
 //   A conversion of an expression of class type to the same class
 //   type is given Exact Match rank, and a conversion of an
@@ -4540,7 +4539,6 @@ TryReferenceInit(Sema &S, Expr *Init, Qu
   return ICS;
 }
 
-ICS.UserDefined.Before.setAsIdentityConversion();
 ICS.UserDefined.After.ReferenceBinding = true;
 ICS.UserDefined.After.IsLvalueReference = !isRValRef;
 ICS.UserDefined.After.BindsToFunctionLvalue = false;

Added: cfe/trunk/test/SemaCXX/pr28050.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/pr28050.cpp?rev=275970&view=auto
==
--- cfe/trunk/test/SemaCXX/pr28050.cpp (added)
+++ cfe/trunk/test/SemaCXX/pr28050.cpp Tue Jul 19 06:29:16 2016
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -std=c++11 %s -fsyntax-only
+//
+// expected-no-diagnostics
+
+class A {
+public:
+  A(char *s) {}
+  A(A &&) = delete;
+};
+
+int main() { A a("OK"); }

Propchange: cfe/trunk/test/SemaCXX/pr28050.cpp
--
svn:eol-style = native

Propchange: cfe/trunk/test/SemaCXX/pr28050.cpp
--
svn:keywords = "Author Date Id Rev URL"

Propchange: cfe/trunk/test/SemaCXX/pr28050.cpp
--
svn:mime-type = text/plain


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

Re: [PATCH] D21228: Deprecated (legacy) string literal conversion to 'char *' causes strange overloading resolution

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin added a subscriber: DmitryPolukhin.
DmitryPolukhin closed this revision.
DmitryPolukhin added a comment.

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


https://reviews.llvm.org/D21228



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

Re: [PATCH] D21962: MPITypeMismatchCheck for Clang-Tidy

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Thanks for addressing the comments. The code looks better now. My main concern 
at this point is that the name and the location of the check: "misc" is a place 
for the stuff we can't find a better place for, but here I guess we clearly 
want a separate module and a subdirectory for MPI-related checks 
(MPITidyModule, "mpi/"). The check name should be updated accordingly: 
"mpi-type-mismatch".

A few more comments inline.



Comment at: clang-tidy/misc/MpiTypeMismatchCheck.cpp:212
@@ +211,3 @@
+
+  static std::map FixedWidthMatches = {
+  {"int8_t", "MPI_INT8_T"}, {"int16_t", "MPI_INT16_T"},

`llvm::StringMap` should be more efficient here.


Comment at: clang-tidy/misc/MpiTypeMismatchCheck.cpp:218
@@ +217,3 @@
+
+  StringRef TypedefToCompare = Typedef->getDecl()->getQualifiedNameAsString();
+  // Check if the typedef is known and not matching the MPI datatype.

`getQualifiedNameAsString` returns a `std::string`, which will be destroyed at 
the end of this statement. `TypedefToCompare` will be a dangling reference 
then. Please change `StringRef` to `std::string` here.

Another question is whether you need `getQualifiedNameAsString`, which is 
rather expensive. Maybe you could use `getName` (it returns a `StringRef` and 
is relatively cheap) and additionally check that the name is in the global 
namespace?


Comment at: clang-tidy/misc/MpiTypeMismatchCheck.cpp:220
@@ +219,3 @@
+  // Check if the typedef is known and not matching the MPI datatype.
+  if (FixedWidthMatches.find(TypedefToCompare) != FixedWidthMatches.end() &&
+  FixedWidthMatches.at(TypedefToCompare) != MPIDatatype) {

Repeated lookups into a map are wasteful. Please store the result of `find` and 
use it to get the value.


https://reviews.llvm.org/D21962



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

Re: [PATCH] D22381: cppcoreguidelines-pro-bounds-constant-array-index: ignore implicit constructor

[Alexander Kornienko via cfe-commits]

alexfh accepted this revision.
alexfh added a comment.
This revision is now accepted and ready to land.

LG


https://reviews.llvm.org/D22381



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

Re: [PATCH] D22069: clang-tidy modernize-loop-convert: preserve type of alias declaration (bug 28341)

[Alexander Kornienko via cfe-commits]

alexfh accepted this revision.
alexfh added a comment.
This revision is now accepted and ready to land.

LG



Comment at: test/clang-tidy/modernize-loop-convert-extra.cpp:1070
@@ +1069,3 @@
+  // CHECK-FIXES: for(unsigned char value : v)
+  // CHECK-FIXES-NOT: unsigned char value = v[i];
+  if (value > 127)

I'd just `CHECK-FIXES-NEXT: if (value > 127)`


https://reviews.llvm.org/D22069



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

Re: [PATCH] D22208: clang-tidy] Fixes to modernize-use-emplace

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/modernize/UseEmplaceCheck.cpp:21
@@ +20,3 @@
+llvm::Optional>
+getHasAnyName(const std::vector &Names) {
+  llvm::Optional> HasNameMatcher;

Looking at `VariadicFunction`, it appears that it already works if you pass an 
`ArrayRef` to the `operator()()` overload. See ASTMatchersInternal.h:81. So 
I still think the matcher can be used directly, just with changing the type of 
the object passed to the functor.


Repository:
  rL LLVM

https://reviews.llvm.org/D22208



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

Re: [PATCH] D19780: Output OpenCL version in Clang diagnostics

[Anastasia Stulova via cfe-commits]

Anastasia closed this revision.
Anastasia added a comment.

r269305


https://reviews.llvm.org/D19780



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

[PATCH] D22510: [include-fixer] A refactoring of IncludeFixerContext.

[Haojian Wu via cfe-commits]

hokein created this revision.
hokein added a reviewer: bkramer.
hokein added a subscriber: cfe-commits.

No functional changes in this patch. It is a refactoring (pull out a
structure representing the symbol being queried).

This is a preparing step for inserting missing namespace qualifiers to all
instances of an unidentified symbol.

https://reviews.llvm.org/D22510

Files:
  include-fixer/IncludeFixer.cpp
  include-fixer/IncludeFixerContext.cpp
  include-fixer/IncludeFixerContext.h
  include-fixer/tool/ClangIncludeFixer.cpp
  include-fixer/tool/clang-include-fixer.py
  test/include-fixer/commandline_options.cpp

Index: test/include-fixer/commandline_options.cpp
===
--- test/include-fixer/commandline_options.cpp
+++ test/include-fixer/commandline_options.cpp
@@ -1,9 +1,9 @@
 // REQUIRES: shell
 // RUN: echo "foo f;" > %t.cpp
 // RUN: clang-include-fixer -db=fixed -input='foo= "foo.h","bar.h"' -output-headers %t.cpp -- | FileCheck %s
-// RUN: cat %t.cpp | clang-include-fixer -stdin -insert-header='{SymbolIdentifier: foo, Range: {Offset: 0, Length: 3}, HeaderInfos: [{Header: "\"foo.h\"", QualifiedName: "foo"}]}' %t.cpp | FileCheck %s -check-prefix=CHECK-CODE
-// RUN: cat %t.cpp | not clang-include-fixer -stdin -insert-header='{SymbolIdentifier: foo, Range: {Offset: 0, Length: 3}, HeaderInfos: [{Header: "\"foo.h\"", QualifiedName: "foo"},{Header: "\"foo2.h\"", QualifiedName: "foo"}]}' %t.cpp
-// RUN: cat %t.cpp | clang-include-fixer -stdin -insert-header='{SymbolIdentifier: foo, Range: {Offset: 0, Length: 3}, HeaderInfos: [{Header: "\"foo.h\"", QualifiedName: "a:foo"},{Header: "\"foo.h\"", QualifiedName: "b:foo"}]}' %t.cpp
+// RUN: cat %t.cpp | clang-include-fixer -stdin -insert-header='{QuerySymbolInfo: {RawIdentifier: foo, Range: {Offset: 0, Length: 3}}, HeaderInfos: [{Header: "\"foo.h\"", QualifiedName: "foo"}]}' %t.cpp | FileCheck %s -check-prefix=CHECK-CODE
+// RUN: cat %t.cpp | not clang-include-fixer -stdin -insert-header='{QuerySymbolInfo: {RawIdentifier: foo, Range: {Offset: 0, Length: 3}}, HeaderInfos: [{Header: "\"foo.h\"", QualifiedName: "foo"},{Header: "\"foo2.h\"", QualifiedName: "foo"}]}' %t.cpp
+// RUN: cat %t.cpp | clang-include-fixer -stdin -insert-header='{QuerySymbolInfo: {RawIdentifier: foo, Range: {Offset: 0, Length: 3}}, HeaderInfos: [{Header: "\"foo.h\"", QualifiedName: "a:foo"},{Header: "\"foo.h\"", QualifiedName: "b:foo"}]}' %t.cpp
 //
 // CHECK: "HeaderInfos": [
 // CHECK-NEXT:  {"Header": "\"foo.h\"",
Index: include-fixer/tool/clang-include-fixer.py
===
--- include-fixer/tool/clang-include-fixer.py
+++ include-fixer/tool/clang-include-fixer.py
@@ -127,7 +127,8 @@
 return
 
   include_fixer_context = json.loads(stdout)
-  symbol = include_fixer_context["SymbolIdentifier"]
+  query_symbol_info = include_fixer_context["QuerySymbolInfo"]
+  symbol = query_symbol_info["RawIdentifier"]
   # The header_infos is already sorted by include-fixer.
   header_infos = include_fixer_context["HeaderInfos"]
   # Deduplicate headers while keeping the order, so that the same header would
@@ -151,8 +152,7 @@
   try:
 # If there is only one suggested header, insert it directly.
 if len(unique_headers) == 1 or maximum_suggested_headers == 1:
-  InsertHeaderToVimBuffer({"SymbolIdentifier": symbol,
-   "Range": include_fixer_context["Range"],
+  InsertHeaderToVimBuffer({"QuerySymbolInfo": query_symbol_info,
"HeaderInfos": header_infos}, text)
   print "Added #include {0} for {1}.".format(unique_headers[0], symbol)
   return
@@ -163,8 +163,7 @@
   header for header in header_infos if header["Header"] == selected]
 
 # Insert a selected header.
-InsertHeaderToVimBuffer({"SymbolIdentifier": symbol,
- "Range": include_fixer_context["Range"],
+InsertHeaderToVimBuffer({"QuerySymbolInfo": query_symbol_info,
  "HeaderInfos": selected_header_infos}, text)
 print "Added #include {0} for {1}.".format(selected, symbol)
   except Exception as error:
Index: include-fixer/tool/ClangIncludeFixer.cpp
===
--- include-fixer/tool/ClangIncludeFixer.cpp
+++ include-fixer/tool/ClangIncludeFixer.cpp
@@ -61,11 +61,17 @@
   }
 };
 
+template <> struct MappingTraits {
+  static void mapping(IO &io, IncludeFixerContext::QuerySymbolInfo &Info) {
+io.mapRequired("RawIdentifier", Info.RawIdentifier);
+io.mapRequired("Range", Info.Range);
+  }
+};
+
 template <> struct MappingTraits {
   static void mapping(IO &IO, IncludeFixerContext &Context) {
-IO.mapRequired("SymbolIdentifier", Context.SymbolIdentifier);
+IO.mapRequired("QuerySymbolInfo", Context.QuerySymbol);
 IO.mapRequired("HeaderInfos", Context.HeaderInfos);
-IO.mapRequired("Range", Context.SymbolRang

r275974 - Fix for failing bot sanitizer-x86_64-linux-fast after r275970

[Dmitry Polukhin via cfe-commits]

Author: dpolukhin
Date: Tue Jul 19 08:35:15 2016
New Revision: 275974

URL: http://llvm.org/viewvc/llvm-project?rev=275974&view=rev
Log:
Fix for failing bot sanitizer-x86_64-linux-fast after r275970

More info 
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/14774/steps/check-clang%20msan/logs/stdio

Modified:
cfe/trunk/include/clang/Sema/Overload.h

Modified: cfe/trunk/include/clang/Sema/Overload.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Overload.h?rev=275974&r1=275973&r2=275974&view=diff
==
--- cfe/trunk/include/clang/Sema/Overload.h (original)
+++ cfe/trunk/include/clang/Sema/Overload.h Tue Jul 19 08:35:15 2016
@@ -429,9 +429,7 @@ namespace clang {
 
 ImplicitConversionSequence()
 : ConversionKind(Uninitialized), StdInitializerListElement(false) {
-  Standard.First = ICK_Identity;
-  Standard.Second = ICK_Identity;
-  Standard.Third = ICK_Identity;
+  Standard.setAsIdentityConversion();
 }
 ~ImplicitConversionSequence() {
   destruct();


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

Re: [PATCH] D21992: [clang-tidy] new cppcoreguidelines-slicing

[Alexander Kornienko via cfe-commits]

alexfh accepted this revision.
alexfh added a comment.
This revision is now accepted and ready to land.

LG with a nit.



Comment at: clang-tidy/cppcoreguidelines/SlicingCheck.cpp:86
@@ +85,3 @@
+   "slicing object from type %0 to %1 discards override %2")
+  << &DerivedDecl << &BaseDecl << Method;
+}

The "slicing ... discards x bytes of state" message is not going to be repeated 
for the same location, so it's fine on its own.

Re: the "discards override" messages, they quite infrequent, IIUC, so the risk 
of spamming people with diagnostics is rather low. In case it's still 
problematic, we can change the repeated parts to notes.


Comment at: clang-tidy/cppcoreguidelines/SlicingCheck.cpp:91
@@ +90,3 @@
+  for (const auto &Base : DerivedDecl.bases()) {
+const auto *BaseRecordType = Base.getType()->getAs();
+if (!BaseRecordType)

Let's make the code more consistent:

```
if (const auto *BaseRecordType = Base.getType()->getAs()) {
  if (const auto *BaseRecord =
cast_or_null(BaseRecordType->getDecl()->getDefinition()))
  DiagnoseSlicedOverriddenMethods(Call, *BaseRecord, BaseDecl);
}
```


https://reviews.llvm.org/D21992



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

Re: [PATCH] D16538: [cc1as] Add MCTargetOptions argument to createAsmBackend

[Joel Jones via cfe-commits]

joelkevinjones added a comment.

Ping. This change needs to be made once https://reviews.llvm.org/D16213 goes in.


https://reviews.llvm.org/D16538



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

Re: [PATCH] D20196: [clang-tidy] Inefficient string operation

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

A few more nits.



Comment at: clang-tidy/performance/InefficientStringConcatenationCheck.cpp:50
@@ +49,3 @@
+  hasOverloadedOperatorName("="),
+  hasArgument(0, allOf(declRefExpr(BasicStringType),
+   declRefExpr(hasDeclaration(decl().bind("lhsStrT")))

The `allOf(declRefExpr(x), declRefExpr(y))` construct can be replaced with 
`declRefExpr(x, y)`.


Comment at: clang-tidy/performance/InefficientStringConcatenationCheck.cpp:54
@@ +53,3 @@
+  hasArgument(1, stmt(hasDescendant(declRefExpr(
+ hasDeclaration(decl(equalsBoundNode("lhsStrT"))),
+  hasDescendant(BasicStringPlusOperator));

Indentation is confusing - as though `hasDeclaration` is an argument of `stmt`. 
Is it a result of clang-format?


Comment at: clang-tidy/performance/InefficientStringConcatenationCheck.cpp:63
@@ +62,3 @@
+cxxOperatorCallExpr(
+hasAncestor(stmt(anyOf(cxxForRangeStmt(), whileStmt(), 
forStmt(,
+anyOf(AssignOperator, PlusOperator)),

`hasAncestor` is potentially more expensive, so it should go last.


https://reviews.llvm.org/D20196



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

Re: [PATCH] D19586: Misleading Indentation check

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Please mark all addressed comments "Done".



Comment at: test/clang-tidy/readability-misleading-indentation.cpp:15
@@ +14,3 @@
+  foo2(); // comment
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: wrong indentation, 
'else' belongs to 'if(cond2)' statement
+  // CHECK-FIXES: {{^}}  // comment1

Please place // CHECK comments at column 1 or 3. Indenting them like this makes 
the test less readable.


Comment at: test/clang-tidy/readability-misleading-indentation.cpp:16
@@ +15,3 @@
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: wrong indentation, 
'else' belongs to 'if(cond2)' statement
+  // CHECK-FIXES: {{^}}  // comment1
+

Did you run the tests after changes? I don't think the `// comment1` line can 
actually appear in the fixed code, when it's not there before the fix.


https://reviews.llvm.org/D19586



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

Re: [PATCH] D22034: [MSVC][DLL] use local vftable mangling only exported classes with virtual destructor

[Reid Kleckner via cfe-commits]

rnk added inline comments.


Comment at: test/CodeGenCXX/dllimport-rtti.cpp:7
@@ -6,3 +6,1 @@
 } s;
-// MSVC: [[VF_S:.*]] = private unnamed_addr constant [2 x i8*]
-// MSVC-DAG: @"\01??_SS@@6B@" = unnamed_addr alias i8*, getelementptr inbounds 
([2 x i8*], [2 x i8*]* [[VF_S]], i32 0, i32 1)

DmitryPolukhin wrote:
> rnk wrote:
> > I would've expected this to remain the same, since the implicit default 
> > ctor of 'S' is constexpr by default in C++14. It seems a lot better to emit 
> > a local vftable here and get static initialization for 's' than dynamic 
> > initialization.
> The context of evaluation of the whole expression is not constexpr so this 
> case can be done both ways. But implemented approach is how MSVC behaves in 
> this case. MSVC has very predictable behavior when local vftable is used - 
> only when class has virtual d-tor. Current Clang behavior is also very 
> consistent - always use local vftable. But this patch makes it hard to 
> predict which table will be used - it becomes use context sensitive instead 
> of depending only on class declaration. Therefore different translation units 
> could use different tables and it could cause strange artifacts. Using 
> dllimported classes in pure constexpr case in my experience is very rare case 
> so it was kind of fine but implicit constructors much more common case.
> 
> Also thinking more about my patch I realized that fix in MayBeEmittedEagerly 
> doesn't work if dllimported class is a member of non-imported class so actual 
> fix would require traversing for all base classes and members for the type.
> 
> So my proposal is to keep things as is for now and abandon this patch if you 
> have no objection.
Sounds good, we also thought this was a reasonable compromise position last 
time we touched this.


https://reviews.llvm.org/D22034



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

r275975 - Add support of the latest Ubuntu (Yakkety Yak - 16.10)

[Sylvestre Ledru via cfe-commits]

Author: sylvestre
Date: Tue Jul 19 09:00:57 2016
New Revision: 275975

URL: http://llvm.org/viewvc/llvm-project?rev=275975&view=rev
Log:
Add support of the latest Ubuntu (Yakkety Yak - 16.10)


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

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=275975&r1=275974&r2=275975&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Tue Jul 19 09:00:57 2016
@@ -3787,6 +3787,7 @@ enum Distro {
   UbuntuVivid,
   UbuntuWily,
   UbuntuXenial,
+  UbuntuYakkety,
   UnknownDistro
 };
 
@@ -3801,7 +3802,7 @@ static bool IsDebian(enum Distro Distro)
 }
 
 static bool IsUbuntu(enum Distro Distro) {
-  return Distro >= UbuntuHardy && Distro <= UbuntuXenial;
+  return Distro >= UbuntuHardy && Distro <= UbuntuYakkety;
 }
 
 static Distro DetectDistro(const Driver &D, llvm::Triple::ArchType Arch) {
@@ -3832,6 +3833,7 @@ static Distro DetectDistro(const Driver
   .Case("vivid", UbuntuVivid)
   .Case("wily", UbuntuWily)
   .Case("xenial", UbuntuXenial)
+  .Case("yakkety", UbuntuYakkety)
   .Default(UnknownDistro);
 if (Version != UnknownDistro)
   return Version;


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

[PATCH] D22514: CloneDetection now respects statement specific data when searching for clones.

[Raphael Isemann via cfe-commits]

teemperor created this revision.
teemperor added reviewers: v.g.vassilev, zaks.anna, NoQ.
teemperor added a subscriber: cfe-commits.

So far the CloneDetector only respected the class of each statement when 
searching for clones. This means that nodes that differentiate in any other 
attribute are falsely considered to be clones of each other as long as they had 
the same statement class. As an example, the statements "a > b" and "a < b" are 
currently considered to be clones of each other, even though they are obviously 
different.

This patch refines the way the CloneDetector collects data from each statement 
by providing methods for each class that will read the class-specific 
attributes. These attributes are for example the operator kind for 
BinaryOperator statements which would prevent the false-positive result from 
the example above.

The code itself is contained in the StmtDataCollector class because it will be 
reused in a future patch that searches for false-positives.

https://reviews.llvm.org/D22514

Files:
  lib/Analysis/CloneDetection.cpp
  test/Analysis/copypaste/test-min-max.cpp

Index: test/Analysis/copypaste/test-min-max.cpp
===
--- test/Analysis/copypaste/test-min-max.cpp
+++ test/Analysis/copypaste/test-min-max.cpp
@@ -18,14 +18,6 @@
 
 // False positives below. These clones should not be reported.
 
-// FIXME: Detect different binary operator kinds.
-int min1(int a, int b) { // expected-note{{Related code clone is here.}}
-  log();
-  if (a < b)
-return a;
-  return b;
-}
-
 // FIXME: Detect different variable patterns.
 int min2(int a, int b) { // expected-note{{Related code clone is here.}}
   log();
@@ -36,6 +28,13 @@
 
 // Functions below are not clones and should not be reported.
 
+int min1(int a, int b) { // no-warning
+  log();
+  if (a < b)
+return a;
+  return b;
+}
+
 int foo(int a, int b) { // no-warning
   return a + b;
 }
Index: lib/Analysis/CloneDetection.cpp
===
--- lib/Analysis/CloneDetection.cpp
+++ lib/Analysis/CloneDetection.cpp
@@ -78,6 +78,199 @@
 SourceLocation StmtSequence::getEndLoc() const { return back()->getLocEnd(); }
 
 namespace {
+/// \brief Defines empty addData methods for each Stmt class.
+///
+/// StmtDataCollector inherits from this class so that each Stmt has an empty
+/// fallback addData method. This prevents compilation failures from missing
+/// methods if a new Stmt subclass is added to clang. Also, many subclasses
+/// don't have any special data attached to them, so we don't need to manually
+/// define empty addData methods in StmtDataCollector if they are already
+/// defined here.
+class StmtDataCollectorDefiner {
+protected:
+  #define STMT(CLASS, PARENT)  \
+  void addData##CLASS(CLASS const *S) {\
+  }
+  #include "clang/AST/StmtNodes.inc"
+};
+} // end anonymous namespace
+
+namespace {
+/// \brief Collects the data of a single Stmt.
+///
+/// The data of a statement that isn't collected by this class is considered to
+/// be unimportant when comparing two statements. This means that this class
+/// defines what a 'similar' clone is. For example, this class doesn't collect
+/// names of variables for example, which makes statements that only differ in
+/// the names of the referenced variables clones of each other.
+class StmtDataCollector : StmtDataCollectorDefiner {
+  ASTContext &Context;
+  llvm::FoldingSetNodeID &D;
+
+public:
+
+  /// \brief Collects data from the given Stmt and saves it into the given
+  ///FoldingSetNodeID.
+  StmtDataCollector(Stmt const *S, ASTContext &Context,
+llvm::FoldingSetNodeID &D) : Context(Context), D(D) {
+collectData(S);
+  }
+
+protected:
+  // Below are utility methods for adding generic data to the FoldingSetNodeID.
+
+  void addData(unsigned Data) {
+D.AddInteger(Data);
+  }
+
+  void addData(llvm::StringRef const &String) {
+D.AddString(String);
+  }
+
+  void addData(std::string const &String) {
+D.AddString(String);
+  }
+
+  void addData(QualType QT) {
+addData(QT.getAsString());
+  }
+
+  // Utility functions for calling the addData method for each parent class
+  // of a given Stmt class.
+  #define STMT(CLASS, PARENT)  \
+  void callAddData##CLASS(CLASS const *S) {\
+callAddData##PARENT(S);\
+addData##CLASS(S); \
+  }
+  #include "clang/AST/StmtNodes.inc"
+
+  // Above code won't define callAddDataStmt, so we have to manually define it.
+  void callAddDataStmt(Stmt const *S) {
+addDataStmt(S);
+  }
+
+  /// \brief Calls the appropriate callAddData method for the actual class of
+  ///the given Stmt.
+  void c

Re: [PATCH] D22514: CloneDetection now respects statement specific data when searching for clones.

[Raphael Isemann via cfe-commits]

teemperor planned changes to this revision.
teemperor added a comment.

- Expand test suite to test newly added code.


https://reviews.llvm.org/D22514



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

Re: [PATCH] D16376: clang-tidy check: cppcoreguidelines-rule-of-five-and-zero

[Jonathan B Coe via cfe-commits]

jbcoe retitled this revision from "clang-tidy check: 
misc-deprecated-special-member-functions" to "clang-tidy check: 
cppcoreguidelines-rule-of-five-and-zero".
jbcoe updated the summary for this revision.
jbcoe updated this revision to Diff 64490.
jbcoe added a comment.
Herald added a subscriber: nemanjai.

I've rewritten this patch to implement a rule-of-five-and-zero check.

No fixes are offered as we've not found them to be useful.


https://reviews.llvm.org/D16376

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/RuleOfFiveAndZeroCheck.cpp
  clang-tidy/cppcoreguidelines/RuleOfFiveAndZeroCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-rule-of-five-and-zero.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-rule-of-five-and-zero.cpp

Index: test/clang-tidy/cppcoreguidelines-rule-of-five-and-zero.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-rule-of-five-and-zero.cpp
@@ -0,0 +1,44 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-rule-of-five-and-zero %t
+
+class DefinesDestructor {
+  ~DefinesDestructor();
+};
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesDestructor' defines a destructor but does not define or delete all other special member functions [cppcoreguidelines-rule-of-five-and-zero]
+
+class DefinesCopyConstructor {
+  DefinesCopyConstructor(const DefinesCopyConstructor &);
+};
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesCopyConstructor' defines a copy constructor but does not define or delete all other special member functions [cppcoreguidelines-rule-of-five-and-zero]
+class DefinesCopyAssignment {
+  DefinesCopyAssignment &operator=(const DefinesCopyAssignment &);
+};
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesCopyAssignment' defines a copy assignment operator but does not define or delete all other special member functions [cppcoreguidelines-rule-of-five-and-zero]
+
+class DefinesMoveConstructor {
+  DefinesMoveConstructor(DefinesMoveConstructor &&);
+};
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesMoveConstructor' defines a move constructor but does not define or delete all other special member functions [cppcoreguidelines-rule-of-five-and-zero]
+
+class DefinesMoveAssignment {
+  DefinesMoveAssignment &operator=(DefinesMoveAssignment &&);
+};
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesMoveAssignment' defines a move assignment operator but does not define or delete all other special member functions [cppcoreguidelines-rule-of-five-and-zero]
+
+class DefinesNothing {
+};
+
+class DefinesEverything {
+  DefinesEverything(const DefinesEverything &);
+  DefinesEverything &operator=(const DefinesEverything &);
+  DefinesEverything(DefinesEverything &&);
+  DefinesEverything &operator=(DefinesEverything &&);
+  ~DefinesEverything();
+};
+
+class DeletesEverything {
+  DeletesEverything(const DeletesEverything &);
+  DeletesEverything &operator=(const DeletesEverything &);
+  DeletesEverything(DeletesEverything &&);
+  DeletesEverything &operator=(DeletesEverything &&);
+  ~DeletesEverything();
+};
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -29,6 +29,7 @@
cppcoreguidelines-pro-type-static-cast-downcast
cppcoreguidelines-pro-type-union-access
cppcoreguidelines-pro-type-vararg
+   cppcoreguidelines-rule-of-five-and-zero
google-build-explicit-make-pair
google-build-namespaces
google-build-using-namespace
Index: docs/clang-tidy/checks/cppcoreguidelines-rule-of-five-and-zero.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-rule-of-five-and-zero.rst
@@ -0,0 +1,21 @@
+.. title:: clang-tidy - cppcoreguidelines-rule-of-five-and-zero
+
+cppcoreguidelines-rule-of-five-and-zero
+===
+
+The check finds classes where some but not all of the special member functions
+are defined.
+
+By default the compiler defines a copy constructor, copy assignment operator,
+move constructor, move assignment operator and destructor. The default can be
+supressed by explciti user-definitions. The relationship between which
+functions will be supressed by definitions of other functions is complicated
+and it is advised that all five are defaulted or explicitly defined.
+
+Note that defining a function with ``=delete`` is considered to be a
+definition. 
+
+This rule is part of the "Constructors, assignments, and destructors" profile of the C++ Core
+Guidelines, corresponding to rule C.21. See
+
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all.
Index: clang-tidy/cppcoreguidelines/Rul

Re: [PATCH] D17990: [clang-tidy] minor improvements in modernise-deprecated-headers check

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Please update the tests according to the comment 
(https://reviews.llvm.org/D17990?id=62701#inline-186216).



Comment at: docs/clang-tidy/checks/modernize-deprecated-headers.rst:43
@@ -44,2 +42,3 @@
 headers deprecated before C++11, otherwise -- every header that appeared in
-the list.
+previous list.
+

nit: "the previous list."


https://reviews.llvm.org/D17990



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

Re: [PATCH] D21472: [clang-tidy] readability-identifier-naming - support for other case types

[Alexander Kornienko via cfe-commits]

alexfh accepted this revision.
alexfh added a comment.
This revision is now accepted and ready to land.

LG


https://reviews.llvm.org/D21472



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

Re: [PATCH] D17990: [clang-tidy] minor improvements in modernise-deprecated-headers check

[Alexander Kornienko via cfe-commits]

alexfh requested changes to this revision.
This revision now requires changes to proceed.


Comment at: clang-tidy/modernize/DeprecatedHeadersCheck.cpp:39
@@ -37,2 +38,3 @@
   llvm::StringMap CStyledHeaderToCxx;
+  std::set DeleteHeader;
 };

nit: DeleteHeaders


Comment at: clang-tidy/modernize/DeprecatedHeadersCheck.cpp:39
@@ -37,2 +38,3 @@
   llvm::StringMap CStyledHeaderToCxx;
+  std::set DeleteHeader;
 };

alexfh wrote:
> nit: DeleteHeaders
Use `llvm::StringSet`


https://reviews.llvm.org/D17990



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

RE: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Robinson, Paul via cfe-commits]

> > I think we could emulate any pre-commit hook we like via GitHub
> > WebHooks by having two repositories: llvm and llvm-staging (say).
> >
> > People push to llvm-staging, which notifies some LLVM server we own.
> > That does basic sanity checks and pushes to llvm proper if passed.
> 
> I think that would be terrible in practice, for instance how do you handle
> situations like:
> 
> 1) Dev A push commit A
> 2) Dev B push commit B that changes some lines close to the one changed by
> commit A
> 3) sanity check fails on commit A, but llvm-staging contains A and B and
> can’t get rid of A easily because B would not apply without A.
> 
> At this point Dev B gets an email (or other mechanism, I don’t know what
> you imagined) telling that his changed are rejected for no good reason.
> 
> Also reverting to a state "before A” on llvm-staging would mean that that
> the history would be rewritten and everyone that pulled/fetched in the
> meantime would suffer .
> 
> If we want to go towards pre-check using staging, I believe we should work
> with pull-request (we’d still have the issue of conflicting PR, but I
> don’t believe it’d be that bad in practice).
> That’d be welcome, but that’d also be a whole other story to setup and
> maintain!
> 
> —
> Mehdi

Hear hear.  The schemes to handle this that I'm aware of do look more like
pull requests.  You submit your change to the pre-qualification queue.
If it rebases cleanly and passes pre-qual, your change becomes the new HEAD.
If it doesn't rebase cleanly or fails pre-qual, your change gets bounced.

A pull-request-like model also helps avoid the rebase-build-test-push(fail)
loop that you can get into with a very active git-based project.  This is
a mechanical task best suited to automation rather than wasting valuable
developer time on it.  But I suspect GitHub does not have anything like
this OOB so it would be an enhancement for a later time.
--paulr

P.S. At Sony we are building a system with a "staging" step but it's not
for our own work... more of a "flood control" dam.  :-)

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

Re: [PATCH] D21567: [OpenCL] Generate struct type for sampler_t and function call for the initializer

[Anastasia Stulova via cfe-commits]

Anastasia added inline comments.


Comment at: lib/CodeGen/CodeGenModule.cpp:2399
@@ +2398,3 @@
+  // therefore no need to be translated.
+  if (getLangOpts().OpenCL && ASTTy->isSamplerT())
+return;

Could we lift this check right to the beginning of the function?


Comment at: lib/Sema/SemaInit.cpp:6917-6929
@@ -6915,4 +6916,15 @@
 << SourceType;
-  } else if (Entity.getKind() != InitializedEntity::EK_Variable) {
-llvm_unreachable("Invalid EntityKind!");
+  break;
+} else if (const DeclRefExpr *DRE = dyn_cast(Init)) {
+  auto Var = cast(DRE->getDecl());
+  if (!Var->hasGlobalStorage()) {
+CurInit = ImplicitCastExpr::Create(S.Context, Step->Type,
+   CK_LValueToRValue, 
CurInit.get(),
+   /*BasePath=*/nullptr, 
VK_RValue);
+break;
+  }
+  Init = cast(const_cast(
+Var->getInit()))->getSubExpr();
+  SourceType = Init->getType();
+}
   }

It would be nice to put some comments here summarizing your description!

Btw, I don't think it's covered in testing yet, isn't it?


Comment at: lib/Sema/SemaInit.cpp:6918
@@ +6917,3 @@
+  break;
+} else if (const DeclRefExpr *DRE = dyn_cast(Init)) {
+  auto Var = cast(DRE->getDecl());

I don't get why this level of indirection is added? Should the variable 
initialization be handled elsewhere?


Comment at: lib/Sema/SemaInit.cpp:6922
@@ +6921,3 @@
+CurInit = ImplicitCastExpr::Create(S.Context, Step->Type,
+   CK_LValueToRValue, 
CurInit.get(),
+   /*BasePath=*/nullptr, 
VK_RValue);

CurInit.get() can be changed to Init


Comment at: test/SemaOpenCL/sampler_t.cl:55
@@ -30,2 +54,2 @@
 
-sampler_t bad(); //expected-error{{declaring function return value of type 
'sampler_t' is not allowed}}
+sampler_t bad(void); //expected-error{{declaring function return value of type 
'sampler_t' is not allowed}}

Why was this change required?


https://reviews.llvm.org/D21567



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

[clang-tools-extra] r275980 - [include-fixer] A refactoring of IncludeFixerContext.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Tue Jul 19 09:49:04 2016
New Revision: 275980

URL: http://llvm.org/viewvc/llvm-project?rev=275980&view=rev
Log:
[include-fixer] A refactoring of IncludeFixerContext.

Summary:
No functional changes in this patch. It is a refactoring (pull out a
structure representing the symbol being queried).

This is a preparing step for inserting missing namespace qualifiers to all
instances of an unidentified symbol.

Reviewers: bkramer

Subscribers: cfe-commits

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

Modified:
clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
clang-tools-extra/trunk/include-fixer/IncludeFixerContext.cpp
clang-tools-extra/trunk/include-fixer/IncludeFixerContext.h
clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
clang-tools-extra/trunk/include-fixer/tool/clang-include-fixer.py
clang-tools-extra/trunk/test/include-fixer/commandline_options.cpp

Modified: clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp?rev=275980&r1=275979&r2=275980&view=diff
==
--- clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp (original)
+++ clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp Tue Jul 19 09:49:04 
2016
@@ -37,7 +37,6 @@ public:
   std::unique_ptr
   CreateASTConsumer(clang::CompilerInstance &Compiler,
 StringRef InFile) override {
-Filename = InFile;
 return llvm::make_unique();
   }
 
@@ -188,8 +187,6 @@ public:
 return clang::TypoCorrection();
   }
 
-  StringRef filename() const { return Filename; }
-
   /// Get the minimal include for a given path.
   std::string minimizeInclude(StringRef Include,
   const clang::SourceManager &SourceManager,
@@ -230,8 +227,7 @@ public:
 Symbol.getContexts(),
 Symbol.getNumOccurrences());
 }
-return IncludeFixerContext(QuerySymbol, SymbolScopedQualifiers,
-   SymbolCandidates, QuerySymbolRange);
+return IncludeFixerContext(QuerySymbolInfo, SymbolCandidates);
   }
 
 private:
@@ -252,9 +248,7 @@ private:
   .print(llvm::dbgs(), getCompilerInstance().getSourceManager()));
 DEBUG(llvm::dbgs() << " ...");
 
-QuerySymbol = Query.str();
-QuerySymbolRange = Range;
-SymbolScopedQualifiers = ScopedQualifiers;
+QuerySymbolInfo = {Query.str(), ScopedQualifiers, Range};
 
 // Query the symbol based on C++ name Lookup rules.
 // Firstly, lookup the identifier with scoped namespace contexts;
@@ -280,19 +274,8 @@ private:
   /// The client to use to find cross-references.
   SymbolIndexManager &SymbolIndexMgr;
 
-  /// The absolute path to the file being processed.
-  std::string Filename;
-
-  /// The symbol being queried.
-  std::string QuerySymbol;
-
-  /// The scoped qualifiers of QuerySymbol. It is represented as a sequence of
-  /// names and scope resolution operatiors ::, ending with a scope resolution
-  /// operator (e.g. a::b::). Empty if the symbol is not in a specific scope.
-  std::string SymbolScopedQualifiers;
-
-  /// The replacement range of the first discovered QuerySymbol.
-  tooling::Range QuerySymbolRange;
+  /// The symbol information.
+  IncludeFixerContext::QuerySymbolInfo QuerySymbolInfo;
 
   /// All symbol candidates which match QuerySymbol. We only include the first
   /// discovered identifier to avoid getting caught in results from error

Modified: clang-tools-extra/trunk/include-fixer/IncludeFixerContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/IncludeFixerContext.cpp?rev=275980&r1=275979&r2=275980&view=diff
==
--- clang-tools-extra/trunk/include-fixer/IncludeFixerContext.cpp (original)
+++ clang-tools-extra/trunk/include-fixer/IncludeFixerContext.cpp Tue Jul 19 
09:49:04 2016
@@ -75,15 +75,14 @@ std::string createQualifiedNameForReplac
 } // anonymous namespace
 
 IncludeFixerContext::IncludeFixerContext(
-llvm::StringRef Name, llvm::StringRef ScopeQualifiers,
-std::vector Symbols,
-tooling::Range Range)
-: SymbolIdentifier(Name), SymbolScopedQualifiers(ScopeQualifiers),
-  MatchedSymbols(std::move(Symbols)), SymbolRange(Range) {
+const QuerySymbolInfo &QuerySymbol,
+const std::vector Symbols)
+: MatchedSymbols(std::move(Symbols)), QuerySymbol(QuerySymbol) {
   for (const auto &Symbol : MatchedSymbols) {
-HeaderInfos.push_back({Symbol.getFilePath().str(),
-   createQualifiedNameForReplacement(
-   SymbolIdentifier, ScopeQualifiers, Symbol)});
+HeaderInfos.push_back(
+{Symbol.getFilePath().str(),
+ createQualifiedNameForReplacement(
+ QuerySymbol.RawIdent

Re: [PATCH] D22505: clang-format Access Modifier Use Normal Indent

[Daniel Jasper via cfe-commits]

djasper added a comment.

Before we continue with the actual code review and brainstorming how we could 
actually call this option, can you read through 
http://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options
 and provide feedback about why this option qualifies?


https://reviews.llvm.org/D22505



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

Re: [PATCH] D22510: [include-fixer] A refactoring of IncludeFixerContext.

[Haojian Wu via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL275980: [include-fixer] A refactoring of 
IncludeFixerContext. (authored by hokein).

Changed prior to commit:
  https://reviews.llvm.org/D22510?vs=64481&id=64502#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22510

Files:
  clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
  clang-tools-extra/trunk/include-fixer/IncludeFixerContext.cpp
  clang-tools-extra/trunk/include-fixer/IncludeFixerContext.h
  clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
  clang-tools-extra/trunk/include-fixer/tool/clang-include-fixer.py
  clang-tools-extra/trunk/test/include-fixer/commandline_options.cpp

Index: clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
===
--- clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
+++ clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
@@ -37,7 +37,6 @@
   std::unique_ptr
   CreateASTConsumer(clang::CompilerInstance &Compiler,
 StringRef InFile) override {
-Filename = InFile;
 return llvm::make_unique();
   }
 
@@ -188,8 +187,6 @@
 return clang::TypoCorrection();
   }
 
-  StringRef filename() const { return Filename; }
-
   /// Get the minimal include for a given path.
   std::string minimizeInclude(StringRef Include,
   const clang::SourceManager &SourceManager,
@@ -230,8 +227,7 @@
 Symbol.getContexts(),
 Symbol.getNumOccurrences());
 }
-return IncludeFixerContext(QuerySymbol, SymbolScopedQualifiers,
-   SymbolCandidates, QuerySymbolRange);
+return IncludeFixerContext(QuerySymbolInfo, SymbolCandidates);
   }
 
 private:
@@ -252,9 +248,7 @@
   .print(llvm::dbgs(), getCompilerInstance().getSourceManager()));
 DEBUG(llvm::dbgs() << " ...");
 
-QuerySymbol = Query.str();
-QuerySymbolRange = Range;
-SymbolScopedQualifiers = ScopedQualifiers;
+QuerySymbolInfo = {Query.str(), ScopedQualifiers, Range};
 
 // Query the symbol based on C++ name Lookup rules.
 // Firstly, lookup the identifier with scoped namespace contexts;
@@ -280,19 +274,8 @@
   /// The client to use to find cross-references.
   SymbolIndexManager &SymbolIndexMgr;
 
-  /// The absolute path to the file being processed.
-  std::string Filename;
-
-  /// The symbol being queried.
-  std::string QuerySymbol;
-
-  /// The scoped qualifiers of QuerySymbol. It is represented as a sequence of
-  /// names and scope resolution operatiors ::, ending with a scope resolution
-  /// operator (e.g. a::b::). Empty if the symbol is not in a specific scope.
-  std::string SymbolScopedQualifiers;
-
-  /// The replacement range of the first discovered QuerySymbol.
-  tooling::Range QuerySymbolRange;
+  /// The symbol information.
+  IncludeFixerContext::QuerySymbolInfo QuerySymbolInfo;
 
   /// All symbol candidates which match QuerySymbol. We only include the first
   /// discovered identifier to avoid getting caught in results from error
Index: clang-tools-extra/trunk/include-fixer/tool/clang-include-fixer.py
===
--- clang-tools-extra/trunk/include-fixer/tool/clang-include-fixer.py
+++ clang-tools-extra/trunk/include-fixer/tool/clang-include-fixer.py
@@ -127,7 +127,8 @@
 return
 
   include_fixer_context = json.loads(stdout)
-  symbol = include_fixer_context["SymbolIdentifier"]
+  query_symbol_info = include_fixer_context["QuerySymbolInfo"]
+  symbol = query_symbol_info["RawIdentifier"]
   # The header_infos is already sorted by include-fixer.
   header_infos = include_fixer_context["HeaderInfos"]
   # Deduplicate headers while keeping the order, so that the same header would
@@ -151,8 +152,7 @@
   try:
 # If there is only one suggested header, insert it directly.
 if len(unique_headers) == 1 or maximum_suggested_headers == 1:
-  InsertHeaderToVimBuffer({"SymbolIdentifier": symbol,
-   "Range": include_fixer_context["Range"],
+  InsertHeaderToVimBuffer({"QuerySymbolInfo": query_symbol_info,
"HeaderInfos": header_infos}, text)
   print "Added #include {0} for {1}.".format(unique_headers[0], symbol)
   return
@@ -163,8 +163,7 @@
   header for header in header_infos if header["Header"] == selected]
 
 # Insert a selected header.
-InsertHeaderToVimBuffer({"SymbolIdentifier": symbol,
- "Range": include_fixer_context["Range"],
+InsertHeaderToVimBuffer({"QuerySymbolInfo": query_symbol_info,
  "HeaderInfos": selected_header_infos}, text)
 print "Added #include {0} for {1}.".format(selected, symbol)
   except Exception as error:
Index: clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
=

[PATCH] D22518: Refactor how include paths are appended to the command arguments.

[Samuel Antao via cfe-commits]

sfantao created this revision.
sfantao added reviewers: tra, rsmith.
sfantao added subscribers: cfe-commits, rsmith.

This patch aims at removing redundancy in the way include paths for the regular 
and offloading toolchains are appended to the arguments list in the clang tool.

This was suggested by @rsmith in response to r275931.

https://reviews.llvm.org/D22518

Files:
  lib/Driver/Tools.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -296,56 +296,43 @@
  !O.hasFlag(options::DriverOption) && !O.hasFlag(options::LinkerInput);
 }
 
-/// Add the C++ include args of other offloading toolchains. If this is a host
-/// job, the device toolchains are added. If this is a device job, the host
-/// toolchains will be added.
-static void addExtraOffloadCXXStdlibIncludeArgs(Compilation &C,
-const JobAction &JA,
-const ArgList &Args,
-ArgStringList &CmdArgs) {
-
-  if (JA.isHostOffloading(Action::OFK_Cuda))
-C.getSingleOffloadToolChain()
-->AddClangCXXStdlibIncludeArgs(Args, CmdArgs);
-  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
-C.getSingleOffloadToolChain()
-->AddClangCXXStdlibIncludeArgs(Args, CmdArgs);
-
-  // TODO: Add support for other programming models here.
-}
-
-/// Add the C include args of other offloading toolchains. If this is a host
-/// job, the device toolchains are added. If this is a device job, the host
-/// toolchains will be added.
-static void addExtraOffloadClangSystemIncludeArgs(Compilation &C,
-  const JobAction &JA,
-  const ArgList &Args,
-  ArgStringList &CmdArgs) {
-
-  if (JA.isHostOffloading(Action::OFK_Cuda))
-C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
-Args, CmdArgs);
-  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
-C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
-Args, CmdArgs);
-
-  // TODO: Add support for other programming models here.
-}
-
-/// Add the include args that are specific of each offloading programming model.
-static void addExtraOffloadSpecificIncludeArgs(Compilation &C,
-   const JobAction &JA,
-   const ArgList &Args,
-   ArgStringList &CmdArgs) {
-
-  if (JA.isHostOffloading(Action::OFK_Cuda))
-C.getSingleOffloadToolChain()->AddCudaIncludeArgs(
-Args, CmdArgs);
-  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
-C.getSingleOffloadToolChain()->AddCudaIncludeArgs(
-Args, CmdArgs);
-
-  // TODO: Add support for other programming models here.
+/// Apply \a Work on the current tool chain \a RegularToolChain and any other
+/// offloading tool chain that is associated with the current action \a JA. If
+/// \a RegularToolChain is null, \a Work is only applied to the offloading
+/// toolchains. If an offloading kind is provided, only offloading actions of
+/// that kind are considered.
+static void forAllAssociatedToolChains(
+Compilation &C, const JobAction &JA, const ToolChain *RegularToolChain,
+llvm::function_ref Work,
+Action::OffloadKind ActiveOffloadingKind = Action::OFK_None) {
+  SmallVector RelevantToolChains;
+  // Add the current tool chain to the relevant tool chain list if it is
+  // defined.
+  if (RegularToolChain)
+RelevantToolChains.push_back(RegularToolChain);
+
+  // Add all the offloading tool chains associated with the current action to
+  // the relevant tool chain list. If we don't have a specific active offload
+  // kind, consider all available, otherwise consider only the active kind.
+  if (ActiveOffloadingKind == Action::OFK_None ||
+  ActiveOffloadingKind == Action::OFK_Cuda) {
+if (JA.isHostOffloading(Action::OFK_Cuda))
+  RelevantToolChains.push_back(
+  C.getSingleOffloadToolChain());
+else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+  RelevantToolChains.push_back(
+  C.getSingleOffloadToolChain());
+  }
+
+  //
+  // TODO: Add support for other offloading programming models here.
+  //
+
+  // Apply Work on all the relevant tool chains.
+  for (const auto *TC : RelevantToolChains) {
+assert(TC && "Undefined tool chain??");
+Work(TC);
+  }
 }
 
 void Clang::AddPreprocessingOptions(Compilation &C, const JobAction &JA,
@@ -622,22 +609,30 @@
   // of an offloading programming model.
 
   // Add C++ include arguments, if needed.
-  if (types::isCXX(Inputs[0].getType())) {
-getToolChain().AddClangCXXStdlibIncludeArgs(Args, CmdArgs);
-addExtraOffloadCXXStdlibIncludeArgs(C, JA, Args, CmdArgs);
-  }
+  if (types::isCXX(Inputs[0].getType()))
+  

Re: [PATCH] D22470: [libcxx] Improve shared_ptr dtor performance

[Ben Craig via cfe-commits]

bcraig updated the summary for this revision.
bcraig updated this revision to Diff 64504.
bcraig added a comment.

Added weak_ptr benchmark, as that's where the cost shifted.


https://reviews.llvm.org/D22470

Files:
  benchmarks/shared_ptr_create_destroy.cpp
  benchmarks/shared_ptr_inc_dec_ref.cpp
  benchmarks/weak_ptr_inc_dec_ref.cpp
  src/memory.cpp

Index: src/memory.cpp
===
--- src/memory.cpp
+++ src/memory.cpp
@@ -96,7 +96,35 @@
 void
 __shared_weak_count::__release_weak() _NOEXCEPT
 {
-if (decrement(__shared_weak_owners_) == -1)
+// NOTE: The acquire load here is an optimization of the very
+// common case where a shared pointer is being destructed while
+// having no other contended references.
+//
+// BENEFIT: We avoid expensive atomic stores like XADD and STREX
+// in a common case.  Those instructions are slow and do nasty
+// things to caches.
+//
+// IS THIS SAFE?  Yes.  During weak destruction, if we see that we
+// are the last reference, we know that no-one else is accessing
+// us. If someone were accessing us, then they would be doing so
+// while the last shared / weak_ptr was being destructed, and
+// that's undefined anyway.
+//
+// If we see anything other than a 0, then we have possible
+// contention, and need to use an atomicrmw primitive.
+// The same arguments don't apply for increment, where it is legal
+// (though inadvisable) to share shared_ptr references between
+// threads, and have them all get copied at once.  The argument
+// also doesn't apply for __release_shared, because an outstanding
+// weak_ptr::lock() could read / modify the shared count.
+if (__libcpp_atomic_load(&__shared_weak_owners_, _AO_Aquire) == 0)
+{
+// no need to do this store, because we are about
+// to destroy everything.
+//__libcpp_atomic_store(&__shared_weak_owners_, -1, _AO_Release);
+__on_zero_shared_weak();
+}
+else if (decrement(__shared_weak_owners_) == -1)
 __on_zero_shared_weak();
 }
 
Index: benchmarks/weak_ptr_inc_dec_ref.cpp
===
--- /dev/null
+++ benchmarks/weak_ptr_inc_dec_ref.cpp
@@ -0,0 +1,37 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include 
+#include 
+#include 
+#include 
+
+void clobber()
+{
+asm volatile("" : : : "memory");
+}
+
+std::atomic g_int;
+std::atomic g_other;
+
+int main() {
+  auto a = std::chrono::high_resolution_clock::now();
+  auto sp = std::make_shared(g_int.load(std::memory_order_relaxed));
+  {
+clobber();
+for (int i = 0; i < 10; ++i)
+{
+  std::weak_ptr wp(sp);
+}
+clobber();
+  }
+  auto b = std::chrono::high_resolution_clock::now();
+  std::cout<(b - a).count()/10.0<<" seconds"<
+#include 
+#include 
+#include 
+
+void clobber()
+{
+asm volatile("" : : : "memory");
+}
+
+std::atomic g_int;
+std::atomic g_other;
+
+int main() {
+  auto a = std::chrono::high_resolution_clock::now();
+  auto sp = std::make_shared(g_int.load(std::memory_order_relaxed));
+  {
+clobber();
+for (int i = 0; i < 10; ++i)
+{
+  std::shared_ptr sp2(sp);
+  g_other.store(*sp2, std::memory_order_relaxed);
+}
+clobber();
+  }
+  auto b = std::chrono::high_resolution_clock::now();
+  std::cout<(b - a).count()/10.0<<" seconds"<
+#include 
+#include 
+#include 
+
+void clobber()
+{
+asm volatile("" : : : "memory");
+}
+
+std::atomic g_int;
+std::atomic g_other;
+
+int main() {
+  auto a = std::chrono::high_resolution_clock::now();
+  {
+clobber();
+for (int i = 0; i < 10; ++i)
+{
+  auto sp = std::make_shared(g_int.load(std::memory_order_relaxed));
+  g_other.store(*sp, std::memory_order_relaxed);
+}
+clobber();
+  }
+  auto b = std::chrono::high_resolution_clock::now();
+  std::cout<(b - a).count()/10.0<<" seconds"<___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r275931 - Append clang system include path for offloading tool chains.

[Samuel F Antao via cfe-commits]

Hi Richard,
 
I posted https://reviews.llvm.org/D22518, is this more or less what you intended?
 
Thanks,
Samuel
 
- Original message -From: Richard Smith Sent by: meta...@gmail.comTo: Samuel F Antao/Watson/IBM@IBMUSCc: cfe-commits Subject: Re: r275931 - Append clang system include path for offloading tool chains.Date: Mon, Jul 18, 2016 8:29 PM 
On Mon, Jul 18, 2016 at 5:01 PM, Samuel Antao via cfe-commits  wrote:

Author: sfantaoDate: Mon Jul 18 19:01:12 2016New Revision: 275931URL: http://llvm.org/viewvc/llvm-project?rev=275931&view=revLog:Append clang system include path for offloading tool chains.Summary:This patch adds clang system include path when offloading tool chains, e.g. CUDA, are used in the current compilation.This fixes an issue detected by @rsmith in response to r275645.Reviewers: rsmith, traSubscribers: rsmith, cfe-commitsDifferential Revision: https://reviews.llvm.org/D22490Modified:    cfe/trunk/lib/Driver/Tools.cppModified: cfe/trunk/lib/Driver/Tools.cppURL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=275931&r1=275930&r2=275931&view=diff==--- cfe/trunk/lib/Driver/Tools.cpp (original)+++ cfe/trunk/lib/Driver/Tools.cpp Mon Jul 18 19:01:12 2016@@ -314,6 +314,24 @@ static void addExtraOffloadCXXStdlibIncl   // TODO: Add support for other programming models here. }+/// Add the C include args of other offloading toolchains. If this is a host+/// job, the device toolchains are added. If this is a device job, the host+/// toolchains will be added.+static void addExtraOffloadClangSystemIncludeArgs(Compilation &C,+                                                  const JobAction &JA,+                                                  const ArgList &Args,+                                                  ArgStringList &CmdArgs) {++  if (JA.isHostOffloading(Action::OFK_Cuda))+    C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(+        Args, CmdArgs);+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))+    C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(+        Args, CmdArgs);
 
We now have three copies of this code to get an aux toolchain, and we have three copies of code that calls the same function on the current toolchain and optionally on an offloading toolchain. Can we do something about this redundancy? Can we replace this duplication with something like:
 
forRegularAndOffloadToolchains(C, JA, [&](ToolChain &TC) {
  TC.AddClangSystemIncludeArgs(Args, CmdLine);
});
 
?
 
++  // TODO: Add support for other programming models here.+}+ /// Add the include args that are specific of each offloading programming model. static void addExtraOffloadSpecificIncludeArgs(Compilation &C,                                                const JobAction &JA,@@ -612,7 +630,7 @@ void Clang::AddPreprocessingOptions(Comp   // Add system include arguments for all targets but IAMCU.   if (!IsIAMCU) {     getToolChain().AddClangSystemIncludeArgs(Args, CmdArgs);-    addExtraOffloadCXXStdlibIncludeArgs(C, JA, Args, CmdArgs);+    addExtraOffloadClangSystemIncludeArgs(C, JA, Args, CmdArgs);   } else {     // For IAMCU add special include arguments.     getToolChain().AddIAMCUIncludeArgs(Args, CmdArgs);___cfe-commits mailing listcfe-commits@lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
 

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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Jonathan Roelofs via cfe-commits]

On 7/19/16 8:55 AM, Robinson, Paul wrote:

I think we could emulate any pre-commit hook we like via GitHub
WebHooks by having two repositories: llvm and llvm-staging (say).

People push to llvm-staging, which notifies some LLVM server we own.
That does basic sanity checks and pushes to llvm proper if passed.


I think that would be terrible in practice, for instance how do you handle
situations like:

1) Dev A push commit A
2) Dev B push commit B that changes some lines close to the one changed by
commit A
3) sanity check fails on commit A, but llvm-staging contains A and B and
can’t get rid of A easily because B would not apply without A.

At this point Dev B gets an email (or other mechanism, I don’t know what
you imagined) telling that his changed are rejected for no good reason.

Also reverting to a state "before A” on llvm-staging would mean that that
the history would be rewritten and everyone that pulled/fetched in the
meantime would suffer .

If we want to go towards pre-check using staging, I believe we should work
with pull-request (we’d still have the issue of conflicting PR, but I
don’t believe it’d be that bad in practice).
That’d be welcome, but that’d also be a whole other story to setup and
maintain!

—
Mehdi


Hear hear.  The schemes to handle this that I'm aware of do look more like
pull requests.  You submit your change to the pre-qualification queue.
If it rebases cleanly and passes pre-qual, your change becomes the new HEAD.
If it doesn't rebase cleanly or fails pre-qual, your change gets bounced.


Reminds me a bit of a blockchain: longest validated chain of commits wins.


Jon



A pull-request-like model also helps avoid the rebase-build-test-push(fail)
loop that you can get into with a very active git-based project.  This is
a mechanical task best suited to automation rather than wasting valuable
developer time on it.  But I suspect GitHub does not have anything like
this OOB so it would be an enhancement for a later time.
--paulr

P.S. At Sony we are building a system with a "staging" step but it's not
for our own work... more of a "flood control" dam.  :-)



--
Jon Roelofs
jonat...@codesourcery.com
CodeSourcery / Mentor Embedded
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r275985 - ClangRenameTests: Update libdeps. r275958 introduced clangASTMatchers.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue Jul 19 10:33:14 2016
New Revision: 275985

URL: http://llvm.org/viewvc/llvm-project?rev=275985&view=rev
Log:
ClangRenameTests: Update libdeps. r275958 introduced clangASTMatchers.

Modified:
clang-tools-extra/trunk/unittests/clang-rename/CMakeLists.txt

Modified: clang-tools-extra/trunk/unittests/clang-rename/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clang-rename/CMakeLists.txt?rev=275985&r1=275984&r2=275985&view=diff
==
--- clang-tools-extra/trunk/unittests/clang-rename/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/unittests/clang-rename/CMakeLists.txt Tue Jul 19 
10:33:14 2016
@@ -16,6 +16,7 @@ add_extra_unittest(ClangRenameTests
 
 target_link_libraries(ClangRenameTests
   clangAST
+  clangASTMatchers
   clangBasic
   clangFrontend
   clangIndex


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

[clang-tools-extra] r275986 - clangRename: Update libdeps to add clangASTMatchers.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue Jul 19 10:53:11 2016
New Revision: 275986

URL: http://llvm.org/viewvc/llvm-project?rev=275986&view=rev
Log:
clangRename: Update libdeps to add clangASTMatchers.

Note, ClangRenameTests is linking USRFindingAction.cpp directly.

Modified:
clang-tools-extra/trunk/clang-rename/CMakeLists.txt

Modified: clang-tools-extra/trunk/clang-rename/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-rename/CMakeLists.txt?rev=275986&r1=275985&r2=275986&view=diff
==
--- clang-tools-extra/trunk/clang-rename/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-rename/CMakeLists.txt Tue Jul 19 10:53:11 2016
@@ -8,6 +8,7 @@ add_clang_library(clangRename
 
   LINK_LIBS
   clangAST
+  clangASTMatchers
   clangBasic
   clangIndex
   clangLex


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

Re: [PATCH] D22424: [OpenCL] Fixes bug of missing OCL related metadata on the AMDGCN target

[Aaron En Ye Shi via cfe-commits]

ashi1 updated this revision to Diff 64513.
ashi1 marked an inline comment as done.
ashi1 added a comment.

Revised based on Anastasia's comments. Now using new function name 
appendOpenCLVersionMD(


Repository:
  rL LLVM

https://reviews.llvm.org/D22424

Files:
  lib/CodeGen/TargetInfo.cpp
  test/CodeGenOpenCL/spir_version.cl

Index: test/CodeGenOpenCL/spir_version.cl
===
--- test/CodeGenOpenCL/spir_version.cl
+++ test/CodeGenOpenCL/spir_version.cl
@@ -1,18 +1,31 @@
-// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CL10
-// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CL12
-// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CL20
-// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CL10
-// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CL12
-// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CL20
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CHECK-SPIR-CL10
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-SPIR-CL12
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL20
+// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CHECK-SPIR-CL10
+// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-SPIR-CL12
+// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL20
+
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - | FileCheck %s 
--check-prefix=CHECK-AMDGCN-CL10
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -cl-std=CL1.2 | 
FileCheck %s --check-prefix=CHECK-AMDGCN-CL12
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -cl-std=CL2.0 | 
FileCheck %s --check-prefix=CHECK-AMDGCN-CL20
+
 kernel void foo() {}
-// CL10: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
-// CL10: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
-// CL10: [[SPIR]] = !{i32 2, i32 0}
-// CL10: [[OCL]] = !{i32 1, i32 0}
-// CL12: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
-// CL12: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
-// CL12: [[SPIR]] = !{i32 2, i32 0}
-// CL12: [[OCL]] = !{i32 1, i32 2}
-// CL20: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
-// CL20: !opencl.ocl.version = !{[[SPIR:![0-9]+]]}
-// CL20: [[SPIR]] = !{i32 2, i32 0}
+
+// CHECK-SPIR-CL10: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
+// CHECK-SPIR-CL10: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
+// CHECK-SPIR-CL10: [[SPIR]] = !{i32 2, i32 0}
+// CHECK-SPIR-CL10: [[OCL]] = !{i32 1, i32 0}
+// CHECK-SPIR-CL12: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
+// CHECK-SPIR-CL12: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
+// CHECK-SPIR-CL12: [[SPIR]] = !{i32 2, i32 0}
+// CHECK-SPIR-CL12: [[OCL]] = !{i32 1, i32 2}
+// CHECK-SPIR-CL20: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
+// CHECK-SPIR-CL20: !opencl.ocl.version = !{[[SPIR:![0-9]+]]}
+// CHECK-SPIR-CL20: [[SPIR]] = !{i32 2, i32 0}
+
+// CHECK-AMDGCN-CL10: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
+// CHECK-AMDGCN-CL10: [[OCL]] = !{i32 1, i32 0}
+// CHECK-AMDGCN-CL12: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
+// CHECK-AMDGCN-CL12: [[OCL]] = !{i32 1, i32 2}
+// CHECK-AMDGCN-CL20: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
+// CHECK-AMDGCN-CL20: [[OCL]] = !{i32 2, i32 0}
\ No newline at end of file
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -6836,6 +6836,8 @@
 
 }
 
+static void appendOpenCLVersionMD (CodeGen::CodeGenModule &CGM);
+
 void AMDGPUTargetCodeGenInfo::setTargetAttributes(
   const Decl *D,
   llvm::GlobalValue *GV,
@@ -6857,6 +6859,8 @@
 if (NumSGPR != 0)
   F->addFnAttr("amdgpu_num_sgpr", llvm::utostr(NumSGPR));
   }
+
+  appendOpenCLVersionMD(M);
 }
 
 
@@ -7530,6 +7534,13 @@
   llvm::NamedMDNode *SPIRVerMD =
   M.getOrInsertNamedMetadata("opencl.spir.version");
   SPIRVerMD->addOperand(llvm::MDNode::get(Ctx, SPIRVerElts));
+  appendOpenCLVersionMD(CGM);
+}
+
+static void appendOpenCLVersionMD (CodeGen::CodeGenModule &CGM) {
+  llvm::LLVMContext &Ctx = CGM.getModule().getContext();
+  llvm::Type *Int32Ty = llvm::Type::getInt32Ty(Ctx);
+  llvm::Module &M = CGM.getModule();
   // SPIR v2.0 s2.13 - The OpenCL version used by the module is stored in the
   // opencl.ocl.version named metadata node.
   llvm::Metadata *OCLVerElts[] = {


Index: test/CodeGenOpe

Re: [PATCH] D22518: Refactor how include paths are appended to the command arguments.

[Artem Belevich via cfe-commits]

tra accepted this revision.
tra added a comment.
This revision is now accepted and ready to land.

Looks good.


https://reviews.llvm.org/D22518



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

Re: [PATCH] D22513: [clang-tidy] add check cppcoreguidelines-rule-of-five-and-zero

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added a subscriber: Eugene.Zelenko.
Eugene.Zelenko added a comment.

Please mention this check in docs/ReleaseNotes.rst. See pre-4.0 branch versions 
as example.



Comment at: 
docs/clang-tidy/checks/cppcoreguidelines-rule-of-five-and-zero.rst:15
@@ +14,3 @@
+
+Note that defining a function with ``=delete`` is considered to be a
+definition. 

Please add space between = and delete.


Comment at: test/clang-tidy/cppcoreguidelines-rule-of-five-and-zero.cpp:12
@@ +11,3 @@
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesCopyConstructor' 
defines a copy constructor but does not define or delete all other special 
member functions [cppcoreguidelines-rule-of-five-and-zero]
+class DefinesCopyAssignment {
+  DefinesCopyAssignment &operator=(const DefinesCopyAssignment &);

Please separate different cases with empty lines.


Comment at: test/clang-tidy/cppcoreguidelines-rule-of-five-and-zero.cpp:39
@@ +38,3 @@
+class DeletesEverything {
+  DeletesEverything(const DeletesEverything &);
+  DeletesEverything &operator=(const DeletesEverything &);

Looks like = delete is missed fall all class methods.


Repository:
  rL LLVM

https://reviews.llvm.org/D22513



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

Re: [PATCH] D22381: cppcoreguidelines-pro-bounds-constant-array-index: ignore implicit constructor

[Matthias Gehre via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL275993: cppcoreguidelines-pro-bounds-constant-array-index: 
ignore implicit constructor (authored by mgehre).

Changed prior to commit:
  https://reviews.llvm.org/D22381?vs=64035&id=64515#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22381

Files:
  
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
  
clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp

Index: 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
===
--- 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
+++ 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
@@ -45,9 +45,12 @@
   if (!getLangOpts().CPlusPlus)
 return;
 
+  // Note: if a struct contains an array member, the compiler-generated
+  // constructor has an arraySubscriptExpr.
   Finder->addMatcher(arraySubscriptExpr(hasBase(ignoringImpCasts(hasType(
 
constantArrayType().bind("type",
-hasIndex(expr().bind("index")))
+hasIndex(expr().bind("index")),
+unless(hasAncestor(isImplicit(
  .bind("expr"),
  this);
 
Index: 
clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
===
--- 
clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
+++ 
clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
@@ -74,3 +74,14 @@
   int i = 0;
   s[i] = 3; // OK, custom operator
 }
+
+struct A {
+  // The compiler-generated copy constructor uses an ArraySubscriptExpr. Don't 
warn.
+  int x[3];
+};
+
+void use_A() {
+  // Force the compiler to generate a copy constructor.
+  A a;
+  A a2(a);
+}


Index: clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
@@ -45,9 +45,12 @@
   if (!getLangOpts().CPlusPlus)
 return;
 
+  // Note: if a struct contains an array member, the compiler-generated
+  // constructor has an arraySubscriptExpr.
   Finder->addMatcher(arraySubscriptExpr(hasBase(ignoringImpCasts(hasType(
 constantArrayType().bind("type",
-hasIndex(expr().bind("index")))
+hasIndex(expr().bind("index")),
+unless(hasAncestor(isImplicit(
  .bind("expr"),
  this);
 
Index: clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
@@ -74,3 +74,14 @@
   int i = 0;
   s[i] = 3; // OK, custom operator
 }
+
+struct A {
+  // The compiler-generated copy constructor uses an ArraySubscriptExpr. Don't warn.
+  int x[3];
+};
+
+void use_A() {
+  // Force the compiler to generate a copy constructor.
+  A a;
+  A a2(a);
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r275993 - cppcoreguidelines-pro-bounds-constant-array-index: ignore implicit constructor

[Matthias Gehre via cfe-commits]

Author: mgehre
Date: Tue Jul 19 12:02:54 2016
New Revision: 275993

URL: http://llvm.org/viewvc/llvm-project?rev=275993&view=rev
Log:
cppcoreguidelines-pro-bounds-constant-array-index: ignore implicit constructor

Summary:
The code

  struct A {
int x[3];
  };

gets an compiler-generated copy constructor that uses ArraySubscriptExpr (see 
below).
Previously, the check would generate a warning on that copy constructor.
This commit disables the warning on implicitly generated code.
AST:

  |-CXXConstructorDecl 0x337b3c8  col:8 implicit used constexpr A 'void 
(const struct A &) noexcept' inline
  | |-ParmVarDecl 0x337b510  col:8 used 'const struct A &'
  | |-CXXCtorInitializer Field 0x3379238 'x' 'int [3]'
  | | `-ImplicitCastExpr 0x337e158  'int' 
  | |   `-ArraySubscriptExpr 0x337e130  'const int' lvalue
  | | |-ImplicitCastExpr 0x337e118  'const int *' 

  | | | `-MemberExpr 0x337dfc8  'int const[3]' lvalue .x 0x3379238
  | | |   `-DeclRefExpr 0x337dfa0  'const struct A' lvalue ParmVar 
0x337b510 '' 'const struct A &'
  | | `-ImplicitCastExpr 0x337e098  'unsigned long' 
  | |   `-DeclRefExpr 0x337e070  'unsigned long' lvalue Var 
0x337e010 '__i0' 'unsigned long'

Reviewers: alexfh, aaron.ballman

Subscribers: aemerson, nemanjai, cfe-commits

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

Modified:

clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp

clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp?rev=275993&r1=275992&r2=275993&view=diff
==
--- 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
 (original)
+++ 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
 Tue Jul 19 12:02:54 2016
@@ -45,9 +45,12 @@ void ProBoundsConstantArrayIndexCheck::r
   if (!getLangOpts().CPlusPlus)
 return;
 
+  // Note: if a struct contains an array member, the compiler-generated
+  // constructor has an arraySubscriptExpr.
   Finder->addMatcher(arraySubscriptExpr(hasBase(ignoringImpCasts(hasType(
 
constantArrayType().bind("type",
-hasIndex(expr().bind("index")))
+hasIndex(expr().bind("index")),
+unless(hasAncestor(isImplicit(
  .bind("expr"),
  this);
 

Modified: 
clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp?rev=275993&r1=275992&r2=275993&view=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
 (original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
 Tue Jul 19 12:02:54 2016
@@ -74,3 +74,14 @@ void customOperator() {
   int i = 0;
   s[i] = 3; // OK, custom operator
 }
+
+struct A {
+  // The compiler-generated copy constructor uses an ArraySubscriptExpr. Don't 
warn.
+  int x[3];
+};
+
+void use_A() {
+  // Force the compiler to generate a copy constructor.
+  A a;
+  A a2(a);
+}


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

Re: [PATCH] D22507: Clang-tidy - Enum misuse check

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added a subscriber: Eugene.Zelenko.
Eugene.Zelenko added a comment.

Please mention this check in docs/ReleaseNotes.rst. See pre-4.0 branch versions 
as example.



Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:116
@@ +115,3 @@
+}
+// if there is only one not power-of-2 value in the enum unless it is
+static bool isPossiblyBitField(const int NonPowOfTwoCounter, const int EnumLen,

Please separate with empty line.


Comment at: test/clang-tidy/misc-enum-misuse-weak.cpp:9
@@ +8,3 @@
+ F = 32,
+ G = 63 };
+

Please put closing }; on next line. Same in other places.


Comment at: test/clang-tidy/misc-enum-misuse-weak.cpp:83
@@ +82,3 @@
+  return 42;
+};
+

Please fix -Wextra-semi. Is next empty line excessive?


Comment at: test/clang-tidy/misc-enum-misuse.cpp:42
@@ +41,3 @@
+int trigger() {
+
+  if (bestDay() | A)

Unnecessary empty line. Same at the end of function.


Comment at: test/clang-tidy/misc-enum-misuse.cpp:77
@@ +76,2 @@
+  return 42;
+};

Please fix -Wextra-semi.


Repository:
  rL LLVM

https://reviews.llvm.org/D22507



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

Re: [PATCH] D22105: [X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using generic IR

[Eli Friedman via cfe-commits]

eli.friedman added a comment.

I don't think we need to use x86-specific operations for sitofp-like 
conversions; the C cast is equivalent given that a 32 or 64-bit integer is 
always in within the range of a 32-bit float.


Repository:
  rL LLVM

https://reviews.llvm.org/D22105



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

[libunwind] r275996 - libunwind: Use conventional DWARF capitalization in comments and errors

[Ed Maste via cfe-commits]

Author: emaste
Date: Tue Jul 19 12:15:50 2016
New Revision: 275996

URL: http://llvm.org/viewvc/llvm-project?rev=275996&view=rev
Log:
libunwind: Use conventional DWARF capitalization in comments and errors

Modified:
libunwind/trunk/include/libunwind.h
libunwind/trunk/include/mach-o/compact_unwind_encoding.h
libunwind/trunk/include/unwind.h
libunwind/trunk/src/AddressSpace.hpp
libunwind/trunk/src/DwarfInstructions.hpp
libunwind/trunk/src/DwarfParser.hpp
libunwind/trunk/src/UnwindLevel1-gcc-ext.c
libunwind/trunk/src/libunwind.cpp

Modified: libunwind/trunk/include/libunwind.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/libunwind.h?rev=275996&r1=275995&r2=275996&view=diff
==
--- libunwind/trunk/include/libunwind.h (original)
+++ libunwind/trunk/include/libunwind.h Tue Jul 19 12:15:50 2016
@@ -75,8 +75,8 @@ struct unw_proc_info_t {
   unw_word_t  gp;   /* not used */
   unw_word_t  flags;/* not used */
   uint32_tformat;   /* compact unwind encoding, or zero if none */
-  uint32_tunwind_info_size; /* size of dwarf unwind info, or zero if none 
*/
-  unw_word_t  unwind_info;  /* address of dwarf unwind info, or zero */
+  uint32_tunwind_info_size; /* size of DWARF unwind info, or zero if none 
*/
+  unw_word_t  unwind_info;  /* address of DWARF unwind info, or zero */
   unw_word_t  extra;/* mach_header of mach-o image containing func 
*/
 };
 typedef struct unw_proc_info_t unw_proc_info_t;

Modified: libunwind/trunk/include/mach-o/compact_unwind_encoding.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/mach-o/compact_unwind_encoding.h?rev=275996&r1=275995&r2=275996&view=diff
==
--- libunwind/trunk/include/mach-o/compact_unwind_encoding.h (original)
+++ libunwind/trunk/include/mach-o/compact_unwind_encoding.h Tue Jul 19 
12:15:50 2016
@@ -6,7 +6,7 @@
 // Source Licenses. See LICENSE.TXT for details.
 //
 //
-// Darwin's alternative to dwarf based unwind encodings.
+// Darwin's alternative to DWARF based unwind encodings.
 //
 
//===--===//
 
@@ -17,7 +17,7 @@
 #include 
 
 //
-// Compilers can emit standard Dwarf FDEs in the __TEXT,__eh_frame section
+// Compilers can emit standard DWARF FDEs in the __TEXT,__eh_frame section
 // of object files. Or compilers can emit compact unwind information in
 // the __LD,__compact_unwind section.
 //
@@ -26,10 +26,10 @@
 // runtime to access unwind info for any given function.  If the compiler
 // emitted compact unwind info for the function, that compact unwind info will
 // be encoded in the __TEXT,__unwind_info section. If the compiler emitted
-// dwarf unwind info, the __TEXT,__unwind_info section will contain the offset
+// DWARF unwind info, the __TEXT,__unwind_info section will contain the offset
 // of the FDE in the __TEXT,__eh_frame section in the final linked image.
 //
-// Note: Previously, the linker would transform some dwarf unwind infos into
+// Note: Previously, the linker would transform some DWARF unwind infos into
 //   compact unwind info.  But that is fragile and no longer done.
 
 
@@ -58,7 +58,7 @@ enum {
 // 1-bit: has lsda
 // 2-bit: personality index
 //
-// 4-bits: 0=old, 1=ebp based, 2=stack-imm, 3=stack-ind, 4=dwarf
+// 4-bits: 0=old, 1=ebp based, 2=stack-imm, 3=stack-ind, 4=DWARF
 //  ebp based:
 //15-bits (5*3-bits per reg) register permutation
 //8-bits for stack offset
@@ -128,9 +128,9 @@ enum {
 //UNWIND_X86_FRAMELESS_STACK_SIZE.  
 // UNWIND_X86_MODE_DWARF:
 //No compact unwind encoding is available.  Instead the low 24-bits of the
-//compact encoding is the offset of the dwarf FDE in the __eh_frame 
section.
+//compact encoding is the offset of the DWARF FDE in the __eh_frame 
section.
 //This mode is never used in object files.  It is only generated by the 
-//linker in final linked images which have only dwarf unwind info for a
+//linker in final linked images which have only DWARF unwind info for a
 //function.
 //
 // The permutation encoding is a Lehmer code sequence encoded into a
@@ -193,7 +193,7 @@ enum {
 // 1-bit: has lsda
 // 2-bit: personality index
 //
-// 4-bits: 0=old, 1=rbp based, 2=stack-imm, 3=stack-ind, 4=dwarf
+// 4-bits: 0=old, 1=rbp based, 2=stack-imm, 3=stack-ind, 4=DWARF
 //  rbp based:
 //15-bits (5*3-bits per reg) register permutation
 //8-bits for stack offset
@@ -262,9 +262,9 @@ enum {
 //UNWIND_X86_64_FRAMELESS_STACK_SIZE.  
 // UNWIND_X86_64_MODE_DWARF:
 //No compact unwind encoding is available.  Instead the low 24-bits of the
-//compact encoding is the offset of the dwarf FDE in the __eh_frame 
section.
+//compact encoding is the offset of the DWARF FDE in the __eh_frame 

Re: [PATCH] D22507: Clang-tidy - Enum misuse check

[Etienne Bergeron via cfe-commits]

etienneb added a comment.

drive-by, some comments.
Thanks for the check



Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:20
@@ +19,3 @@
+// Return the number of EnumConstantDecls in an EnumDecl.
+static int enumLen(const EnumDecl *EnumDec) {
+  int Counter = 0;

hokein wrote:
> You can use `std::distance(Enum->enumerator_begin(), Enum->enumerator_end())`.
We tend to keep name meaningful and avoid abbreviation.
enumLen -> enumLength


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:35
@@ +34,3 @@
+  ValueRange(const EnumDecl *EnumDec) {
+
+llvm::APSInt BeginVal = EnumDec->enumerator_begin()->getInitVal();

nit: remove empty line


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:55
@@ +54,3 @@
+
+bool hasCommonBit(const llvm::APSInt &Val1, const llvm::APSInt &Val2) {
+  return (Val1 & Val2).getExtValue();

nit: static


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:81
@@ +80,3 @@
+void EnumMisuseCheck::registerMatchers(MatchFinder *Finder) {
+
+  const auto enumExpr = [](StringRef RefName, StringRef DeclName) {

nit: remove empty line


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:117
@@ +116,3 @@
+// if there is only one not power-of-2 value in the enum unless it is
+static bool isPossiblyBitField(const int NonPowOfTwoCounter, const int EnumLen,
+   const ValueRange &VR, const EnumDecl *EnumDec) {

nit: const int x   --> int x   for all parameters


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:119
@@ +118,3 @@
+   const ValueRange &VR, const EnumDecl *EnumDec) {
+  return NonPowOfTwoCounter >= 1 && NonPowOfTwoCounter <= 2 && 
NonPowOfTwoCounter < enumLen(EnumDec) / 2 &&
+ (VR.MaxVal - VR.MinVal != EnumLen - 1) && !(NonPowOfTwoCounter == 1 
&& isMaxValAllBitSet(EnumDec));

nit: line too long


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:127
@@ +126,3 @@
+  // 1. case: The two enum values come from different types.
+  if (DiffEnumOp) {
+

A common pattern is:

```
if (const auto *DiffEnumOp = 
Result.Nodes.getNodeAs("diffEnumOp")) {
   [...]
}
```

This way the scope is smaller and there is less chance to use it by mistake.


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:128
@@ +127,3 @@
+  if (DiffEnumOp) {
+
+const auto *EnumDec = Result.Nodes.getNodeAs("enumDecl");

nit: no empty line


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:150
@@ +149,3 @@
+
+  if (EnumExpr) {
+if (!IsStrict)

ditto for th "if (var = ...)" pattern 


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:170
@@ +169,3 @@
+  "possibly contains misspelled "
+  "number(s) ");
+diag(EnumExpr->getExprLoc(), "Used here as a bitfield.",

nit: remove the space after (s)


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:177
@@ +176,3 @@
+  }
+  // 3. case
+  // | or + operator where both argument comes from the same enum type

To be consistent with your comments, add newline here.


Repository:
  rL LLVM

https://reviews.llvm.org/D22507



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

Re: [PATCH] D18360: Add AIX Target/ToolChain to Clang Driver

[Andrew Paprocki via cfe-commits]

apaprocki updated this revision to Diff 64518.
apaprocki added a comment.

Increased context and removed accidental inclusion of Solaris change.


https://reviews.llvm.org/D18360

Files:
  lib/Basic/Targets.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  tools/libclang/CIndexer.cpp

Index: tools/libclang/CIndexer.cpp
===
--- tools/libclang/CIndexer.cpp
+++ tools/libclang/CIndexer.cpp
@@ -37,12 +37,71 @@
 
 #ifdef LLVM_ON_WIN32
 #include 
+#elif defined(_AIX)
+#include 
+#include 
+#include 
 #else
 #include 
 #endif
 
 using namespace clang;
 
+#ifdef _AIX
+static int
+test_dir(char ret[PATH_MAX], const char *dir, const char *bin)
+{
+  struct stat sb;
+  char fullpath[PATH_MAX];
+
+  snprintf(fullpath, PATH_MAX, "%s/%s", dir, bin);
+  if (!realpath(fullpath, ret))
+return 1;
+  if (stat(fullpath, &sb) != 0)
+return 1;
+
+  return 0;
+}
+
+static char *
+getprogpath(char ret[PATH_MAX], const char *bin)
+{
+  char *pv, *s, *t;
+
+  /* First approach: absolute path. */
+  if (bin[0] == '/') {
+if (test_dir(ret, "/", bin) == 0)
+  return ret;
+return nullptr;
+  }
+
+  /* Second approach: relative path. */
+  if (strchr(bin, '/')) {
+char cwd[PATH_MAX];
+if (!getcwd(cwd, PATH_MAX))
+  return nullptr;
+if (test_dir(ret, cwd, bin) == 0)
+  return ret;
+return nullptr;
+  }
+
+  /* Third approach: $PATH */
+  if ((pv = getenv("PATH")) == nullptr)
+return nullptr;
+  s = pv = strdup(pv);
+  if (!pv)
+return nullptr;
+  while ((t = strsep(&s, ":")) != nullptr) {
+if (test_dir(ret, t, bin) == 0) {
+  free(pv);
+  return ret;
+}
+  }
+  free(pv);
+  return nullptr;
+}
+#endif
+
 const std::string &CIndexer::getClangResourcesPath() {
   // Did we already compute the path?
   if (!ResourcesPath.empty())
@@ -69,6 +128,11 @@
 #endif
 
   LibClangPath += llvm::sys::path::parent_path(path);
+#elif defined(_AIX)
+  extern char **argv;
+  char exe_path[MAXPATHLEN];
+  if (getprogpath(exe_path, argv[0]) != NULL)
+LibClangPath += llvm::sys::path::parent_path(exe_path);
 #else
   // This silly cast below avoids a C++ warning.
   Dl_info info;
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -652,6 +652,34 @@
 };
 } // end namespace solaris
 
+/// aix -- Directly call AIX assembler and linker
+namespace aix {
+class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
+public:
+  Assembler(const ToolChain &TC) : Tool("aix::Assembler", "assembler", TC) {}
+
+  bool hasIntegratedCPP() const override { return false; }
+
+  void ConstructJob(Compilation &C, const JobAction &JA,
+const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::opt::ArgList &TCArgs,
+const char *LinkingOutput) const override;
+};
+
+class LLVM_LIBRARY_VISIBILITY Linker : public Tool {
+public:
+  Linker(const ToolChain &TC) : Tool("aix::Linker", "linker", TC) {}
+
+  bool hasIntegratedCPP() const override { return false; }
+  bool isLinkJob() const override { return true; }
+
+  void ConstructJob(Compilation &C, const JobAction &JA,
+const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::opt::ArgList &TCArgs,
+const char *LinkingOutput) const override;
+};
+}  // end namespace aix
+
 /// dragonfly -- Directly call GNU Binutils assembler and linker
 namespace dragonfly {
 class LLVM_LIBRARY_VISIBILITY Assembler : public GnuTool {
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -5452,6 +5452,7 @@
   options::OPT_fuse_cxa_atexit, options::OPT_fno_use_cxa_atexit,
   !IsWindowsCygnus && !IsWindowsGNU &&
   getToolChain().getTriple().getOS() != llvm::Triple::Solaris &&
+  getToolChain().getTriple().getOS() != llvm::Triple::AIX &&
   getToolChain().getArch() != llvm::Triple::hexagon &&
   getToolChain().getArch() != llvm::Triple::xcore &&
   ((getToolChain().getTriple().getVendor() !=
@@ -8102,6 +8103,94 @@
   C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
 }
 
+void aix::Assembler::ConstructJob(Compilation &C, const JobAction &JA,
+  const InputInfo &Output,
+  const InputInfoList &Inputs,
+  const ArgList &Args,
+  const char *LinkingOutput) const {
+  claimNoWarnArgs(Args);
+  ArgStringList CmdArgs;
+
+  Args.AddAllArgValues(CmdArgs, options::OPT_Wa_COMMA, options::OPT_Xassembler);
+
+  CmdArgs.push_back("-o");
+  CmdArgs.push_back(Output.getFilename());
+
+  for (const auto &II : Inputs)
+CmdArgs.p

Re: [PATCH] D22105: [X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using generic IR

[Simon Pilgrim via cfe-commits]

RKSimon added a comment.

In https://reviews.llvm.org/D22105#488513, @eli.friedman wrote:

> I don't think we need to use x86-specific operations for sitofp-like 
> conversions; the C cast is equivalent given that a 32 or 64-bit integer is 
> always in within the range of a 32-bit float.


I think the only situation that lossless conversion occurs is i32->f64, every 
other sitofp conversion could be affected by the rounding control no?


Repository:
  rL LLVM

https://reviews.llvm.org/D22105



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

[libunwind] r275997 - libunwind: sync some coments with NetBSD's version

[Ed Maste via cfe-commits]

Author: emaste
Date: Tue Jul 19 12:28:38 2016
New Revision: 275997

URL: http://llvm.org/viewvc/llvm-project?rev=275997&view=rev
Log:
libunwind: sync some coments with NetBSD's version

NetBSD's system unwinder is a modified version of LLVM's libunwind.
Slightly reduce diffs by updating comments to match theirs where
appropriate.

Modified:
libunwind/trunk/src/DwarfParser.hpp

Modified: libunwind/trunk/src/DwarfParser.hpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/DwarfParser.hpp?rev=275997&r1=275996&r2=275997&view=diff
==
--- libunwind/trunk/src/DwarfParser.hpp (original)
+++ libunwind/trunk/src/DwarfParser.hpp Tue Jul 19 12:28:38 2016
@@ -138,23 +138,23 @@ const char *CFI_Parser::decodeFDE(A &
   if (err != NULL)
 return err;
   p += 4;
-  // parse pc begin and range
+  // Parse pc begin and range.
   pint_t pcStart =
   addressSpace.getEncodedP(p, nextCFI, cieInfo->pointerEncoding);
   pint_t pcRange =
   addressSpace.getEncodedP(p, nextCFI, cieInfo->pointerEncoding & 0x0F);
-  // parse rest of info
+  // Parse rest of info.
   fdeInfo->lsda = 0;
-  // check for augmentation length
+  // Check for augmentation length.
   if (cieInfo->fdesHaveAugmentationData) {
 pint_t augLen = (pint_t)addressSpace.getULEB128(p, nextCFI);
 pint_t endOfAug = p + augLen;
 if (cieInfo->lsdaEncoding != DW_EH_PE_omit) {
-  // peek at value (without indirection).  Zero means no lsda
+  // Peek at value (without indirection).  Zero means no LSDA.
   pint_t lsdaStart = p;
   if (addressSpace.getEncodedP(p, nextCFI, cieInfo->lsdaEncoding & 0x0F) !=
   0) {
-// reset pointer and re-parse lsda address
+// Reset pointer and re-parse LSDA address.
 p = lsdaStart;
 fdeInfo->lsda =
 addressSpace.getEncodedP(p, nextCFI, cieInfo->lsdaEncoding);
@@ -192,23 +192,23 @@ bool CFI_Parser::findFDE(A &addressSp
   return false; // end marker
 uint32_t id = addressSpace.get32(p);
 if (id == 0) {
-  // skip over CIEs
+  // Skip over CIEs.
   p += cfiLength;
 } else {
-  // process FDE to see if it covers pc
+  // Process FDE to see if it covers pc.
   pint_t nextCFI = p + cfiLength;
   uint32_t ciePointer = addressSpace.get32(p);
   pint_t cieStart = p - ciePointer;
-  // validate pointer to CIE is within section
+  // Validate pointer to CIE is within section.
   if ((ehSectionStart <= cieStart) && (cieStart < ehSectionEnd)) {
 if (parseCIE(addressSpace, cieStart, cieInfo) == NULL) {
   p += 4;
-  // parse pc begin and range
+  // Parse pc begin and range.
   pint_t pcStart =
   addressSpace.getEncodedP(p, nextCFI, cieInfo->pointerEncoding);
   pint_t pcRange = addressSpace.getEncodedP(
   p, nextCFI, cieInfo->pointerEncoding & 0x0F);
-  // test if pc is within the function this FDE covers
+  // Test if pc is within the function this FDE covers.
   if ((pcStart < pc) && (pc <= pcStart + pcRange)) {
 // parse rest of info
 fdeInfo->lsda = 0;
@@ -217,11 +217,11 @@ bool CFI_Parser::findFDE(A &addressSp
   pint_t augLen = (pint_t)addressSpace.getULEB128(p, nextCFI);
   pint_t endOfAug = p + augLen;
   if (cieInfo->lsdaEncoding != DW_EH_PE_omit) {
-// peek at value (without indirection).  Zero means no lsda
+// Peek at value (without indirection).  Zero means no LSDA.
 pint_t lsdaStart = p;
 if (addressSpace.getEncodedP(
 p, nextCFI, cieInfo->lsdaEncoding & 0x0F) != 0) {
-  // reset pointer and re-parse lsda address
+  // Reset pointer and re-parse LSDA address.
   p = lsdaStart;
   fdeInfo->lsda = addressSpace
   .getEncodedP(p, nextCFI, cieInfo->lsdaEncoding);
@@ -239,7 +239,7 @@ bool CFI_Parser::findFDE(A &addressSp
 // pc is not in begin/range, skip this FDE
   }
 } else {
-  // malformed CIE, now augmentation describing pc range encoding
+  // Malformed CIE, now augmentation describing pc range encoding.
 }
   } else {
 // malformed FDE.  CIE is bad


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

Re: [PATCH] D22105: [X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using generic IR

[Eli Friedman via cfe-commits]

eli.friedman added a comment.

The x86-specific operation is affected by the rounding mode... but so is a C 
cast.  This is specified by Annex F in the C standard.

Of course, you're going to end up with undefined behavior if you actually 
modify the rounding mode because LLVM and clang don't support FENV_ACCESS at 
the moment.


Repository:
  rL LLVM

https://reviews.llvm.org/D22105



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

Re: [PATCH] D18360: Add AIX Target/ToolChain to Clang Driver

[David Majnemer via cfe-commits]

majnemer accepted this revision.
majnemer added a reviewer: majnemer.
majnemer added a comment.
This revision is now accepted and ready to land.

LGTM


https://reviews.llvm.org/D18360



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

Re: [PATCH] D19544: Pass for translating math intrinsics to math library calls.

[Matt via cfe-commits]

mmasten added a comment.

In the process of writing test cases, I noticed that a loop with a call to 
llvm.log.f32 was not getting vectorized due to cost modeling. When forcing 
vectorization on the loop and throwing -fveclib=SVML, the loop was vectorized 
with a widened intrinsic instead of the svml call. Is this correct? I would 
have expected to get the svml call. In light of this, wouldn't it be better to 
represent the math calls with vector intrinsics and let CodeGenPrepare or the 
backends decide how to lower them?

Thanks,

Matt


https://reviews.llvm.org/D19544



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

Re: [PATCH] D21962: MPITypeMismatchCheck for Clang-Tidy

[Alexander Droste via cfe-commits]

Alexander_Droste marked 2 inline comments as done.
Alexander_Droste added a comment.

Thanks for looking over this once more. I'll set up an extra MPI folder and 
rename the check.

One comment inline.



Comment at: clang-tidy/misc/MpiTypeMismatchCheck.cpp:218
@@ +217,3 @@
+
+  StringRef TypedefToCompare = Typedef->getDecl()->getQualifiedNameAsString();
+  // Check if the typedef is known and not matching the MPI datatype.

alexfh wrote:
> `getQualifiedNameAsString` returns a `std::string`, which will be destroyed 
> at the end of this statement. `TypedefToCompare` will be a dangling reference 
> then. Please change `StringRef` to `std::string` here.
> 
> Another question is whether you need `getQualifiedNameAsString`, which is 
> rather expensive. Maybe you could use `getName` (it returns a `StringRef` and 
> is relatively cheap) and additionally check that the name is in the global 
> namespace?
No, it seems I can also simply use `getName`. Why is it necessary to check if 
the name is in the global namespace? How would that check look like? 


https://reviews.llvm.org/D21962



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

Re: [PATCH] D20786: Fix undefined behavior in __tree

[Eric Fiselier via cfe-commits]

EricWF updated this revision to Diff 64525.
EricWF added a comment.

Add test for PR28469 and remove __tree from the UBSAN blacklist.


https://reviews.llvm.org/D20786

Files:
  include/__config
  include/__tree
  test/libcxx/containers/associative/tree_balance_after_insert.pass.cpp
  test/libcxx/containers/associative/tree_left_rotate.pass.cpp
  test/libcxx/containers/associative/tree_remove.pass.cpp
  test/libcxx/containers/associative/tree_right_rotate.pass.cpp
  test/std/containers/associative/map/PR28469_undefined_behavior_segfault.sh.cpp
  test/ubsan_blacklist.txt

Index: test/ubsan_blacklist.txt
===
--- test/ubsan_blacklist.txt
+++ test/ubsan_blacklist.txt
@@ -1,2 +1 @@
-fun:*__tree*
 fun:*__hash_table*
Index: test/std/containers/associative/map/PR28469_undefined_behavior_segfault.sh.cpp
===
--- /dev/null
+++ test/std/containers/associative/map/PR28469_undefined_behavior_segfault.sh.cpp
@@ -0,0 +1,31 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// RUN: %build -O2
+// RUN: %run
+
+// 
+
+// Previously this code caused a segfault when compiled at -O2 due to undefined
+// behavior in __tree. See https://llvm.org/bugs/show_bug.cgi?id=28469
+
+#include 
+#include 
+
+void dummy() {}
+
+struct F {
+std::map > m;
+F() { m[42] = &dummy; }
+};
+
+int main() {
+F f;
+f = F();
+}
Index: test/libcxx/containers/associative/tree_right_rotate.pass.cpp
===
--- test/libcxx/containers/associative/tree_right_rotate.pass.cpp
+++ test/libcxx/containers/associative/tree_right_rotate.pass.cpp
@@ -23,6 +23,9 @@
 Node* __right_;
 Node* __parent_;
 
+Node* __parent_unsafe() const { return __parent_; }
+void __set_parent(Node* x) { __parent_ = x;}
+
 Node() : __left_(), __right_(), __parent_() {}
 };
 
Index: test/libcxx/containers/associative/tree_remove.pass.cpp
===
--- test/libcxx/containers/associative/tree_remove.pass.cpp
+++ test/libcxx/containers/associative/tree_remove.pass.cpp
@@ -24,6 +24,9 @@
 Node* __parent_;
 bool __is_black_;
 
+Node* __parent_unsafe() const { return __parent_; }
+void __set_parent(Node* x) { __parent_ = x;}
+
 Node() : __left_(), __right_(), __parent_(), __is_black_() {}
 };
 
Index: test/libcxx/containers/associative/tree_left_rotate.pass.cpp
===
--- test/libcxx/containers/associative/tree_left_rotate.pass.cpp
+++ test/libcxx/containers/associative/tree_left_rotate.pass.cpp
@@ -23,6 +23,9 @@
 Node* __right_;
 Node* __parent_;
 
+Node* __parent_unsafe() const { return __parent_; }
+void __set_parent(Node* x) { __parent_ = x;}
+
 Node() : __left_(), __right_(), __parent_() {}
 };
 
Index: test/libcxx/containers/associative/tree_balance_after_insert.pass.cpp
===
--- test/libcxx/containers/associative/tree_balance_after_insert.pass.cpp
+++ test/libcxx/containers/associative/tree_balance_after_insert.pass.cpp
@@ -24,6 +24,9 @@
 Node* __parent_;
 bool __is_black_;
 
+Node* __parent_unsafe() const { return __parent_; }
+void __set_parent(Node* x) { __parent_ = x;}
+
 Node() : __left_(), __right_(), __parent_(), __is_black_() {}
 };
 
Index: include/__tree
===
--- include/__tree
+++ include/__tree
@@ -165,21 +165,36 @@
 if (__x->__right_ != nullptr)
 return __tree_min(__x->__right_);
 while (!__tree_is_left_child(__x))
-__x = __x->__parent_;
-return __x->__parent_;
+__x = __x->__parent_unsafe();
+return __x->__parent_unsafe();
+}
+
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+_EndNodePtr
+__tree_next_iter(_NodePtr __x) _NOEXCEPT
+{
+if (__x->__right_ != nullptr)
+return static_cast<_EndNodePtr>(__tree_min(__x->__right_));
+while (!__tree_is_left_child(__x))
+__x = __x->__parent_unsafe();
+return static_cast<_EndNodePtr>(__x->__parent_);
 }
 
 // Returns:  pointer to the previous in-order node before __x.
 // Precondition:  __x != nullptr.
-template 
+// Note: __x may be the end node.
+template 
+inline _LIBCPP_INLINE_VISIBILITY
 _NodePtr
-__tree_prev(_NodePtr __x) _NOEXCEPT
+__tree_prev_iter(_EndNodePtr __x) _NOEXCEPT
 {
 if (__x->__left_ != nullptr)
 return __tree_max(__x->__left_);
-while (__tree_is_left_child(__x))
-__x = __x->__parent_;
-return __x->

[libcxx] r276003 - Fix undefined behavior in __tree

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Jul 19 12:56:20 2016
New Revision: 276003

URL: http://llvm.org/viewvc/llvm-project?rev=276003&view=rev
Log:
Fix undefined behavior in __tree

Summary:
This patch attempts to fix the undefined behavior in __tree by changing the 
node pointer types used throughout. The pointer types are changed for raw 
pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy 
pointer types may not be ABI compatible).

The UB in `__tree` arises because tree downcasts the embedded end node and then 
deferences that pointer. Currently there are 3 node types in __tree.

* `__tree_end_node` which contains the `__left_` pointer. This node is embedded 
within the container.
* `__tree_node_base` which contains `__right_`, `__parent_` and `__is_black`. 
This node is used throughout the tree rebalancing algorithms.
* `__tree_node` which contains `__value_`.

Currently `__tree` stores the start of the tree, `__begin_node_`, as a pointer 
to a `__tree_node`. Additionally the iterators store their position as a 
pointer to a `__tree_node`. In both of these cases the pointee can be the end 
node. This is fixed by changing them to store `__tree_end_node` pointers 
instead.

To make this change I introduced an `__iter_pointer` typedef which is defined 
to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node` in 
the current one.
Both `__tree::__begin_node_` and iterator pointers are now stored as 
`__iter_pointers`.

The other situation where `__tree_end_node` is stored as the wrong type is in 
`__tree_node_base::__parent_`.  Currently `__left_`, `__right_`, and 
`__parent_` are all `__tree_node_base` pointers. Since the end node will only 
be stored in `__parent_` the fix is to change `__parent_` to be a pointer to 
`__tree_end_node`.

To make this change I introduced a `__parent_pointer` typedef which is defined 
to be a pointer to either `__tree_end_node` in the new ABI or 
`__tree_node_base` in the current one.

Note that in the new ABI `__iter_pointer` and `__parent_pointer` are the same 
type (but not in the old one). The confusion between these two types is 
unfortunate but it was the best solution I could come up with that maintains 
the ABI.

The typedef changes force a ton of explicit type casts to correct pointer types 
and to make current code compatible with both the old and new pointer typedefs. 
This is the bulk of the change and it's really messy. Unfortunately I don't 
know how to avoid it.

Please let me know what you think.





Reviewers: howard.hinnant, mclow.lists

Subscribers: howard.hinnant, bbannier, cfe-commits

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

Added:

libcxx/trunk/test/std/containers/associative/map/PR28469_undefined_behavior_segfault.sh.cpp
Modified:
libcxx/trunk/include/__config
libcxx/trunk/include/__tree

libcxx/trunk/test/libcxx/containers/associative/tree_balance_after_insert.pass.cpp
libcxx/trunk/test/libcxx/containers/associative/tree_left_rotate.pass.cpp
libcxx/trunk/test/libcxx/containers/associative/tree_remove.pass.cpp
libcxx/trunk/test/libcxx/containers/associative/tree_right_rotate.pass.cpp
libcxx/trunk/test/ubsan_blacklist.txt

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=276003&r1=276002&r2=276003&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Tue Jul 19 12:56:20 2016
@@ -41,6 +41,8 @@
 #define _LIBCPP_ABI_INCOMPLETE_TYPES_IN_DEQUE
 // Fix undefined behavior in how std::list stores it's linked nodes.
 #define _LIBCPP_ABI_LIST_REMOVE_NODE_POINTER_UB
+// Fix undefined behavior in  how __tree stores its end and parent nodes.
+#define _LIBCPP_ABI_TREE_REMOVE_NODE_POINTER_UB
 #define _LIBCPP_ABI_FORWARD_LIST_REMOVE_NODE_POINTER_UB
 #define _LIBCPP_ABI_FIX_UNORDERED_CONTAINER_SIZE_TYPE
 #define _LIBCPP_ABI_VARIADIC_LOCK_GUARD

Modified: libcxx/trunk/include/__tree
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tree?rev=276003&r1=276002&r2=276003&view=diff
==
--- libcxx/trunk/include/__tree (original)
+++ libcxx/trunk/include/__tree Tue Jul 19 12:56:20 2016
@@ -165,21 +165,36 @@ __tree_next(_NodePtr __x) _NOEXCEPT
 if (__x->__right_ != nullptr)
 return __tree_min(__x->__right_);
 while (!__tree_is_left_child(__x))
-__x = __x->__parent_;
-return __x->__parent_;
+__x = __x->__parent_unsafe();
+return __x->__parent_unsafe();
+}
+
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+_EndNodePtr
+__tree_next_iter(_NodePtr __x) _NOEXCEPT
+{
+if (__x->__right_ != nullptr)
+return static_cast<_EndNodePtr>(__tree_min(__x->__right_));
+while (!__tree_is_left_child(__x))
+__x = __x->__parent_unsafe();
+return static_cast<_EndNodePtr>(__x->__parent_);
 }
 

Re: [PATCH] D19544: Pass for translating math intrinsics to math library calls.

[Sanjay Patel via cfe-commits]

spatel added a subscriber: davide.
spatel added a comment.

In https://reviews.llvm.org/D19544#488589, @mmasten wrote:

> In the process of writing test cases, I noticed that a loop with a call to 
> llvm.log.f32 was not getting vectorized due to cost modeling. When forcing 
> vectorization on the loop and throwing -fveclib=SVML, the loop was vectorized 
> with a widened intrinsic instead of the svml call. Is this correct? I would 
> have expected to get the svml call. In light of this, wouldn't it be better 
> to represent the math calls with vector intrinsics and let CodeGenPrepare or 
> the backends decide how to lower them?


I don't know the answer, but I'm curious about this too for an unrelated change 
in LibCallSimplifier (cc @davide).

The LangRef has this boilerplate for all target-independent math intrinsics:
"Not all targets support all types however."

Is that only intended for the weird types (x86_fp80, ppc_fp128, fp128?), or 
does it mean that we shouldn't create these intrinsics for vectors with 
standard FP types (eg, v4f32)?


https://reviews.llvm.org/D19544



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

[PATCH] D22523: [OpenCL] AMDGCN target will generate images in constant address space

[Aaron En Ye Shi via cfe-commits]

ashi1 created this revision.
ashi1 added reviewers: yaxunl, Anastasia.
ashi1 added a subscriber: cfe-commits.
ashi1 set the repository for this revision to rL LLVM.

Allows AMDGCN target to generate images (such as %opencl.image2d_t) in constant 
address space.
Images will still be generated in global address space by default. 

Added tests to existing opencl-types.cl in test\CodeGenOpenCL

Repository:
  rL LLVM

https://reviews.llvm.org/D22523

Files:
  lib/CodeGen/CGOpenCLRuntime.cpp
  lib/CodeGen/TargetInfo.cpp
  lib/CodeGen/TargetInfo.h
  test/CodeGenOpenCL/opencl_types.cl

Index: test/CodeGenOpenCL/opencl_types.cl
===
--- test/CodeGenOpenCL/opencl_types.cl
+++ test/CodeGenOpenCL/opencl_types.cl
@@ -1,40 +1,49 @@
-// RUN: %clang_cc1 %s -emit-llvm -o - -O0 | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -o - -O0 | FileCheck %s --check-prefix=CHECK-NORMAL
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -O0 | FileCheck %s --check-prefix=CHECK-AMDGCN
 
 constant sampler_t glb_smp = 7;
-// CHECK: constant i32 7
+// CHECK-NORMAL: constant i32 7
+// CHECK-AMDGCN: addrspace(2) constant i32 7
 
 void fnc1(image1d_t img) {}
-// CHECK: @fnc1(%opencl.image1d_ro_t*
+// CHECK-NORMAL: @fnc1(%opencl.image1d_ro_t*
+// CHECK-AMDGCN: @fnc1(%opencl.image1d_ro_t addrspace(2)*
 
 void fnc1arr(image1d_array_t img) {}
-// CHECK: @fnc1arr(%opencl.image1d_array_ro_t*
+// CHECK-NORMAL: @fnc1arr(%opencl.image1d_array_ro_t*
+// CHECK-AMDGCN: @fnc1arr(%opencl.image1d_array_ro_t addrspace(2)*
 
 void fnc1buff(image1d_buffer_t img) {}
-// CHECK: @fnc1buff(%opencl.image1d_buffer_ro_t*
+// CHECK-NORMAL: @fnc1buff(%opencl.image1d_buffer_ro_t*
+// CHECK-AMDGCN: @fnc1buff(%opencl.image1d_buffer_ro_t addrspace(2)*
 
 void fnc2(image2d_t img) {}
-// CHECK: @fnc2(%opencl.image2d_ro_t*
+// CHECK-NORMAL: @fnc2(%opencl.image2d_ro_t*
+// CHECK-AMDGCN: @fnc2(%opencl.image2d_ro_t addrspace(2)*
 
 void fnc2arr(image2d_array_t img) {}
-// CHECK: @fnc2arr(%opencl.image2d_array_ro_t*
+// CHECK-NORMAL: @fnc2arr(%opencl.image2d_array_ro_t*
+// CHECK-AMDGCN: @fnc2arr(%opencl.image2d_array_ro_t addrspace(2)*
 
 void fnc3(image3d_t img) {}
-// CHECK: @fnc3(%opencl.image3d_ro_t*
+// CHECK-NORMAL: @fnc3(%opencl.image3d_ro_t*
+// CHECK-AMDGCN: @fnc3(%opencl.image3d_ro_t addrspace(2)*
 
 void fnc4smp(sampler_t s) {}
-// CHECK-LABEL: define {{.*}}void @fnc4smp(i32
+// CHECK-NORMAL-LABEL: define {{.*}}void @fnc4smp(i32
 
 kernel void foo(image1d_t img) {
   sampler_t smp = 5;
-  // CHECK: alloca i32
+  // CHECK-NORMAL: alloca i32
   event_t evt;
-  // CHECK: alloca %opencl.event_t*
-  // CHECK: store i32 5,
+  // CHECK-NORMAL: alloca %opencl.event_t*
+  // CHECK-NORMAL: store i32 5,
   fnc4smp(smp);
-  // CHECK: call {{.*}}void @fnc4smp(i32
+  // CHECK-NORMAL: call {{.*}}void @fnc4smp(i32
   fnc4smp(glb_smp);
-  // CHECK: call {{.*}}void @fnc4smp(i32
+  // CHECK-NORMAL: call {{.*}}void @fnc4smp(i32
 }
 
 void __attribute__((overloadable)) bad1(image1d_t b, image2d_t c, image2d_t d) {}
-// CHECK-LABEL: @{{_Z4bad114ocl_image1d_ro14ocl_image2d_roS0_|"\\01\?bad1@@\$\$J0YAXPAUocl_image1d_ro@@PAUocl_image2d_ro@@1@Z"}}
+// CHECK-NORMAL-LABEL: @{{_Z4bad114ocl_image1d_ro14ocl_image2d_roS0_|"\\01\?bad1@@\$\$J0YAXPAUocl_image1d_ro@@PAUocl_image2d_ro@@1@Z"}}
+// CHECK-AMDGCN-LABEL: @{{_Z4bad114ocl_image1d_ro14ocl_image2d_roS0_|"\\01\?bad1@@\$\$J0YAXPAUocl_image1d_ro@@PAUocl_image2d_ro@@1@Z"}}(%opencl.image1d_ro_t addrspace(2)*{{.*}}%opencl.image2d_ro_t addrspace(2)*{{.*}}%opencl.image2d_ro_t addrspace(2)*{{.*}})
Index: lib/CodeGen/TargetInfo.h
===
--- lib/CodeGen/TargetInfo.h
+++ lib/CodeGen/TargetInfo.h
@@ -220,6 +220,9 @@
 
   /// Get LLVM calling convention for OpenCL kernel.
   virtual unsigned getOpenCLKernelCallingConv() const;
+
+  /// Get LLVM Image Address Space for OpenCL kernel.
+  virtual unsigned getOpenCLImageAddrSpace(CodeGen::CodeGenModule &CGM) const;
 };
 
 } // namespace CodeGen
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -375,6 +375,11 @@
 unsigned TargetCodeGenInfo::getOpenCLKernelCallingConv() const {
   return llvm::CallingConv::C;
 }
+
+unsigned TargetCodeGenInfo::getOpenCLImageAddrSpace(CodeGen::CodeGenModule &CGM) const {
+  return CGM.getContext().getTargetAddressSpace(LangAS::opencl_global);
+}
+
 static bool isEmptyRecord(ASTContext &Context, QualType T, bool AllowArrays);
 
 /// isEmptyField - Return true iff a the field is "empty", that is it
@@ -6832,6 +6832,7 @@
   void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
CodeGen::CodeGenModule &M) const override;
   unsigned getOpenCLKernelCallingConv() const override;
+  unsigned getOpenCLImageAddrSpace(CodeGen::CodeGenModule &CGM) const override;
 };
 
 }
@@ -6864,6 +6864,10 @@
   return llvm:

Re: [PATCH] D20168: [CodeGen] Handle structs directly in AMDGPUABIInfo

[Matt Arsenault via cfe-commits]

arsenm added inline comments.


Comment at: lib/CodeGen/TargetInfo.cpp:6856
@@ +6855,3 @@
+  }
+  else if (StrTy->getNumElements() == 1) {
+// Coerce single element structs to its element.

No else after return


Comment at: test/CodeGenOpenCL/amdgpu-abi-struct-coerce.cl:62
@@ +61,3 @@
+// CHECK-LABEL: @test_non_kernel_struct_arg
+// CHECK-NOT: %struct.struct_arg %arg1.coerce
+void test_non_kernel_struct_arg(struct_arg_t arg1)

Positive checks are greatly preferred 


https://reviews.llvm.org/D20168



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

Re: [PATCH] D21567: [OpenCL] Generate struct type for sampler_t and function call for the initializer

[Yaxun Liu via cfe-commits]

yaxunl updated this revision to Diff 64529.
yaxunl marked 7 inline comments as done.
yaxunl added a comment.

Revised by Anastasia's comments.


https://reviews.llvm.org/D21567

Files:
  include/clang/AST/OperationKinds.def
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/AST/ASTContext.cpp
  lib/AST/Expr.cpp
  lib/AST/ExprConstant.cpp
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CGDebugInfo.h
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CGExprAgg.cpp
  lib/CodeGen/CGExprComplex.cpp
  lib/CodeGen/CGExprConstant.cpp
  lib/CodeGen/CGExprScalar.cpp
  lib/CodeGen/CGOpenCLRuntime.cpp
  lib/CodeGen/CGOpenCLRuntime.h
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Edit/RewriteObjCFoundationAPI.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaInit.cpp
  lib/StaticAnalyzer/Core/ExprEngineC.cpp
  test/CodeGenOpenCL/opencl_types.cl
  test/CodeGenOpenCL/sampler.cl
  test/SemaOpenCL/sampler_t.cl

Index: test/SemaOpenCL/sampler_t.cl
===
--- test/SemaOpenCL/sampler_t.cl
+++ test/SemaOpenCL/sampler_t.cl
@@ -1,6 +1,25 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -DCHECK_SAMPLER_VALUE -Wspir-compat -triple amdgcn--amdhsa
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -DCHECK_SAMPLER_VALUE -triple spir-unknown-unknown
 
-constant sampler_t glb_smp = 5;
+#define CLK_ADDRESS_CLAMP_TO_EDGE   2
+#define CLK_NORMALIZED_COORDS_TRUE  1
+#define CLK_FILTER_NEAREST  0x10
+#define CLK_FILTER_LINEAR   0x20
+
+constant sampler_t glb_smp = CLK_ADDRESS_CLAMP_TO_EDGE | CLK_NORMALIZED_COORDS_TRUE | CLK_FILTER_LINEAR;
+constant sampler_t glb_smp2; // expected-error{{variable in constant address space must be initialized}}
+global sampler_t glb_smp3 = CLK_ADDRESS_CLAMP_TO_EDGE | CLK_NORMALIZED_COORDS_TRUE | CLK_FILTER_NEAREST; // expected-error{{sampler type cannot be used with the __local and __global address space qualifiers}}
+
+constant sampler_t glb_smp4 = 0;
+#ifdef CHECK_SAMPLER_VALUE
+// expected-warning@-2{{sampler initializer has invalid Filter Mode bits}}
+#endif
+
+constant sampler_t glb_smp5 = 0x1f;
+#ifdef CHECK_SAMPLER_VALUE
+// expected-warning@-2{{sampler initializer has invalid Addressing Mode bits}}
+#endif
 
 void foo(sampler_t);
 
@@ -10,22 +29,27 @@
 
 void kernel ker(sampler_t argsmp) {
   local sampler_t smp; // expected-error{{sampler type cannot be used with the __local and __global address space qualifiers}}
-  const sampler_t const_smp = 7;
+  const sampler_t const_smp = CLK_ADDRESS_CLAMP_TO_EDGE | CLK_NORMALIZED_COORDS_TRUE | CLK_FILTER_LINEAR;
+  const sampler_t const_smp2;
   foo(glb_smp);
+  foo(glb_smp2);
+  foo(glb_smp3);
   foo(const_smp);
+  foo(const_smp2);
+  foo(argsmp);
   foo(5); // expected-error{{sampler_t variable required - got 'int'}}
   sampler_t sa[] = {argsmp, const_smp}; // expected-error {{array of 'sampler_t' type is invalid in OpenCL}}
 }
 
 void bad(sampler_t*); // expected-error{{pointer to type 'sampler_t' is invalid in OpenCL}}
 
 void bar() {
-  sampler_t smp1 = 7;
-  sampler_t smp2 = 2;
+  sampler_t smp1 = CLK_ADDRESS_CLAMP_TO_EDGE | CLK_NORMALIZED_COORDS_TRUE | CLK_FILTER_LINEAR;
+  sampler_t smp2 = CLK_ADDRESS_CLAMP_TO_EDGE | CLK_NORMALIZED_COORDS_TRUE | CLK_FILTER_NEAREST;
   smp1=smp2; //expected-error{{invalid operands to binary expression ('sampler_t' and 'sampler_t')}}
   smp1+1; //expected-error{{invalid operands to binary expression ('sampler_t' and 'int')}}
   &smp1; //expected-error{{invalid argument type 'sampler_t' to unary expression}}
   *smp2; //expected-error{{invalid argument type 'sampler_t' to unary expression}}
 }
 
-sampler_t bad(); //expected-error{{declaring function return value of type 'sampler_t' is not allowed}}
+sampler_t bad(void); //expected-error{{declaring function return value of type 'sampler_t' is not allowed}}
Index: test/CodeGenOpenCL/sampler.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/sampler.cl
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 %s -emit-llvm -triple spir-unknown-unknown -o - -O0 | FileCheck %s
+//
+// This test covers 6 cases of sampler initialzation:
+//   1. function argument passing
+//  1a. argument is a file-scope variable
+//  1b. argument is a function-scope variable
+//  1c. argument is one of caller function's parameters
+//   2. variable initialization
+//  2a. initializing a file-scope variable
+//  2b. initializing a function-scope variable
+
+#define CLK_ADDRESS_CLAMP_TO_EDGE   2
+#define CLK_NORMALIZED_COORDS_TRUE  1
+#define CLK_FILTER_NEAREST  0x10
+#define CLK_FILTER_LINEAR   0x20
+
+// CHECK: %__opencl_sampler_t = type opaque
+
+// Case 2a
+constant sampler_t glb_smp = CLK_ADDRESS_CLAMP_TO_EDGE | CLK_NORMALIZED_COORDS_TRUE | CLK_FILTER_LINEAR;
+// CHECK-N

Re: [PATCH] D21567: [OpenCL] Generate struct type for sampler_t and function call for the initializer

[Yaxun Liu via cfe-commits]

yaxunl added inline comments.


Comment at: lib/Sema/SemaInit.cpp:6917-6929
@@ -6915,4 +6916,15 @@
 << SourceType;
-  } else if (Entity.getKind() != InitializedEntity::EK_Variable) {
-llvm_unreachable("Invalid EntityKind!");
+  break;
+} else if (const DeclRefExpr *DRE = dyn_cast(Init)) {
+  auto Var = cast(DRE->getDecl());
+  if (!Var->hasGlobalStorage()) {
+CurInit = ImplicitCastExpr::Create(S.Context, Step->Type,
+   CK_LValueToRValue, 
CurInit.get(),
+   /*BasePath=*/nullptr, 
VK_RValue);
+break;
+  }
+  Init = cast(const_cast(
+Var->getInit()))->getSubExpr();
+  SourceType = Init->getType();
+}
   }

Anastasia wrote:
> It would be nice to put some comments here summarizing your description!
> 
> Btw, I don't think it's covered in testing yet, isn't it?
Added detailed comments.

I only missed passing sampler parameter as function call argument. Now added.


Comment at: lib/Sema/SemaInit.cpp:6918
@@ +6917,3 @@
+  break;
+} else if (const DeclRefExpr *DRE = dyn_cast(Init)) {
+  auto Var = cast(DRE->getDecl());

Anastasia wrote:
> I don't get why this level of indirection is added? Should the variable 
> initialization be handled elsewhere?
For global variables, since we cannot initialize them with a function call 
`__translate_sampler_initializer`, we have to take their initializer and pass 
them to a function call.


Comment at: test/SemaOpenCL/sampler_t.cl:55
@@ -30,2 +54,2 @@
 
-sampler_t bad(); //expected-error{{declaring function return value of type 
'sampler_t' is not allowed}}
+sampler_t bad(void); //expected-error{{declaring function return value of type 
'sampler_t' is not allowed}}

Anastasia wrote:
> Why was this change required?
Since i added a run with spir triple, there is an extra error msg emitted:

function with no prototype cannot use the spir_function calling convention

adding void argument suppresses this error msg.


https://reviews.llvm.org/D21567



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

Re: [PATCH] D22523: [OpenCL] AMDGCN target will generate images in constant address space

[Yaxun Liu via cfe-commits]

yaxunl added inline comments.


Comment at: test/CodeGenOpenCL/opencl_types.cl:1
@@ -1,1 +1,2 @@
-// RUN: %clang_cc1 %s -emit-llvm -o - -O0 | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -o - -O0 | FileCheck %s 
--check-prefix=CHECK-NORMAL
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -O0 | FileCheck 
%s --check-prefix=CHECK-AMDGCN

I think we should add -triple spir-unknown-unknown for this command, otherwise 
by default all address spaces are mapped to 0.


Repository:
  rL LLVM

https://reviews.llvm.org/D22523



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

Re: [PATCH] D22105: [X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using generic IR

[Simon Pilgrim via cfe-commits]

RKSimon added a comment.

In https://reviews.llvm.org/D22105#488566, @eli.friedman wrote:

> The x86-specific operation is affected by the rounding mode... but so is a C 
> cast.  This is specified by Annex F in the C standard.
>
> Of course, you're going to end up with undefined behavior if you actually 
> modify the rounding mode because LLVM and clang don't support FENV_ACCESS at 
> the moment.


OK I'm going to pull the sitofp conversions from this patch - I have other 
concerns about them (i.e. we don't treat scalar + vector the same) that will 
need to be looked at as well.


Repository:
  rL LLVM

https://reviews.llvm.org/D22105



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

[PATCH] D22525: [Sema] Add sizeof diagnostics for bzero

[Bruno Cardoso Lopes via cfe-commits]

bruno created this revision.
bruno added a reviewer: zaks.anna.
bruno added a subscriber: cfe-commits.

For memset (and others) we can get diagnostics like:

  struct stat { int x; };
  void foo(struct stat *stamps) {
memset(stamps, 0, sizeof(stamps));
  }

  t.c:7:28: warning: 'memset' call operates on objects of type 'struct stat' 
while the size is based on a different type 'struct stat *' 
[-Wsizeof-pointer-memaccess]
memset(stamps, 0, sizeof(stamps));
   ~~^~
  t.c:7:28: note: did you mean to dereference the argument to 'sizeof' (and 
multiply it by the number of elements)?
memset(stamps, 0, sizeof(stamps));
 ^~

This patch adds support for the same class of warnings for bzero.

https://reviews.llvm.org/D22525

Files:
  lib/AST/Decl.cpp
  lib/Sema/SemaChecking.cpp
  test/SemaCXX/warn-memset-bad-sizeof.cpp

Index: test/SemaCXX/warn-memset-bad-sizeof.cpp
===
--- test/SemaCXX/warn-memset-bad-sizeof.cpp
+++ test/SemaCXX/warn-memset-bad-sizeof.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -Wno-sizeof-array-argument %s
 //
+extern "C" void *bzero(void *, unsigned);
 extern "C" void *memset(void *, int, unsigned);
 extern "C" void *memmove(void *s1, const void *s2, unsigned n);
 extern "C" void *memcpy(void *s1, const void *s2, unsigned n);
@@ -47,6 +48,19 @@
   memset(heap_buffer, 0, sizeof(heap_buffer));  // \
   // expected-warning {{'memset' call operates on objects of type 'char' while the size is based on a different type 'char *'}} expected-note{{did you mean to provide an explicit length?}}
 
+  bzero(&s, sizeof(&s));  // \
+  // expected-warning {{'bzero' call operates on objects of type 'S' while the size is based on a different type 'S *'}} expected-note{{did you mean to remove the addressof in the argument to 'sizeof' (and multiply it by the number of elements)?}}
+  bzero(ps, sizeof(ps));  // \
+  // expected-warning {{'bzero' call operates on objects of type 'S' while the size is based on a different type 'S *'}} expected-note{{did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?}}
+  bzero(ps2, sizeof(ps2));  // \
+  // expected-warning {{'bzero' call operates on objects of type 'S' while the size is based on a different type 'PS' (aka 'S *')}} expected-note{{did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?}}
+  bzero(ps2, sizeof(typeof(ps2)));  // \
+  // expected-warning {{argument to 'sizeof' in 'bzero' call is the same pointer type}}
+  bzero(ps2, sizeof(PS));  // \
+  // expected-warning {{argument to 'sizeof' in 'bzero' call is the same pointer type}}
+  bzero(heap_buffer, sizeof(heap_buffer));  // \
+  // expected-warning {{'bzero' call operates on objects of type 'char' while the size is based on a different type 'char *'}} expected-note{{did you mean to provide an explicit length?}}
+
   memcpy(&s, 0, sizeof(&s));  // \
   // expected-warning {{'memcpy' call operates on objects of type 'S' while the size is based on a different type 'S *'}} expected-note{{did you mean to remove the addressof in the argument to 'sizeof' (and multiply it by the number of elements)?}}
   memcpy(0, &s, sizeof(&s));  // \
@@ -73,6 +87,21 @@
   memset(arr, 0, sizeof(arr));
   memset(parr, 0, sizeof(parr));
 
+  bzero((void*)&s, sizeof(&s));
+  bzero(&s, sizeof(s));
+  bzero(&s, sizeof(S));
+  bzero(&s, sizeof(const S));
+  bzero(&s, sizeof(volatile S));
+  bzero(&s, sizeof(volatile const S));
+  bzero(&foo, sizeof(CFoo));
+  bzero(&foo, sizeof(VFoo));
+  bzero(&foo, sizeof(CVFoo));
+  bzero(ps, sizeof(*ps));
+  bzero(ps2, sizeof(*ps2));
+  bzero(ps2, sizeof(typeof(*ps2)));
+  bzero(arr, sizeof(arr));
+  bzero(parr, sizeof(parr));
+
   memcpy(&foo, &const_foo, sizeof(Foo));
   memcpy((void*)&s, 0, sizeof(&s));
   memcpy(0, (void*)&s, sizeof(&s));
@@ -96,12 +125,17 @@
   int iarr[14];
   memset(&iarr[0], 0, sizeof iarr);
   memset(iarr, 0, sizeof iarr);
+  bzero(&iarr[0], sizeof iarr);
+  bzero(iarr, sizeof iarr);
 
   int* iparr[14];
   memset(&iparr[0], 0, sizeof iparr);
   memset(iparr, 0, sizeof iparr);
+  bzero(&iparr[0], sizeof iparr);
+  bzero(iparr, sizeof iparr);
 
   memset(m, 0, sizeof(Mat));
+  bzero(m, sizeof(Mat));
 
   // Copy to raw buffer shouldn't warn either
   memcpy(&foo, &arr, sizeof(Foo));
@@ -114,12 +148,21 @@
 for (;;) {}
 &s;
   }), 0, sizeof(s));
+
+  bzero(({
+if (0) {}
+while (0) {}
+for (;;) {}
+&s;
+  }), sizeof(s));
 }
 
 namespace ns {
 void memset(void* s, char c, int n);
+void bzero(void* s, int n);
 void f(int* i) {
   memset(i, 0, sizeof(i));
+  bzero(i, sizeof(i));
 }
 }
 
Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -6125,13 +6125,15 @@
 
   // It is possibl

Re: [PATCH] D22105: [X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using generic IR

[Simon Pilgrim via cfe-commits]

RKSimon updated this revision to Diff 64534.
RKSimon added a comment.

Removed sitofp conversion changes


Repository:
  rL LLVM

https://reviews.llvm.org/D22105

Files:
  include/clang/Basic/BuiltinsX86.def
  lib/Headers/avxintrin.h
  lib/Headers/emmintrin.h
  lib/Headers/xmmintrin.h
  test/CodeGen/avx-builtins.c
  test/CodeGen/builtins-x86.c
  test/CodeGen/sse-builtins.c
  test/CodeGen/sse2-builtins.c

Index: test/CodeGen/sse2-builtins.c
===
--- test/CodeGen/sse2-builtins.c
+++ test/CodeGen/sse2-builtins.c
@@ -507,7 +507,7 @@
 
 __m128 test_mm_cvtsd_ss(__m128 A, __m128d B) {
   // CHECK-LABEL: test_mm_cvtsd_ss
-  // CHECK: fptrunc double %{{.*}} to float
+  // CHECK: call <4 x float> @llvm.x86.sse2.cvtsd2ss(<4 x float> %{{.*}}, <2 x double> %{{.*}})
   return _mm_cvtsd_ss(A, B);
 }
 
@@ -569,21 +569,19 @@
 
 __m128i test_mm_cvttps_epi32(__m128 A) {
   // CHECK-LABEL: test_mm_cvttps_epi32
-  // CHECK: fptosi <4 x float> %{{.*}} to <4 x i32>
+  // CHECK: call <4 x i32> @llvm.x86.sse2.cvttps2dq(<4 x float> %{{.*}})
   return _mm_cvttps_epi32(A);
 }
 
 int test_mm_cvttsd_si32(__m128d A) {
   // CHECK-LABEL: test_mm_cvttsd_si32
-  // CHECK: extractelement <2 x double> %{{.*}}, i32 0
-  // CHECK: fptosi double %{{.*}} to i32
+  // CHECK: call i32 @llvm.x86.sse2.cvttsd2si(<2 x double> %{{.*}})
   return _mm_cvttsd_si32(A);
 }
 
 long long test_mm_cvttsd_si64(__m128d A) {
   // CHECK-LABEL: test_mm_cvttsd_si64
-  // CHECK: extractelement <2 x double> %{{.*}}, i32 0
-  // CHECK: fptosi double %{{.*}} to i64
+  // CHECK: call i64 @llvm.x86.sse2.cvttsd2si64(<2 x double> %{{.*}})
   return _mm_cvttsd_si64(A);
 }
 
Index: test/CodeGen/sse-builtins.c
===
--- test/CodeGen/sse-builtins.c
+++ test/CodeGen/sse-builtins.c
@@ -295,22 +295,19 @@
 
 int test_mm_cvtt_ss2si(__m128 A) {
   // CHECK-LABEL: test_mm_cvtt_ss2si
-  // CHECK: extractelement <4 x float> %{{.*}}, i32 0
-  // CHECK: fptosi float %{{.*}} to i32
+  // CHECK: call i32 @llvm.x86.sse.cvttss2si(<4 x float> %{{.*}})
   return _mm_cvtt_ss2si(A);
 }
 
 int test_mm_cvttss_si32(__m128 A) {
   // CHECK-LABEL: test_mm_cvttss_si32
-  // CHECK: extractelement <4 x float> %{{.*}}, i32 0
-  // CHECK: fptosi float %{{.*}} to i32
+  // CHECK: call i32 @llvm.x86.sse.cvttss2si(<4 x float> %{{.*}})
   return _mm_cvttss_si32(A);
 }
 
 long long test_mm_cvttss_si64(__m128 A) {
   // CHECK-LABEL: test_mm_cvttss_si64
-  // CHECK: extractelement <4 x float> %{{.*}}, i32 0
-  // CHECK: fptosi float %{{.*}} to i64
+  // CHECK: call i64 @llvm.x86.sse.cvttss2si64(<4 x float> %{{.*}})
   return _mm_cvttss_si64(A);
 }
 
Index: test/CodeGen/builtins-x86.c
===
--- test/CodeGen/builtins-x86.c
+++ test/CodeGen/builtins-x86.c
@@ -287,12 +287,14 @@
   tmp_V4f = __builtin_ia32_cvtpi2ps(tmp_V4f, tmp_V2i);
   tmp_V2i = __builtin_ia32_cvtps2pi(tmp_V4f);
   tmp_i = __builtin_ia32_cvtss2si(tmp_V4f);
+  tmp_i = __builtin_ia32_cvttss2si(tmp_V4f);
 
   tmp_i = __builtin_ia32_rdtsc();
   tmp_i = __builtin_ia32_rdtscp(&tmp_Ui);
   tmp_LLi = __builtin_ia32_rdpmc(tmp_i);
 #ifdef USE_64
   tmp_LLi = __builtin_ia32_cvtss2si64(tmp_V4f);
+  tmp_LLi = __builtin_ia32_cvttss2si64(tmp_V4f);
 #endif
   tmp_V2i = __builtin_ia32_cvttps2pi(tmp_V4f);
   (void) __builtin_ia32_maskmovq(tmp_V8c, tmp_V8c, tmp_cp);
@@ -328,10 +330,14 @@
   tmp_V2i = __builtin_ia32_cvttpd2pi(tmp_V2d);
   tmp_V2d = __builtin_ia32_cvtpi2pd(tmp_V2i);
   tmp_i = __builtin_ia32_cvtsd2si(tmp_V2d);
+  tmp_i = __builtin_ia32_cvttsd2si(tmp_V2d);
+  tmp_V4f = __builtin_ia32_cvtsd2ss(tmp_V4f, tmp_V2d);
 #ifdef USE_64
   tmp_LLi = __builtin_ia32_cvtsd2si64(tmp_V2d);
+  tmp_LLi = __builtin_ia32_cvttsd2si64(tmp_V2d);
 #endif
   tmp_V4i = __builtin_ia32_cvtps2dq(tmp_V4f);
+  tmp_V4i = __builtin_ia32_cvttps2dq(tmp_V4f);
   (void) __builtin_ia32_clflush(tmp_vCp);
   (void) __builtin_ia32_lfence();
   (void) __builtin_ia32_mfence();
@@ -410,7 +416,9 @@
   tmp_V8f = __builtin_ia32_cvtdq2ps256(tmp_V8i);
   tmp_V4f = __builtin_ia32_cvtpd2ps256(tmp_V4d);
   tmp_V8i = __builtin_ia32_cvtps2dq256(tmp_V8f);
+  tmp_V4i = __builtin_ia32_cvttpd2dq256(tmp_V4d);
   tmp_V4i = __builtin_ia32_cvtpd2dq256(tmp_V4d);
+  tmp_V8i = __builtin_ia32_cvttps2dq256(tmp_V8f);
   tmp_V4d = __builtin_ia32_vperm2f128_pd256(tmp_V4d, tmp_V4d, 0x7);
   tmp_V8f = __builtin_ia32_vperm2f128_ps256(tmp_V8f, tmp_V8f, 0x7);
   tmp_V8i = __builtin_ia32_vperm2f128_si256(tmp_V8i, tmp_V8i, 0x7);
Index: test/CodeGen/avx-builtins.c
===
--- test/CodeGen/avx-builtins.c
+++ test/CodeGen/avx-builtins.c
@@ -286,13 +286,13 @@
 
 __m128i test_mm256_cvttpd_epi32(__m256d A) {
   // CHECK-LABEL: test_mm256_cvttpd_epi32
-  // CHECK: fptosi <4 x double> %{{.*}} to <4 x i32>
+  // CHECK: call <4 x i32> @llvm.x86.avx.cvtt.pd2dq.256(<4 x double> %{{.*}})
   return _mm

Re: [PATCH] D22523: [OpenCL] AMDGCN target will generate images in constant address space

[Aaron En Ye Shi via cfe-commits]

ashi1 updated this revision to Diff 64538.
ashi1 marked an inline comment as done.
ashi1 added a comment.

Revised based on Sam's comments. Also updated test file to changes with using 
triple spir-unknown-unknown.


Repository:
  rL LLVM

https://reviews.llvm.org/D22523

Files:
  lib/CodeGen/CGOpenCLRuntime.cpp
  lib/CodeGen/TargetInfo.cpp
  lib/CodeGen/TargetInfo.h
  test/CodeGenOpenCL/opencl_types.cl

Index: test/CodeGenOpenCL/opencl_types.cl
===
--- test/CodeGenOpenCL/opencl_types.cl
+++ test/CodeGenOpenCL/opencl_types.cl
@@ -1,40 +1,49 @@
-// RUN: %clang_cc1 %s -emit-llvm -o - -O0 | FileCheck %s
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - -O0 | FileCheck %s --check-prefix=CHECK-SPIR
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -O0 | FileCheck %s --check-prefix=CHECK-AMDGCN
 
 constant sampler_t glb_smp = 7;
-// CHECK: constant i32 7
+// CHECK-SPIR: constant i32 7
+// CHECK-AMDGCN: addrspace(2) constant i32 7
 
 void fnc1(image1d_t img) {}
-// CHECK: @fnc1(%opencl.image1d_ro_t*
+// CHECK-SPIR: @fnc1(%opencl.image1d_ro_t addrspace(1)*
+// CHECK-AMDGCN: @fnc1(%opencl.image1d_ro_t addrspace(2)*
 
 void fnc1arr(image1d_array_t img) {}
-// CHECK: @fnc1arr(%opencl.image1d_array_ro_t*
+// CHECK-SPIR: @fnc1arr(%opencl.image1d_array_ro_t addrspace(1)*
+// CHECK-AMDGCN: @fnc1arr(%opencl.image1d_array_ro_t addrspace(2)*
 
 void fnc1buff(image1d_buffer_t img) {}
-// CHECK: @fnc1buff(%opencl.image1d_buffer_ro_t*
+// CHECK-SPIR: @fnc1buff(%opencl.image1d_buffer_ro_t addrspace(1)*
+// CHECK-AMDGCN: @fnc1buff(%opencl.image1d_buffer_ro_t addrspace(2)*
 
 void fnc2(image2d_t img) {}
-// CHECK: @fnc2(%opencl.image2d_ro_t*
+// CHECK-SPIR: @fnc2(%opencl.image2d_ro_t addrspace(1)*
+// CHECK-AMDGCN: @fnc2(%opencl.image2d_ro_t addrspace(2)*
 
 void fnc2arr(image2d_array_t img) {}
-// CHECK: @fnc2arr(%opencl.image2d_array_ro_t*
+// CHECK-SPIR: @fnc2arr(%opencl.image2d_array_ro_t addrspace(1)*
+// CHECK-AMDGCN: @fnc2arr(%opencl.image2d_array_ro_t addrspace(2)*
 
 void fnc3(image3d_t img) {}
-// CHECK: @fnc3(%opencl.image3d_ro_t*
+// CHECK-SPIR: @fnc3(%opencl.image3d_ro_t addrspace(1)*
+// CHECK-AMDGCN: @fnc3(%opencl.image3d_ro_t addrspace(2)*
 
 void fnc4smp(sampler_t s) {}
-// CHECK-LABEL: define {{.*}}void @fnc4smp(i32
+// CHECK-SPIR-LABEL: define {{.*}}void @fnc4smp(i32
 
 kernel void foo(image1d_t img) {
   sampler_t smp = 5;
-  // CHECK: alloca i32
+  // CHECK-SPIR: alloca i32
   event_t evt;
-  // CHECK: alloca %opencl.event_t*
-  // CHECK: store i32 5,
+  // CHECK-SPIR: alloca %opencl.event_t*
+  // CHECK-SPIR: store i32 5,
   fnc4smp(smp);
-  // CHECK: call {{.*}}void @fnc4smp(i32
+  // CHECK-SPIR: call {{.*}}void @fnc4smp(i32
   fnc4smp(glb_smp);
-  // CHECK: call {{.*}}void @fnc4smp(i32
+  // CHECK-SPIR: call {{.*}}void @fnc4smp(i32
 }
 
 void __attribute__((overloadable)) bad1(image1d_t b, image2d_t c, image2d_t d) {}
-// CHECK-LABEL: @{{_Z4bad114ocl_image1d_ro14ocl_image2d_roS0_|"\\01\?bad1@@\$\$J0YAXPAUocl_image1d_ro@@PAUocl_image2d_ro@@1@Z"}}
+// CHECK-SPIR-LABEL: @{{_Z4bad114ocl_image1d_ro14ocl_image2d_roS0_|"\\01\?bad1@@\$\$J0YAXPAUocl_image1d_ro@@PAUocl_image2d_ro@@1@Z"}}
+// CHECK-AMDGCN-LABEL: @{{_Z4bad114ocl_image1d_ro14ocl_image2d_roS0_|"\\01\?bad1@@\$\$J0YAXPAUocl_image1d_ro@@PAUocl_image2d_ro@@1@Z"}}(%opencl.image1d_ro_t addrspace(2)*{{.*}}%opencl.image2d_ro_t addrspace(2)*{{.*}}%opencl.image2d_ro_t addrspace(2)*{{.*}})
Index: lib/CodeGen/TargetInfo.h
===
--- lib/CodeGen/TargetInfo.h
+++ lib/CodeGen/TargetInfo.h
@@ -220,6 +220,9 @@
 
   /// Get LLVM calling convention for OpenCL kernel.
   virtual unsigned getOpenCLKernelCallingConv() const;
+
+  /// Get LLVM Image Address Space for OpenCL kernel.
+  virtual unsigned getOpenCLImageAddrSpace(CodeGen::CodeGenModule &CGM) const;
 };
 
 } // namespace CodeGen
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -375,6 +375,11 @@
 unsigned TargetCodeGenInfo::getOpenCLKernelCallingConv() const {
   return llvm::CallingConv::C;
 }
+
+unsigned TargetCodeGenInfo::getOpenCLImageAddrSpace(CodeGen::CodeGenModule &CGM) const {
+  return CGM.getContext().getTargetAddressSpace(LangAS::opencl_global);
+}
+
 static bool isEmptyRecord(ASTContext &Context, QualType T, bool AllowArrays);
 
 /// isEmptyField - Return true iff a the field is "empty", that is it
@@ -6832,6 +6832,7 @@
   void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
CodeGen::CodeGenModule &M) const override;
   unsigned getOpenCLKernelCallingConv() const override;
+  unsigned getOpenCLImageAddrSpace(CodeGen::CodeGenModule &CGM) const override;
 };
 
 }
@@ -6864,6 +6864,10 @@
   return llvm::CallingConv::AMDGPU_KERNEL;
 }
 
+unsigned AMDGPUTargetCodeGenInfo::getOpenCLImageAddrSpace(CodeG

[libclc] r276009 - amdgpu: Use right builtn for rsq

[Matt Arsenault via cfe-commits]

Author: arsenm
Date: Tue Jul 19 14:02:01 2016
New Revision: 276009

URL: http://llvm.org/viewvc/llvm-project?rev=276009&view=rev
Log:
amdgpu: Use right builtn for rsq

The r600 path has never actually worked sinced double is not implemented
there.

Modified:
libclc/trunk/amdgpu/lib/math/sqrt.cl

Modified: libclc/trunk/amdgpu/lib/math/sqrt.cl
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/amdgpu/lib/math/sqrt.cl?rev=276009&r1=276008&r2=276009&view=diff
==
--- libclc/trunk/amdgpu/lib/math/sqrt.cl (original)
+++ libclc/trunk/amdgpu/lib/math/sqrt.cl Tue Jul 19 14:02:01 2016
@@ -30,6 +30,11 @@ _CLC_DEFINE_UNARY_BUILTIN(float, sqrt, _
 
 #pragma OPENCL EXTENSION cl_khr_fp64 : enable
 
+#ifdef __AMDGCN__
+  #define __clc_builtin_rsq __builtin_amdgcn_rsq
+#else
+  #define __clc_builtin_rsq __builtin_r600_recipsqrt_ieee
+#endif
 
 _CLC_OVERLOAD _CLC_DEF double sqrt(double x) {
 
@@ -38,7 +43,7 @@ _CLC_OVERLOAD _CLC_DEF double sqrt(doubl
   unsigned exp1 = vcc ? 0xff80 : 0;
 
   double v01 = ldexp(x, exp0);
-  double v23 = __builtin_amdgpu_rsq(v01);
+  double v23 = __clc_builtin_rsq(v01);
   double v45 = v01 * v23;
   v23 = v23 * 0.5;
 


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

Re: [PATCH] D22105: [X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using generic IR

[Eli Friedman via cfe-commits]

eli.friedman accepted this revision.
eli.friedman added a comment.
This revision is now accepted and ready to land.

LGTM.


Repository:
  rL LLVM

https://reviews.llvm.org/D22105



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

Re: [PATCH] D22523: [OpenCL] AMDGCN target will generate images in constant address space

[Yaxun Liu via cfe-commits]

yaxunl accepted this revision.
yaxunl added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks!


Repository:
  rL LLVM

https://reviews.llvm.org/D22523



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

Re: [PATCH] D14326: ASTImporter: expressions, pt.2

[Serge Pavlov via cfe-commits]

Unit test ImportVAArgExpr fails on Windows. The source file:

void declToImport(__builtin_va_list list, ...) {

  (void)__builtin_va_arg(list, int);

}


When compiled on Windows it produces AST:


TranslationUnitDecl 0x638f150 <> 



`-FunctionDecl 0x638f780  line:1:6 declToImport
'void (__builtin_va_list, ...)'

  |-ParmVarDecl 0x638f6e0  col:37 used list
'__builtin_va_list':'char *'

  `-CompoundStmt 0x638f880 

`-CStyleCastExpr 0x638f868  'void' 

  `-VAArgExpr 0x638f848  'int'

`-DeclRefExpr 0x638f820  '__builtin_va_list':'char *'
lvalue ParmVar 0x638f6e0 'list' '__builtin_va_list':'char *'

while on Linux 64 the result is:

TranslationUnitDecl 0x9fef870 <> 

`-FunctionDecl 0xa046700  line:1:6 declToImport
'void (struct __va_list_tag *, ...)'
  |-ParmVarDecl 0xa046600  col:37 used list 'struct
__va_list_tag *':'struct __va_list_tag *'
  `-CompoundStmt 0xa0468c8 
`-CStyleCastExpr 0xa0468a0  'void' 
  `-VAArgExpr 0xa046868  'int'
`-ImplicitCastExpr 0xa046850  'struct __va_list_tag
*':'struct __va_list_tag *' 
  `-DeclRefExpr 0xa0467f0  'struct __va_list_tag *':'struct
__va_list_tag *' lvalue ParmVar 0xa046600 'list' 'struct __va_list_tag
*':'struct __va_list_tag *'

Maybe it can help.

Thanks,
--Serge

2016-07-18 16:33 GMT+06:00 Aleksei Sidorin :

> a.sidorin added a comment.
>
> > I don't think this small improvement in Importer is worth invasive
> changes in other components.
>
>
> Thanks, Serge. Is it OK to commit?
>
>
> https://reviews.llvm.org/D14326
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22424: [OpenCL] Fixes bug of missing OCL related metadata on the AMDGCN target

[Yaxun Liu via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL276010: [OpenCL] Fixes bug of missing OCL version metadata 
on the AMDGCN target (authored by yaxunl).

Changed prior to commit:
  https://reviews.llvm.org/D22424?vs=64513&id=64545#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22424

Files:
  cfe/trunk/lib/CodeGen/TargetInfo.cpp
  cfe/trunk/test/CodeGenOpenCL/spir_version.cl

Index: cfe/trunk/test/CodeGenOpenCL/spir_version.cl
===
--- cfe/trunk/test/CodeGenOpenCL/spir_version.cl
+++ cfe/trunk/test/CodeGenOpenCL/spir_version.cl
@@ -1,18 +1,31 @@
-// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CL10
-// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CL12
-// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CL20
-// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CL10
-// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CL12
-// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CL20
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CHECK-SPIR-CL10
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-SPIR-CL12
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL20
+// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CHECK-SPIR-CL10
+// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-SPIR-CL12
+// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL20
+
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - | FileCheck %s 
--check-prefix=CHECK-AMDGCN-CL10
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -cl-std=CL1.2 | 
FileCheck %s --check-prefix=CHECK-AMDGCN-CL12
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -cl-std=CL2.0 | 
FileCheck %s --check-prefix=CHECK-AMDGCN-CL20
+
 kernel void foo() {}
-// CL10: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
-// CL10: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
-// CL10: [[SPIR]] = !{i32 2, i32 0}
-// CL10: [[OCL]] = !{i32 1, i32 0}
-// CL12: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
-// CL12: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
-// CL12: [[SPIR]] = !{i32 2, i32 0}
-// CL12: [[OCL]] = !{i32 1, i32 2}
-// CL20: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
-// CL20: !opencl.ocl.version = !{[[SPIR:![0-9]+]]}
-// CL20: [[SPIR]] = !{i32 2, i32 0}
+
+// CHECK-SPIR-CL10: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
+// CHECK-SPIR-CL10: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
+// CHECK-SPIR-CL10: [[SPIR]] = !{i32 2, i32 0}
+// CHECK-SPIR-CL10: [[OCL]] = !{i32 1, i32 0}
+// CHECK-SPIR-CL12: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
+// CHECK-SPIR-CL12: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
+// CHECK-SPIR-CL12: [[SPIR]] = !{i32 2, i32 0}
+// CHECK-SPIR-CL12: [[OCL]] = !{i32 1, i32 2}
+// CHECK-SPIR-CL20: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
+// CHECK-SPIR-CL20: !opencl.ocl.version = !{[[SPIR:![0-9]+]]}
+// CHECK-SPIR-CL20: [[SPIR]] = !{i32 2, i32 0}
+
+// CHECK-AMDGCN-CL10: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
+// CHECK-AMDGCN-CL10: [[OCL]] = !{i32 1, i32 0}
+// CHECK-AMDGCN-CL12: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
+// CHECK-AMDGCN-CL12: [[OCL]] = !{i32 1, i32 2}
+// CHECK-AMDGCN-CL20: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
+// CHECK-AMDGCN-CL20: [[OCL]] = !{i32 2, i32 0}
\ No newline at end of file
Index: cfe/trunk/lib/CodeGen/TargetInfo.cpp
===
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp
@@ -6836,6 +6836,8 @@
 
 }
 
+static void appendOpenCLVersionMD (CodeGen::CodeGenModule &CGM);
+
 void AMDGPUTargetCodeGenInfo::setTargetAttributes(
   const Decl *D,
   llvm::GlobalValue *GV,
@@ -6857,8 +6859,10 @@
 if (NumSGPR != 0)
   F->addFnAttr("amdgpu_num_sgpr", llvm::utostr(NumSGPR));
   }
-}
 
+  appendOpenCLVersionMD(M);
+}
+
 
 unsigned AMDGPUTargetCodeGenInfo::getOpenCLKernelCallingConv() const {
   return llvm::CallingConv::AMDGPU_KERNEL;
@@ -7530,6 +7534,13 @@
   llvm::NamedMDNode *SPIRVerMD =
   M.getOrInsertNamedMetadata("opencl.spir.version");
   SPIRVerMD->addOperand(llvm::MDNode::get(Ctx, SPIRVerElts));
+  appendOpenCLVersionMD(CGM);
+}
+
+static void appendOpenCLVersionMD (CodeGen::CodeGenModule &CGM) {
+  llvm::LLVMContext &Ctx = CGM.getModule().getContext()

r276010 - [OpenCL] Fixes bug of missing OCL version metadata on the AMDGCN target

[Yaxun Liu via cfe-commits]

Author: yaxunl
Date: Tue Jul 19 14:39:45 2016
New Revision: 276010

URL: http://llvm.org/viewvc/llvm-project?rev=276010&view=rev
Log:
[OpenCL] Fixes bug of missing OCL version metadata on the AMDGCN target

Added the opencl.ocl.version metadata to be emitted with amdgcn. Created a 
static function emitOCLVerMD which is shared between triple spir and target 
amdgcn.

Also added new testcases to existing test file, spir_version.cl inside 
test/CodeGenOpenCL.

Patch by Aaron En Ye Shi.

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

Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/test/CodeGenOpenCL/spir_version.cl

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=276010&r1=276009&r2=276010&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Tue Jul 19 14:39:45 2016
@@ -6836,6 +6836,8 @@ public:
 
 }
 
+static void appendOpenCLVersionMD (CodeGen::CodeGenModule &CGM);
+
 void AMDGPUTargetCodeGenInfo::setTargetAttributes(
   const Decl *D,
   llvm::GlobalValue *GV,
@@ -6857,8 +6859,10 @@ void AMDGPUTargetCodeGenInfo::setTargetA
 if (NumSGPR != 0)
   F->addFnAttr("amdgpu_num_sgpr", llvm::utostr(NumSGPR));
   }
-}
 
+  appendOpenCLVersionMD(M);
+}
+
 
 unsigned AMDGPUTargetCodeGenInfo::getOpenCLKernelCallingConv() const {
   return llvm::CallingConv::AMDGPU_KERNEL;
@@ -7530,6 +7534,13 @@ void SPIRTargetCodeGenInfo::emitTargetMD
   llvm::NamedMDNode *SPIRVerMD =
   M.getOrInsertNamedMetadata("opencl.spir.version");
   SPIRVerMD->addOperand(llvm::MDNode::get(Ctx, SPIRVerElts));
+  appendOpenCLVersionMD(CGM);
+}
+
+static void appendOpenCLVersionMD (CodeGen::CodeGenModule &CGM) {
+  llvm::LLVMContext &Ctx = CGM.getModule().getContext();
+  llvm::Type *Int32Ty = llvm::Type::getInt32Ty(Ctx);
+  llvm::Module &M = CGM.getModule();
   // SPIR v2.0 s2.13 - The OpenCL version used by the module is stored in the
   // opencl.ocl.version named metadata node.
   llvm::Metadata *OCLVerElts[] = {

Modified: cfe/trunk/test/CodeGenOpenCL/spir_version.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/spir_version.cl?rev=276010&r1=276009&r2=276010&view=diff
==
--- cfe/trunk/test/CodeGenOpenCL/spir_version.cl (original)
+++ cfe/trunk/test/CodeGenOpenCL/spir_version.cl Tue Jul 19 14:39:45 2016
@@ -1,18 +1,31 @@
-// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CL10
-// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CL12
-// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CL20
-// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CL10
-// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CL12
-// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CL20
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CHECK-SPIR-CL10
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-SPIR-CL12
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL20
+// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - | 
FileCheck %s --check-prefix=CHECK-SPIR-CL10
+// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-SPIR-CL12
+// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL20
+
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - | FileCheck %s 
--check-prefix=CHECK-AMDGCN-CL10
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -cl-std=CL1.2 | 
FileCheck %s --check-prefix=CHECK-AMDGCN-CL12
+// RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -cl-std=CL2.0 | 
FileCheck %s --check-prefix=CHECK-AMDGCN-CL20
+
 kernel void foo() {}
-// CL10: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
-// CL10: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
-// CL10: [[SPIR]] = !{i32 2, i32 0}
-// CL10: [[OCL]] = !{i32 1, i32 0}
-// CL12: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
-// CL12: !opencl.ocl.version = !{[[OCL:![0-9]+]]}
-// CL12: [[SPIR]] = !{i32 2, i32 0}
-// CL12: [[OCL]] = !{i32 1, i32 2}
-// CL20: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
-// CL20: !opencl.ocl.version = !{[[SPIR:![0-9]+]]}
-// CL20: [[SPIR]] = !{i32 2, i32 0}
+
+// CHECK-SPIR-CL10: !opencl.spir.version = !{[[SPIR:![0-9]+]]}
+// CHECK-S

Re: [PATCH] D22513: [clang-tidy] add check cppcoreguidelines-rule-of-five-and-zero

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added a comment.

Will be good idea to introduce similar check for C++98/03.


Repository:
  rL LLVM

https://reviews.llvm.org/D22513



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

[PATCH] D22528: [libcxxabi] When catching an exception of type nullptr_t with a handler of pointer-to-member type, produce a null value of the right type

[Richard Smith via cfe-commits]

rsmith created this revision.
rsmith added reviewers: EricWF, mclow.lists.
rsmith added a subscriber: cfe-commits.
rsmith set the repository for this revision to rL LLVM.

This fixes a bug where throwing an exception of type nullptr_t and catching it 
as a pointer-to-member would not guarantee to produce a null value in the catch 
handler. The fix is pretty simple: we statically allocate a constant null 
pointer-to-data-member representation and a constant null 
pointer-to-member-function representation, and produce the address of the 
relevant value as the adjusted pointer for the exception.

Repository:
  rL LLVM

https://reviews.llvm.org/D22528

Files:
  src/CMakeLists.txt
  src/private_typeinfo.cpp
  test/catch_const_pointer_nullptr.pass.cpp
  test/catch_member_pointer_nullptr.pass.cpp
  test/catch_pointer_nullptr.pass.cpp
  test/catch_reference_nullptr.pass.cpp
  test/incomplete_type.sh.cpp

Index: test/incomplete_type.sh.cpp
===
--- test/incomplete_type.sh.cpp
+++ test/incomplete_type.sh.cpp
@@ -88,7 +88,9 @@
 assert(false);
   } catch (int CompleteAtThrow::*) {
 assert(false);
-  } catch (int NeverDefined::*) {}
+  } catch (int NeverDefined::*p) {
+assert(!p);
+  }
   AssertIncompleteTypeInfoEquals(ReturnTypeInfoIncompleteMP(), typeid(int IncompleteAtThrow::*));
   try {
 ThrowIncompleteMP();
@@ -99,24 +101,30 @@
 assert(false);
   } catch (IncompleteAtThrow**) {
 assert(false);
-  } catch (int IncompleteAtThrow::*) {}
+  } catch (int IncompleteAtThrow::*p) {
+assert(!p);
+  }
 
   AssertIncompleteTypeInfoEquals(ReturnTypeInfoIncompletePP(), typeid(IncompleteAtThrow**));
   try {
 ThrowIncompletePP();
 assert(false);
   } catch (int IncompleteAtThrow::*) {
 assert(false);
-  } catch (IncompleteAtThrow**) {}
+  } catch (IncompleteAtThrow** p) {
+assert(!p);
+  }
 
   try {
 ThrowIncompletePMP();
 assert(false);
   } catch (int IncompleteAtThrow::*) {
 assert(false);
   } catch (IncompleteAtThrow**) {
 assert(false);
-  } catch (int IncompleteAtThrow::**) {}
+  } catch (int IncompleteAtThrow::**p) {
+assert(!p);
+  }
 
   AssertIncompleteTypeInfoEquals(ReturnTypeInfoCompleteMP(), typeid(int CompleteAtThrow::*));
   try {
@@ -128,7 +136,9 @@
 assert(false);
   } catch (CompleteAtThrow**) {
 assert(false);
-  } catch (int CompleteAtThrow::*) {}
+  } catch (int CompleteAtThrow::*p) {
+assert(!p);
+  }
 
   AssertIncompleteTypeInfoEquals(ReturnTypeInfoCompletePP(), typeid(CompleteAtThrow**));
   try {
@@ -140,7 +150,9 @@
 assert(false);
   } catch (int CompleteAtThrow::*) {
 assert(false);
-  } catch (CompleteAtThrow**) {}
+  } catch (CompleteAtThrow**p) {
+assert(!p);
+  }
 
   try {
 ThrowCompletePMP();
@@ -153,22 +165,30 @@
 assert(false);
   } catch (CompleteAtThrow**) {
 assert(false);
-  } catch (int CompleteAtThrow::**) {}
+  } catch (int CompleteAtThrow::**p) {
+assert(!p);
+  }
 
 #if __cplusplus >= 201103L
   // Catch nullptr as complete type
   try {
 ThrowNullptr();
-  } catch (int IncompleteAtThrow::*) {}
+  } catch (int IncompleteAtThrow::*p) {
+assert(!p);
+  }
 
   // Catch nullptr as an incomplete type
   try {
 ThrowNullptr();
-  } catch (int CompleteAtThrow::*) {}
+  } catch (int CompleteAtThrow::*p) {
+assert(!p);
+  }
   // Catch nullptr as a type that is never complete.
   try {
 ThrowNullptr();
-  } catch (int NeverDefined::*) {}
+  } catch (int NeverDefined::*p) {
+assert(!p);
+  }
 #endif
 }
 #endif
Index: test/catch_reference_nullptr.pass.cpp
===
--- test/catch_reference_nullptr.pass.cpp
+++ test/catch_reference_nullptr.pass.cpp
@@ -0,0 +1,49 @@
+//===- catch_pointer_nullptr.cpp --===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// UNSUPPORTED: c++98, c++03, libcxxabi-no-exceptions
+
+#include 
+#include 
+
+struct A {};
+
+template
+static void catch_nullptr_test() {
+  try {
+throw nullptr;
+  } catch (T &p) {
+assert(CanCatchNullptr && !p);
+  } catch (...) {
+assert(!CanCatchNullptr);
+  }
+}
+
+int main()
+{
+  using nullptr_t = decltype(nullptr);
+
+  // A reference to nullptr_t can catch nullptr.
+  catch_nullptr_test();
+  catch_nullptr_test();
+  catch_nullptr_test();
+  catch_nullptr_test();
+
+  // No other reference type can.
+#if 0
+  // FIXME: These tests fail, because the ABI provides no way for us to
+  // distinguish this from catching by value.
+  catch_nullptr_test();
+  catch_nullptr_test();
+  catch_nullptr_test();
+  catch_nullptr_test();
+  catch_nullptr_test();
+  catch_nullptr_test();
+#endif
+}
Index: test/catch_po

Re: [PATCH] D22528: [libcxxabi] When catching an exception of type nullptr_t with a handler of pointer-to-member type, produce a null value of the right type

[Richard Smith via cfe-commits]

rsmith added inline comments.


Comment at: src/CMakeLists.txt:94
@@ -93,3 +93,3 @@
   PROPERTIES
-COMPILE_FLAGS "${LIBCXXABI_COMPILE_FLAGS}"
+COMPILE_FLAGS "${LIBCXXABI_COMPILE_FLAGS} -fno-modules"
   )

Err, ignore this :)


Repository:
  rL LLVM

https://reviews.llvm.org/D22528



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

Re: [PATCH] D22528: [libcxxabi] When catching an exception of type nullptr_t with a handler of pointer-to-member type, produce a null value of the right type

[Eric Fiselier via cfe-commits]

EricWF accepted this revision.
EricWF added a comment.
This revision is now accepted and ready to land.

LGTM.


Repository:
  rL LLVM

https://reviews.llvm.org/D22528



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

r276014 - Let FuncAttrs infer the 'returned' argument attribute

[David Majnemer via cfe-commits]

Author: majnemer
Date: Tue Jul 19 14:59:24 2016
New Revision: 276014

URL: http://llvm.org/viewvc/llvm-project?rev=276014&view=rev
Log:
Let FuncAttrs infer the 'returned' argument attribute

This reverts commit r275756.

Modified:
cfe/trunk/test/CodeGen/ppc64-struct-onevect.c
cfe/trunk/test/CodeGenCXX/wasm-args-returns.cpp
cfe/trunk/test/CodeGenOpenCL/as_type.cl

Modified: cfe/trunk/test/CodeGen/ppc64-struct-onevect.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/ppc64-struct-onevect.c?rev=276014&r1=276013&r2=276014&view=diff
==
--- cfe/trunk/test/CodeGen/ppc64-struct-onevect.c (original)
+++ cfe/trunk/test/CodeGen/ppc64-struct-onevect.c Tue Jul 19 14:59:24 2016
@@ -9,5 +9,5 @@ v4sf foo (struct s a) {
   return a.v;
 }
 
-// CHECK-LABEL: define <4 x float> @foo(<4 x float> inreg %a.coerce)
+// CHECK-LABEL: define <4 x float> @foo(<4 x float> inreg returned %a.coerce)
 // CHECK: ret <4 x float> %a.coerce

Modified: cfe/trunk/test/CodeGenCXX/wasm-args-returns.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/wasm-args-returns.cpp?rev=276014&r1=276013&r2=276014&view=diff
==
--- cfe/trunk/test/CodeGenCXX/wasm-args-returns.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/wasm-args-returns.cpp Tue Jul 19 14:59:24 2016
@@ -14,7 +14,7 @@
 
 struct one_field { double d; };
 test(one_field);
-// CHECK: define double @_Z7forward9one_field(double %{{.*}})
+// CHECK: define double @_Z7forward9one_field(double returned %{{.*}})
 //
 // CHECK: define void @_Z14test_one_fieldv()
 // CHECK: %[[call:.*]] = tail call double @_Z13def_one_fieldv()
@@ -89,7 +89,7 @@ struct one_bitfield {
 int d:3;
 };
 test(one_bitfield);
-// CHECK: define i32 @_Z7forward12one_bitfield(i32 %{{.*}})
+// CHECK: define i32 @_Z7forward12one_bitfield(i32 returned %{{.*}})
 //
 // CHECK: define void @_Z17test_one_bitfieldv()
 // CHECK: %[[call:.*]] = tail call i32 @_Z16def_one_bitfieldv()

Modified: cfe/trunk/test/CodeGenOpenCL/as_type.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/as_type.cl?rev=276014&r1=276013&r2=276014&view=diff
==
--- cfe/trunk/test/CodeGenOpenCL/as_type.cl (original)
+++ cfe/trunk/test/CodeGenOpenCL/as_type.cl Tue Jul 19 14:59:24 2016
@@ -51,7 +51,7 @@ int f6(char4 x) {
   return __builtin_astype(x, int);
 }
 
-//CHECK: define spir_func <3 x i8> @f7(<3 x i8> %[[x:.*]])
+//CHECK: define spir_func <3 x i8> @f7(<3 x i8> returned %[[x:.*]])
 //CHECK-NOT: bitcast
 //CHECK-NOT: shufflevector
 //CHECK: ret <3 x i8> %[[x]]


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

Re: [PATCH] D22392: [Sema] Fix an invalid nullability warning for binary conditional operators

[Akira Hatanaka via cfe-commits]

ahatanak updated this revision to Diff 64551.
ahatanak added a comment.

Address review comments.

- Rename function to computeConditionalNullability.
- Rewrite the function to compute the nullability of both normal and binary 
conditional expressions.
- Add more test cases.


https://reviews.llvm.org/D22392

Files:
  lib/Sema/SemaExpr.cpp
  test/Sema/nullability.c
  test/SemaCXX/nullability.cpp

Index: test/SemaCXX/nullability.cpp
===
--- test/SemaCXX/nullability.cpp
+++ test/SemaCXX/nullability.cpp
@@ -97,3 +97,23 @@
 
   TakeNonnull(ReturnNullable()); //expected-warning{{implicit conversion from nullable pointer 'void * _Nullable' to non-nullable pointer type 'void * _Nonnull}}
 }
+
+void ConditionalExpr(bool c) {
+  struct Base {};
+  struct Derived : Base {};
+
+  Base * _Nonnull p;
+  Base * _Nonnull nonnullB;
+  Base * _Nullable nullableB;
+  Derived * _Nonnull nonnullD;
+  Derived * _Nullable nullableD;
+
+  p = c ? nonnullB : nonnullD;
+  p = c ? nonnullB : nullableD; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableB : nonnullD; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableB : nullableD; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nonnullD : nonnullB;
+  p = c ? nonnullD : nullableB; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableD : nonnullB; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableD : nullableB; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+}
Index: test/Sema/nullability.c
===
--- test/Sema/nullability.c
+++ test/Sema/nullability.c
@@ -128,3 +128,70 @@
 
   accepts_nonnull_1(ptr); // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
 }
+
+// Check nullability of conditional expressions.
+void conditional_expr(int c) {
+  int * _Nonnull p;
+  int * _Nonnull nonnullP;
+  int * _Nullable nullableP;
+  int * _Null_unspecified unspecifiedP;
+  int *noneP;
+
+  p = c ? nonnullP : nonnullP;
+  p = c ? nonnullP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nonnullP : unspecifiedP;
+  p = c ? nonnullP : noneP;
+  p = c ? nullableP : nonnullP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nullableP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nullableP : unspecifiedP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nullableP : noneP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? unspecifiedP : nonnullP;
+  p = c ? unspecifiedP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? unspecifiedP : unspecifiedP;
+  p = c ? unspecifiedP : noneP;
+  p = c ? noneP : nonnullP;
+  p = c ? noneP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? noneP : unspecifiedP;
+  p = c ? noneP : noneP;
+
+  // Check that we don't remove all sugar when creating a new QualType for the
+  // conditional expression.
+  typedef int *IntP;
+  typedef IntP _Nonnull NonnullIntP0;
+  typedef NonnullIntP0 _Nonnull NonnullIntP1;
+  typedef IntP _Nullable NullableIntP0;
+  typedef NullableIntP0 _Nullable NullableIntP1;
+  NonnullIntP1 nonnullP2;
+  NullableIntP1 nullableP2;
+
+  p = c ? nonnullP2 : nonnullP2;
+  p = c ? nonnullP2 : nullableP2; // expected-warning{{implicit conversion from nullable pointer 'IntP _Nullable' (aka 'int *') to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nullableP2 : nonnullP2; // expected-warning{{implicit conversion from nullable pointer 'NullableIntP1' (aka 'int *') to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nullableP2 : nullableP2; // expected-warning{{implicit conversion from nullable pointer 'NullableIntP1' (aka 'int *') to non-nullable pointer type 'int * _Nonnull'}}
+}
+
+// Check nullability of binary co

[libcxxabi] r276016 - [libcxxabi] When catching an exception of type nullptr_t with a handler of

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Jul 19 15:19:37 2016
New Revision: 276016

URL: http://llvm.org/viewvc/llvm-project?rev=276016&view=rev
Log:
[libcxxabi] When catching an exception of type nullptr_t with a handler of
pointer-to-member type, produce a null value of the right type.

This fixes a bug where throwing an exception of type nullptr_t and catching it
as a pointer-to-member would not guarantee to produce a null value in the catch
handler. The fix is pretty simple: we statically allocate a constant null
pointer-to-data-member representation and a constant null
pointer-to-member-function representation, and produce the address of the
relevant value as the adjusted pointer for the exception.

Added:
libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp
Modified:
libcxxabi/trunk/src/private_typeinfo.cpp
libcxxabi/trunk/test/catch_const_pointer_nullptr.pass.cpp
libcxxabi/trunk/test/catch_member_pointer_nullptr.pass.cpp
libcxxabi/trunk/test/catch_pointer_nullptr.pass.cpp
libcxxabi/trunk/test/incomplete_type.sh.cpp

Modified: libcxxabi/trunk/src/private_typeinfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/private_typeinfo.cpp?rev=276016&r1=276015&r2=276016&view=diff
==
--- libcxxabi/trunk/src/private_typeinfo.cpp (original)
+++ libcxxabi/trunk/src/private_typeinfo.cpp Tue Jul 19 15:19:37 2016
@@ -171,8 +171,12 @@ __pointer_to_member_type_info::~__pointe
 // catch (D2& d2) : adjustedPtr == &d2  (d2 is base class of thrown object)
 // catch (D2* d2) : adjustedPtr == d2
 // catch (D2*& d2) : adjustedPtr == d2
-// 
+//
 // catch (...) : adjustedPtr == & of the exception
+//
+// If the thrown type is nullptr_t and the caught type is a pointer to
+// member type, adjustedPtr points to a statically-allocated null pointer
+// representation of that type.
 
 // Handles bullet 1
 bool
@@ -337,12 +341,11 @@ __vmi_class_type_info::has_unambiguous_p
 }
 }
 
-// Handles bullets 1 and 4 for both pointers and member pointers
+// Handles bullet 1 for both pointers and member pointers
 bool
 __pbase_type_info::can_catch(const __shim_type_info* thrown_type,
  void*&) const
 {
-if (is_equal(thrown_type, &typeid(std::nullptr_t), false)) return true;
 bool use_strcmp = this->__flags & (__incomplete_class_mask |
__incomplete_mask);
 if (!use_strcmp) {
@@ -367,7 +370,13 @@ bool
 __pointer_type_info::can_catch(const __shim_type_info* thrown_type,
void*& adjustedPtr) const
 {
-// bullets 1 and 4
+// bullet 4
+if (is_equal(thrown_type, &typeid(std::nullptr_t), false)) {
+  adjustedPtr = nullptr;
+  return true;
+}
+
+// bullet 1
 if (__pbase_type_info::can_catch(thrown_type, adjustedPtr)) {
 if (adjustedPtr != NULL)
 adjustedPtr = *static_cast(adjustedPtr);
@@ -468,7 +477,22 @@ bool __pointer_type_info::can_catch_nest
 
 bool __pointer_to_member_type_info::can_catch(
 const __shim_type_info* thrown_type, void*& adjustedPtr) const {
-// bullets 1 and 4
+// bullet 4
+if (is_equal(thrown_type, &typeid(std::nullptr_t), false)) {
+  // We assume that the pointer to member representation is the same for
+  // all pointers to data members and for all pointers to member functions.
+  struct X {};
+  if (dynamic_cast(__pointee)) {
+static int (X::*const null_ptr_rep)() = nullptr;
+adjustedPtr = const_cast(&null_ptr_rep);
+  } else {
+static int X::*const null_ptr_rep = nullptr;
+adjustedPtr = const_cast(&null_ptr_rep);
+  }
+  return true;
+}
+
+// bullet 1
 if (__pbase_type_info::can_catch(thrown_type, adjustedPtr))
 return true;
 

Modified: libcxxabi/trunk/test/catch_const_pointer_nullptr.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/catch_const_pointer_nullptr.pass.cpp?rev=276016&r1=276015&r2=276016&view=diff
==
--- libcxxabi/trunk/test/catch_const_pointer_nullptr.pass.cpp (original)
+++ libcxxabi/trunk/test/catch_const_pointer_nullptr.pass.cpp Tue Jul 19 
15:19:37 2016
@@ -29,8 +29,9 @@ void test1()
 throw nullptr;
 assert(false);
 }
-catch (A*)
+catch (A* p)
 {
+assert(!p);
 }
 catch (const A*)
 {
@@ -46,8 +47,9 @@ void test2()
 throw nullptr;
 assert(false);
 }
-catch (const A*)
+catch (const A* p)
 {
+assert(!p);
 }
 catch (A*)
 {
@@ -62,8 +64,9 @@ void test3()
 throw nullptr;
 assert(false);
 }
-catch (const A* const)
+catch (const A* const p)
 {
+assert(!p);
 }
 catch (A*)
 {
@@ -78,8 +81,9 @@ void test4()
 throw nullptr;
 assert(false);
 }
-catch (A*)
+catch (A* p)
 {
+  

Re: [PATCH] D22528: [libcxxabi] When catching an exception of type nullptr_t with a handler of pointer-to-member type, produce a null value of the right type

[Richard Smith via cfe-commits]

rsmith closed this revision.
rsmith added a comment.

Committed as r276016.


Repository:
  rL LLVM

https://reviews.llvm.org/D22528



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

r276020 - [SemaObjC] Improve ObjCDictionaryLiteral and ObjCArryLiteral diagnostics

[Bruno Cardoso Lopes via cfe-commits]

Author: bruno
Date: Tue Jul 19 15:21:18 2016
New Revision: 276020

URL: http://llvm.org/viewvc/llvm-project?rev=276020&view=rev
Log:
[SemaObjC] Improve ObjCDictionaryLiteral and ObjCArryLiteral diagnostics

Sema actions on ObjCDictionaryLiteral and ObjCArryLiteral are currently
done as a side-effect of Sema upon parent expressions, which incurs of
delayed typo corrections for such literals to be performed by TypoTransforms
upon the ObjCDictionaryLiteral and ObjCArryLiteral themselves instead of
its elements individually.

This is specially bad because it was not designed to act on several
elements; searching through all possible combinations of corrections for
several elements is very expensive. Additionally, when one of the
elements has no correction candidate, we still explore all options and
at the end emit no typo corrections whatsoever.

Do the proper sema actions by acting on each element alone during appropriate
literal parsing time to get proper diagonistics and decent compile time
behavior.

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

rdar://problem/21046678

Modified:
cfe/trunk/lib/Parse/ParseObjc.cpp
cfe/trunk/test/SemaObjC/objc-array-literal.m
cfe/trunk/test/SemaObjC/objc-dictionary-literal.m

Modified: cfe/trunk/lib/Parse/ParseObjc.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseObjc.cpp?rev=276020&r1=276019&r2=276020&view=diff
==
--- cfe/trunk/lib/Parse/ParseObjc.cpp (original)
+++ cfe/trunk/lib/Parse/ParseObjc.cpp Tue Jul 19 15:21:18 2016
@@ -3416,6 +3416,7 @@ ExprResult Parser::ParseObjCArrayLiteral
   ExprVector ElementExprs;   // array elements.
   ConsumeBracket(); // consume the l_square.
 
+  bool HasInvalidEltExpr = false;
   while (Tok.isNot(tok::r_square)) {
 // Parse list of array element expressions (all must be id types).
 ExprResult Res(ParseAssignmentExpression());
@@ -3427,11 +3428,15 @@ ExprResult Parser::ParseObjCArrayLiteral
   return Res;
 }
 
+Res = Actions.CorrectDelayedTyposInExpr(Res.get());
+if (Res.isInvalid())
+  HasInvalidEltExpr = true;
+
 // Parse the ellipsis that indicates a pack expansion.
 if (Tok.is(tok::ellipsis))
   Res = Actions.ActOnPackExpansion(Res.get(), ConsumeToken());
 if (Res.isInvalid())
-  return true;
+  HasInvalidEltExpr = true;
 
 ElementExprs.push_back(Res.get());
 
@@ -3442,6 +3447,10 @@ ExprResult Parser::ParseObjCArrayLiteral
 << tok::comma);
   }
   SourceLocation EndLoc = ConsumeBracket(); // location of ']'
+
+  if (HasInvalidEltExpr)
+return ExprError();
+
   MultiExprArg Args(ElementExprs);
   return Actions.BuildObjCArrayLiteral(SourceRange(AtLoc, EndLoc), Args);
 }
@@ -3449,6 +3458,7 @@ ExprResult Parser::ParseObjCArrayLiteral
 ExprResult Parser::ParseObjCDictionaryLiteral(SourceLocation AtLoc) {
   SmallVector Elements; // dictionary elements.
   ConsumeBrace(); // consume the l_square.
+  bool HasInvalidEltExpr = false;
   while (Tok.isNot(tok::r_brace)) {
 // Parse the comma separated key : value expressions.
 ExprResult KeyExpr;
@@ -3478,7 +3488,15 @@ ExprResult Parser::ParseObjCDictionaryLi
   return ValueExpr;
 }
 
-// Parse the ellipsis that designates this as a pack expansion.
+// Check the key and value for possible typos
+KeyExpr = Actions.CorrectDelayedTyposInExpr(KeyExpr.get());
+ValueExpr = Actions.CorrectDelayedTyposInExpr(ValueExpr.get());
+if (KeyExpr.isInvalid() || ValueExpr.isInvalid())
+  HasInvalidEltExpr = true;
+
+// Parse the ellipsis that designates this as a pack expansion. Do not
+// ActOnPackExpansion here, leave it to template instantiation time where
+// we can get better diagnostics.
 SourceLocation EllipsisLoc;
 if (getLangOpts().CPlusPlus)
   TryConsumeToken(tok::ellipsis, EllipsisLoc);
@@ -3495,6 +3513,9 @@ ExprResult Parser::ParseObjCDictionaryLi
 << tok::comma);
   }
   SourceLocation EndLoc = ConsumeBrace();
+
+  if (HasInvalidEltExpr)
+return ExprError();
   
   // Create the ObjCDictionaryLiteral.
   return Actions.BuildObjCDictionaryLiteral(SourceRange(AtLoc, EndLoc),

Modified: cfe/trunk/test/SemaObjC/objc-array-literal.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/objc-array-literal.m?rev=276020&r1=276019&r2=276020&view=diff
==
--- cfe/trunk/test/SemaObjC/objc-array-literal.m (original)
+++ cfe/trunk/test/SemaObjC/objc-array-literal.m Tue Jul 19 15:21:18 2016
@@ -67,3 +67,11 @@ id radar15147688() {
   x = @[ @"stuff", @"hello" "world"]; // expected-warning {{concatenated 
NSString literal for an NSArray expression}}
   return x;
 }
+
+enum XXXYYYZZZType { XXXYYYZZZTypeAny }; // expected-note {{'XXXYYY

Re: [PATCH] D22183: [SemObjC] Fix TypoExpr handling in TransformObjCDictionaryLiteral

[Bruno Cardoso Lopes via cfe-commits]

bruno closed this revision.
bruno added a comment.

Thanks Manman, Committed r276020


https://reviews.llvm.org/D22183



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

Re: [PATCH] D22392: [Sema] Fix an invalid nullability warning for binary conditional operators

[Akira Hatanaka via cfe-commits]

ahatanak updated this revision to Diff 64557.
ahatanak added a comment.

Remove the check "if (LHSKind == RHSKind)" in computeConditionalNullability as 
it's not needed.


https://reviews.llvm.org/D22392

Files:
  lib/Sema/SemaExpr.cpp
  test/Sema/nullability.c
  test/SemaCXX/nullability.cpp

Index: test/SemaCXX/nullability.cpp
===
--- test/SemaCXX/nullability.cpp
+++ test/SemaCXX/nullability.cpp
@@ -97,3 +97,23 @@
 
   TakeNonnull(ReturnNullable()); //expected-warning{{implicit conversion from nullable pointer 'void * _Nullable' to non-nullable pointer type 'void * _Nonnull}}
 }
+
+void ConditionalExpr(bool c) {
+  struct Base {};
+  struct Derived : Base {};
+
+  Base * _Nonnull p;
+  Base * _Nonnull nonnullB;
+  Base * _Nullable nullableB;
+  Derived * _Nonnull nonnullD;
+  Derived * _Nullable nullableD;
+
+  p = c ? nonnullB : nonnullD;
+  p = c ? nonnullB : nullableD; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableB : nonnullD; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableB : nullableD; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nonnullD : nonnullB;
+  p = c ? nonnullD : nullableB; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableD : nonnullB; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableD : nullableB; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+}
Index: test/Sema/nullability.c
===
--- test/Sema/nullability.c
+++ test/Sema/nullability.c
@@ -128,3 +128,70 @@
 
   accepts_nonnull_1(ptr); // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
 }
+
+// Check nullability of conditional expressions.
+void conditional_expr(int c) {
+  int * _Nonnull p;
+  int * _Nonnull nonnullP;
+  int * _Nullable nullableP;
+  int * _Null_unspecified unspecifiedP;
+  int *noneP;
+
+  p = c ? nonnullP : nonnullP;
+  p = c ? nonnullP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nonnullP : unspecifiedP;
+  p = c ? nonnullP : noneP;
+  p = c ? nullableP : nonnullP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nullableP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nullableP : unspecifiedP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nullableP : noneP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? unspecifiedP : nonnullP;
+  p = c ? unspecifiedP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? unspecifiedP : unspecifiedP;
+  p = c ? unspecifiedP : noneP;
+  p = c ? noneP : nonnullP;
+  p = c ? noneP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? noneP : unspecifiedP;
+  p = c ? noneP : noneP;
+
+  // Check that we don't remove all sugar when creating a new QualType for the
+  // conditional expression.
+  typedef int *IntP;
+  typedef IntP _Nonnull NonnullIntP0;
+  typedef NonnullIntP0 _Nonnull NonnullIntP1;
+  typedef IntP _Nullable NullableIntP0;
+  typedef NullableIntP0 _Nullable NullableIntP1;
+  NonnullIntP1 nonnullP2;
+  NullableIntP1 nullableP2;
+
+  p = c ? nonnullP2 : nonnullP2;
+  p = c ? nonnullP2 : nullableP2; // expected-warning{{implicit conversion from nullable pointer 'IntP _Nullable' (aka 'int *') to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nullableP2 : nonnullP2; // expected-warning{{implicit conversion from nullable pointer 'NullableIntP1' (aka 'int *') to non-nullable pointer type 'int * _Nonnull'}}
+  p = c ? nullableP2 : nullableP2; // expected-warning{{implicit conversion from nullable pointer 'NullableIntP1' (aka 'int *') to non-nullable pointer type 'int * _Nonnull'}}
+}
+
+// Check nullability of binary conditional expressions.
+void binary_conditional_expr() {
+  int * _Nonnull p;
+  int * _Nonnull nonnullP;

[libcxxabi] r276022 - Attempt to bring peace to -Werror buildbots.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Jul 19 15:35:09 2016
New Revision: 276022

URL: http://llvm.org/viewvc/llvm-project?rev=276022&view=rev
Log:
Attempt to bring peace to -Werror buildbots.

Modified:
libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp

Modified: libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp?rev=276022&r1=276021&r2=276022&view=diff
==
--- libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp (original)
+++ libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp Tue Jul 19 15:35:09 
2016
@@ -12,6 +12,12 @@
 #include 
 #include 
 
+// Clang emits a warning on converting an object of type nullptr_t to bool,
+// even in generic code. Suppress it.
+#if defined(__clang__)
+#pragma clang diagnostic ignored "-Wnull-conversion"
+#endif
+
 struct A {};
 
 template


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

Re: [PATCH] D21453: Add support for attribute "overallocated"

[Akira Hatanaka via cfe-commits]

ahatanak added a comment.

ping


https://reviews.llvm.org/D21453



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

Re: [PATCH] D22513: [clang-tidy] add check cppcoreguidelines-rule-of-five-and-zero

[Piotr Padlewski via cfe-commits]

Prazek added a subscriber: Prazek.


Comment at: clang-tidy/cppcoreguidelines/RuleOfFiveAndZeroCheck.cpp:73-77
@@ +72,7 @@
+
+  checkRuleOfFiveViolation(Result, "dtor", "destructor");
+  checkRuleOfFiveViolation(Result, "copy-ctor", "copy constructor");
+  checkRuleOfFiveViolation(Result, "copy-assign", "copy assignment operator");
+  checkRuleOfFiveViolation(Result, "move-ctor", "move constructor");
+  checkRuleOfFiveViolation(Result, "move-assign", "move assignment operator");
+}

I think it would be much better to aggregate the diagnosics.
E.g. if I declare 4 special functions then I will get 4 lines of warnings, and 
I won't even know what function did I forgot to declare.

So it should be better to fire diag on the first, or just one of the special 
function and say "class %0 defines {{list_here}} but doesn't define 
{{other_list}}"


Comment at: clang-tidy/cppcoreguidelines/RuleOfFiveAndZeroCheck.h:19
@@ +18,3 @@
+
+/// Checks for classes where some, but not all, of the special member functions
+/// are defined.

no comma after all. But I might be wrong because I am not certified grammar nazi


Comment at: 
docs/clang-tidy/checks/cppcoreguidelines-rule-of-five-and-zero.rst:11
@@ +10,3 @@
+move constructor, move assignment operator and destructor. The default can be
+supressed by explciti user-definitions. The relationship between which
+functions will be supressed by definitions of other functions is complicated

typo s/expliciti/explicit


Repository:
  rL LLVM

https://reviews.llvm.org/D22513



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

Re: [PATCH] D19544: Pass for translating math intrinsics to math library calls.

[Matt via cfe-commits]

mmasten updated this revision to Diff 64571.

https://reviews.llvm.org/D19544

Files:
  include/llvm/Analysis/TargetLibraryInfo.h
  lib/Analysis/TargetLibraryInfo.cpp
  test/Transforms/LoopVectorize/X86/svml-calls.ll

Index: lib/Analysis/TargetLibraryInfo.cpp
===
--- lib/Analysis/TargetLibraryInfo.cpp
+++ lib/Analysis/TargetLibraryInfo.cpp
@@ -23,6 +23,8 @@
   "No vector functions library"),
clEnumValN(TargetLibraryInfoImpl::Accelerate, "Accelerate",
   "Accelerate framework"),
+   clEnumValN(TargetLibraryInfoImpl::SVML, "SVML",
+  "Intel SVML library"),
clEnumValEnd));
 
 const char *const TargetLibraryInfoImpl::StandardNames[LibFunc::NumLibFuncs] = {
@@ -1074,6 +1076,75 @@
 addVectorizableFunctions(VecFuncs);
 break;
   }
+  case SVML: {
+const VecDesc VecFuncs[] = {
+{"sin", "__svml_sin2", 2},
+{"sin", "__svml_sin4", 4},
+{"sin", "__svml_sin8", 8},
+
+{"sinf", "__svml_sinf4", 4},
+{"sinf", "__svml_sinf8", 8},
+{"sinf", "__svml_sinf16", 16},
+
+{"cos", "__svml_cos2", 2},
+{"cos", "__svml_cos4", 4},
+{"cos", "__svml_cos8", 8},
+
+{"cosf", "__svml_cosf4", 4},
+{"cosf", "__svml_cosf8", 8},
+{"cosf", "__svml_cosf16", 16},
+
+{"pow", "__svml_pow2", 2},
+{"pow", "__svml_pow4", 4},
+{"pow", "__svml_pow8", 8},
+
+{"powf", "__svml_powf4", 4},
+{"powf", "__svml_powf8", 8},
+{"powf", "__svml_powf16", 16},
+
+{"llvm.pow.f64", "__svml_pow2", 2},
+{"llvm.pow.f64", "__svml_pow4", 4},
+{"llvm.pow.f64", "__svml_pow8", 8},
+
+{"llvm.pow.f32", "__svml_powf4", 4},
+{"llvm.pow.f32", "__svml_powf8", 8},
+{"llvm.pow.f32", "__svml_powf16", 16},
+
+{"exp", "__svml_exp2", 2},
+{"exp", "__svml_exp4", 4},
+{"exp", "__svml_exp8", 8},
+
+{"expf", "__svml_expf4", 4},
+{"expf", "__svml_expf8", 8},
+{"expf", "__svml_expf16", 16},
+
+{"llvm.exp.f64", "__svml_exp2", 2},
+{"llvm.exp.f64", "__svml_exp4", 4},
+{"llvm.exp.f64", "__svml_exp8", 8},
+
+{"llvm.exp.f32", "__svml_expf4", 4},
+{"llvm.exp.f32", "__svml_expf8", 8},
+{"llvm.exp.f32", "__svml_expf16", 16},
+
+{"log", "__svml_log2", 2},
+{"log", "__svml_log4", 4},
+{"log", "__svml_log8", 8},
+
+{"logf", "__svml_logf4", 4},
+{"logf", "__svml_logf8", 8},
+{"logf", "__svml_logf16", 16},
+
+{"llvm.log.f64", "__svml_log2", 2},
+{"llvm.log.f64", "__svml_log4", 4},
+{"llvm.log.f64", "__svml_log8", 8},
+
+{"llvm.log.f32", "__svml_logf4", 4},
+{"llvm.log.f32", "__svml_logf8", 8},
+{"llvm.log.f32", "__svml_logf16", 16},
+};
+addVectorizableFunctions(VecFuncs);
+break;
+  }
   case NoLibrary:
 break;
   }
Index: include/llvm/Analysis/TargetLibraryInfo.h
===
--- include/llvm/Analysis/TargetLibraryInfo.h
+++ include/llvm/Analysis/TargetLibraryInfo.h
@@ -85,8 +85,9 @@
   /// addVectorizableFunctionsFromVecLib for filling up the tables of
   /// vectorizable functions.
   enum VectorLibrary {
-NoLibrary, // Don't use any vector library.
-Accelerate // Use Accelerate framework.
+NoLibrary,  // Don't use any vector library.
+Accelerate, // Use Accelerate framework.
+SVML// Intel short vector math library.
   };
 
   TargetLibraryInfoImpl();
Index: test/Transforms/LoopVectorize/X86/svml-calls.ll
===
--- test/Transforms/LoopVectorize/X86/svml-calls.ll
+++ test/Transforms/LoopVectorize/X86/svml-calls.ll
@@ -0,0 +1,185 @@
+; RUN: opt -vector-library=SVML -loop-vectorize -S < %s | FileCheck %s
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+; CHECK-LABEL: @sin_f32
+; CHECK: <4 x float> @__svml_sinf4
+; CHECK: ret
+
+declare float @sinf(float) nounwind readnone
+
+define void @sin_f32(float* nocapture %varray) {
+entry:
+  br label %for.body
+
+for.body: ; preds = %for.body, %entry
+  %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ]
+  %0 = trunc i64 %indvars.iv to i32
+  %conv = sitofp i32 %0 to float
+  %call = tail call fast float @sinf(float %conv)
+  %arrayidx = getelementptr inbounds float, float* %varray, i64 %indvars.iv
+  store float %call, float* %arrayidx, align 4
+  %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
+  %exitcond = icmp eq i64 %indvars.iv.next, 1000
+  br i1 %exitcond, label %for.end, label %for.body
+
+for.end:  ; preds = %for.body
+  ret void
+}
+
+; CHECK-LABEL: @cos_f32
+; CHECK: <4 x fl

[PATCH] D22542: [CodeGen] Fix a crash on valid when constant folding 'default:' statement in switch

[Erik Pilkington via cfe-commits]

erik.pilkington created this revision.
erik.pilkington added reviewers: rsmith, manmanren.
erik.pilkington added a subscriber: cfe-commits.

The following valid code crashes Clang in CodeGen:
```
void other_test() {
  switch(0) {
  case 0:
do {
default:;
} while(0);
  }
}
```
The problem is that when we constant fold the switch into the `case 0:` case, 
the `default:` attempts to find the enclosing switch it is attached to, which 
does not exist. The solution is to ignore the `default` and emit it's child 
statement. (Which is the exact same solution as in the `case` statement, in 
`EmitCaseStmt` just above this)

Fixes PR28609.

https://reviews.llvm.org/D22542

Files:
  lib/CodeGen/CGStmt.cpp
  test/CodeGenCXX/switch-case-folding-2.cpp

Index: test/CodeGenCXX/switch-case-folding-2.cpp
===
--- test/CodeGenCXX/switch-case-folding-2.cpp
+++ test/CodeGenCXX/switch-case-folding-2.cpp
@@ -18,4 +18,13 @@
  return test(5);
 }
 
+void other_test() {
+  switch(0) {
+  case 0:
+do {
+default:;
+} while(0);
+  }
+}
+
 // CHECK: call i32 (i8*, ...) @_Z6printfPKcz
Index: lib/CodeGen/CGStmt.cpp
===
--- lib/CodeGen/CGStmt.cpp
+++ lib/CodeGen/CGStmt.cpp
@@ -1261,6 +1261,14 @@
 }
 
 void CodeGenFunction::EmitDefaultStmt(const DefaultStmt &S) {
+  // If there is no enclosing switch instance that we're aware of, then this
+  // default statement can be elided. This situation only happens when we've
+  // constant-folded the switch.
+  if (!SwitchInsn) {
+EmitStmt(S.getSubStmt());
+return;
+  }
+
   llvm::BasicBlock *DefaultBlock = SwitchInsn->getDefaultDest();
   assert(DefaultBlock->empty() &&
  "EmitDefaultStmt: Default block already defined?");


Index: test/CodeGenCXX/switch-case-folding-2.cpp
===
--- test/CodeGenCXX/switch-case-folding-2.cpp
+++ test/CodeGenCXX/switch-case-folding-2.cpp
@@ -18,4 +18,13 @@
  return test(5);
 }
 
+void other_test() {
+  switch(0) {
+  case 0:
+do {
+default:;
+} while(0);
+  }
+}
+
 // CHECK: call i32 (i8*, ...) @_Z6printfPKcz
Index: lib/CodeGen/CGStmt.cpp
===
--- lib/CodeGen/CGStmt.cpp
+++ lib/CodeGen/CGStmt.cpp
@@ -1261,6 +1261,14 @@
 }
 
 void CodeGenFunction::EmitDefaultStmt(const DefaultStmt &S) {
+  // If there is no enclosing switch instance that we're aware of, then this
+  // default statement can be elided. This situation only happens when we've
+  // constant-folded the switch.
+  if (!SwitchInsn) {
+EmitStmt(S.getSubStmt());
+return;
+  }
+
   llvm::BasicBlock *DefaultBlock = SwitchInsn->getDefaultDest();
   assert(DefaultBlock->empty() &&
  "EmitDefaultStmt: Default block already defined?");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D22543: [libunwind] Properly align _Unwind_Exception.

[Eric Fiselier via cfe-commits]

EricWF created this revision.
EricWF added reviewers: mclow.lists, compnerd.
EricWF added a subscriber: cfe-commits.

_Unwind_Exception is required to be double word aligned. Currently the struct 
is under aligned.

https://reviews.llvm.org/D22543

Files:
  include/unwind.h
  test/alignment.pass.cpp

Index: test/alignment.pass.cpp
===
--- /dev/null
+++ test/alignment.pass.cpp
@@ -0,0 +1,21 @@
+// -*- C++ -*-
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// The Itanium ABI requires that _Unwind_Exception objects are "double-word
+// aligned".
+
+#include 
+
+struct MaxAligned {} __attribute__((aligned));
+static_assert(alignof(_Unwind_Exception) == alignof(MaxAligned), "");
+
+int main()
+{
+}
Index: include/unwind.h
===
--- include/unwind.h
+++ include/unwind.h
@@ -122,13 +122,16 @@
   uintptr_t private_1; // non-zero means forced unwind
   uintptr_t private_2; // holds sp that phase1 found for phase2 to use
 #ifndef __LP64__
-  // The gcc implementation of _Unwind_Exception used attribute mode on the
-  // above fields which had the side effect of causing this whole struct to
+  // The implementation of _Unwind_Exception uses an attribute mode on the
+  // above fields which has the side effect of causing this whole struct to
   // round up to 32 bytes in size. To be more explicit, we add pad fields
   // added for binary compatibility.
   uint32_t reserved[3];
 #endif
-};
+  // The Itanium ABI requires that _Unwind_Exception objects are "double-word
+  // aligned".  GCC has interpreted this to mean "use the maximum useful
+  // alignment for the target"; so do we.
+} __attribute__((__aligned__));
 
 typedef _Unwind_Reason_Code (*_Unwind_Stop_Fn)
 (int version,


Index: test/alignment.pass.cpp
===
--- /dev/null
+++ test/alignment.pass.cpp
@@ -0,0 +1,21 @@
+// -*- C++ -*-
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// The Itanium ABI requires that _Unwind_Exception objects are "double-word
+// aligned".
+
+#include 
+
+struct MaxAligned {} __attribute__((aligned));
+static_assert(alignof(_Unwind_Exception) == alignof(MaxAligned), "");
+
+int main()
+{
+}
Index: include/unwind.h
===
--- include/unwind.h
+++ include/unwind.h
@@ -122,13 +122,16 @@
   uintptr_t private_1; // non-zero means forced unwind
   uintptr_t private_2; // holds sp that phase1 found for phase2 to use
 #ifndef __LP64__
-  // The gcc implementation of _Unwind_Exception used attribute mode on the
-  // above fields which had the side effect of causing this whole struct to
+  // The implementation of _Unwind_Exception uses an attribute mode on the
+  // above fields which has the side effect of causing this whole struct to
   // round up to 32 bytes in size. To be more explicit, we add pad fields
   // added for binary compatibility.
   uint32_t reserved[3];
 #endif
-};
+  // The Itanium ABI requires that _Unwind_Exception objects are "double-word
+  // aligned".  GCC has interpreted this to mean "use the maximum useful
+  // alignment for the target"; so do we.
+} __attribute__((__aligned__));
 
 typedef _Unwind_Reason_Code (*_Unwind_Stop_Fn)
 (int version,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits