date:20160712

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

2016-07-12 Thread Haojian Wu via cfe-commits

hokein added inline comments.


Comment at: clang-tidy/cppcoreguidelines/SlicingCheck.cpp:48
@@ +47,3 @@
+
+  // Assignement slicing: "a = b;" and "a = std::move(b);" variants.
+  const auto SlicesObjectInAssignment =

courbet wrote:
> hokein wrote:
> > Looks like you are missing some cases here, like assigning a Subclass 
> > object from a function call to a Baseclass object, passing a Subclass 
> > object to a function whose parameter is a BaseClass.
> > 
> > But I think it's fine to implement in a separate patch, but you'd better to 
> > add a TODO here.
> > 
> > ```
> > SubClass f1();
> > BaseClass a = f1();
> > 
> > void f1(BaseClass a);
> > SubClass sc;
> > f1(sc);
> > ```
> Actually these will still create a CXXConstructExpr in the AST, e.g for case 
> (2):
> 
> ```
> CallExpr 0x3d6e560  
> 'void'
> |-ImplicitCastExpr 0x3d6e548  'void (*)(class A)' 
> 
> | `-DeclRefExpr 0x3d6e4f8  'void (class A)' lvalue Function 0x3d66550 
> 'g' 'void (class A)'
> `-CXXConstructExpr 0x3d6e5c8  'class A' 'void (const class A &) 
> throw()'
>   `-ImplicitCastExpr 0x3d6e5b0  'const class A' lvalue 
> `-ImplicitCastExpr 0x3d6e590  'class A' lvalue 
>   `-DeclRefExpr 0x3d6e4d0  'class B' lvalue Var 0x3d6e300 'b' 
> 'class B'
> ```
> 
> I alreagy have a test to case (2) and I've added one for case (1).
> 
Oh, I see it now. Sorry for missing them and thanks for explanation.  It'd be 
more clear to if you can update comments at `SlicesObjectInCtor`.


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

Maybe alexfh@ has idea about this. Output multiple warning messages in a same 
location is not the pattern of clang-tidy message. I think we should combine 
three message into exact one, something like `"slicing object from type 'B' to 
'A' discards override 'f', 'g', 4*sizeof(char) bytes of state"`.




Comment at: docs/clang-tidy/checks/cppcoreguidelines-slicing.rst:24
@@ +23,2 @@
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c145-access-polymorphic-objects-through-pointers-and-references
+

There is an extra blank line at the bottom.


Comment at: test/clang-tidy/cppcoreguidelines-slicing.cpp:95
@@ +94,3 @@
+  // Derived type overrides methods, but these methods are not in the base 
type,
+  // so cannot be called accidentally. Righ tnow this triggers, but we might
+  // want to allow it.

s/tnow/now


http://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] D22129: [clang-rename] add documentation

2016-07-12 Thread Kirill Bobyrev via cfe-commits

omtcyf0 updated this revision to Diff 63646.
omtcyf0 marked 6 inline comments as done.
omtcyf0 added a comment.

Fixed.

Thanks for the feedback!


http://reviews.llvm.org/D22129

Files:
  docs/clang-rename.rst

Index: docs/clang-rename.rst
===
--- /dev/null
+++ docs/clang-rename.rst
@@ -0,0 +1,99 @@
+
+Clang-Rename
+
+
+.. contents::
+
+See also:
+
+.. toctree::
+   :maxdepth: 1
+
+
+:program:`clang-rename` is a clang-based C++ "linter" tool. Its purpose is to
+perform efficient renaming actions in large-scale projects such as renaming
+classes, functions, variables, arguments, namespaces etc.
+
+The tool is in a very early development stage, so you might encounter bugs and
+crashes. Submitting reports with information about how to reproduce the issue
+to `the LLVM bugtracker `_ will definitely help the
+project. If you have any ideas or suggestions, you might want to put a feature
+request there.
+
+Using clang-rename
+==
+
+:program:`clang-rename` is a `LibTooling
+`_-based tool, and it's easier to
+work with if you set up a compile command database for your project (for an
+example of how to do this see `How To Setup Tooling For LLVM
+`_). You can also
+specify compilation options on the command line after ``--``:
+
+.. code-block:: console
+
+  $ clang-rename -offset=42 -new-name=foo test.cpp -- -Imy_project/include -DMY_DEFINES ...
+
+
+To get an offset of a symbol in a file run
+
+.. code-block:: console
+
+  $ grep -FUbo 'foo' file.cpp
+
+
+The tool currently supports renaming actions inside a single Translation Unit
+only. It is planned to extend the tool's functionality to support multi-TU
+renaming actions in the future.
+
+:program:`clang-rename` also aims to be easily integrated into popular text
+editors, such as Vim, and improve the workflow of users.
+
+Although a command line interface exists, it is highly recommended to use the
+text editor interface instead for better experience.
+
+.. code-block:: console
+
+  $ clang-rename -help
+  OVERVIEW: A tool to rename symbols in C/C++ code.
+  clang-rename renames every occurrence of a symbol found at  in
+  . If -i is specified, the edited files are overwritten to disk.
+  Otherwise, the results are written to stdout.
+
+  USAGE: clang-rename [subcommand] [options]  [... ]
+
+  OPTIONS:
+
+  Clang-rename options:
+
+-export-fixes=   - YAML file to store suggested fixes in.
+-extra-arg=- Additional argument to append to the compiler command line
+-extra-arg-before= - Additional argument to prepend to the compiler command line
+-i - Overwrite edited s.
+-new-name= - The new name to change the symbol to.
+-offset= - Locates the symbol by offset as opposed to :.
+-old-name= - The fully qualified name of the symbol, if -offset is not used.
+-p=- Build path
+-pl- Print the locations affected by renaming to stderr.
+-pn- Print the found symbol's name prior to renaming to stderr.
+
+  Generic Options:
+
+-help  - Display available options (-help-hidden for more)
+-help-list - Display list of available options (-help-list-hidden for more)
+-version   - Display the version of this program
+
+
+clang-rename Vim integration
+
+
+You can call :program:`clang-rename` directly from Vim! To set up
+:program:`clang-rename` integration for Vim see
+`clang-rename/tool/clang-rename.py
+`_.
+
+Once installed, you can point your cursor to the symbols you want to rename,
+press `,cr` and print new desired name.
+
+Please note that **you have to save all buffers, in which the replacement will
+happen before running the tool**.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22102: [clang-rename] extend testset

2016-07-12 Thread Kirill Bobyrev via cfe-commits

omtcyf0 updated this revision to Diff 63647.

http://reviews.llvm.org/D22102

Files:
  test/clang-rename/FunctionMacro.cpp
  test/clang-rename/Namespace.cpp
  test/clang-rename/TemplateTypename.cpp
  test/clang-rename/VariableMacro.cpp
  test/clang-rename/VirtualFunction.cpp

Index: test/clang-rename/VirtualFunction.cpp
===
--- /dev/null
+++ test/clang-rename/VirtualFunction.cpp
@@ -0,0 +1,13 @@
+// Currently unsupported test.
+// FIXME: after passing A::foo() to clang-rename the tools should also rename
+// B:foo(), which overrides A::foo().
+
+class A {
+public:
+  virtual void foo();
+};
+
+class B : public A {
+public:
+  void foo();
+};
Index: test/clang-rename/VariableMacro.cpp
===
--- /dev/null
+++ test/clang-rename/VariableMacro.cpp
@@ -0,0 +1,18 @@
+// RUN: cat %s > %t.cpp
+// RUN: clang-rename -offset=208 -new-name=Z %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
+
+#define Y X // CHECK: #define Y Z
+
+void foo(int value) {}
+
+void macro() {
+  int X;// CHECK: int Z;
+  X = 42;   // CHECK: Z = 42;
+  Y -= 0;
+  foo(X);   // CHECK: foo(Z);
+  foo(Y);
+}
+
+// Use grep -FUbo 'foo;'  to get the correct offset of foo when changing
+// this file.
Index: test/clang-rename/TemplateTypename.cpp
===
--- /dev/null
+++ test/clang-rename/TemplateTypename.cpp
@@ -0,0 +1,16 @@
+// RUN: cat %s > %t.cpp
+// RUN: clang-rename -offset=152 -new-name=U %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
+// XFAIL: *
+
+template  // CHECK: template 
+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;  // CHECK: value = (U)number;
+  value = static_cast(number); // CHECK: value = static_cast(number);
+  return value;
+}
+
+// Use grep -FUbo 'foo;'  to get the correct offset of foo when changing
+// this file.
Index: test/clang-rename/Namespace.cpp
===
--- /dev/null
+++ test/clang-rename/Namespace.cpp
@@ -0,0 +1,14 @@
+// RUN: cat %s > %t.cpp
+// RUN: clang-rename -offset=143 -new-name=llvm %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
+
+namespace foo { // CHECK: namespace llvm {
+  int x;
+}
+
+void boo() {
+  foo::x = 42;  // CHECK: llvm::x = 42;
+}
+
+// Use grep -FUbo 'foo;'  to get the correct offset of foo when changing
+// this file.
Index: test/clang-rename/FunctionMacro.cpp
===
--- /dev/null
+++ test/clang-rename/FunctionMacro.cpp
@@ -0,0 +1,21 @@
+// RUN: cat %s > %t.cpp
+// RUN: clang-rename -offset=199 -new-name=macro_function %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
+
+#define moo foo // CHECK: #define moo macro_function
+
+int foo() { // CHECK: int macro_function() {
+  return 42;
+}
+
+void boo(int value) {}
+
+void qoo() {
+  foo();// CHECK: macro_function();
+  boo(foo());   // CHECK: boo(macro_function());
+  moo();
+  boo(moo());
+}
+
+// Use grep -FUbo 'foo;'  to get the correct offset of foo when changing
+// this file.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D22260: [clang-tidy] Fix misc-definitions-in-headers misplaced fixing to fully templated function.

2016-07-12 Thread Haojian Wu via cfe-commits

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

http://reviews.llvm.org/D22260

Files:
  clang-tidy/misc/DefinitionsInHeadersCheck.cpp
  test/clang-tidy/misc-definitions-in-headers.hpp

Index: test/clang-tidy/misc-definitions-in-headers.hpp
===
--- test/clang-tidy/misc-definitions-in-headers.hpp
+++ test/clang-tidy/misc-definitions-in-headers.hpp
@@ -29,6 +29,7 @@
 template <>
 int CA::f3() {
 // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: function 'f3' defined in a 
header file;
+// CHECK-FIXES: inline int CA::f3() {
   int a = 1;
   return a;
 }
@@ -90,8 +91,9 @@
 }
 
 template <>
-// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: function 'f3' defined in a 
header file;
 int f3() {
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f3' defined in a 
header file;
+// CHECK-FIXES: inline int f3() {
   int a = 1;
   return a;
 }
@@ -153,6 +155,7 @@
 
 int CD::f() {
 // CHECK-MESSAGES: :[[@LINE-1]]:19: warning: function 'f' defined in a header 
file;
+// CHECK-FIXES: inline int CD::f() {
   return 0;
 }
 
Index: clang-tidy/misc/DefinitionsInHeadersCheck.cpp
===
--- clang-tidy/misc/DefinitionsInHeadersCheck.cpp
+++ clang-tidy/misc/DefinitionsInHeadersCheck.cpp
@@ -126,8 +126,8 @@
 diag(FD->getLocation(),
  "function %0 defined in a header file; "
  "function definitions in header files can lead to ODR violations")
-<< FD << FixItHint::CreateInsertion(FD->getSourceRange().getBegin(),
-"inline ");
+<< FD << FixItHint::CreateInsertion(
+ FD->getReturnTypeSourceRange().getBegin(), "inline ");
   } else if (const auto *VD = dyn_cast(ND)) {
 // Static data members of a class template are allowed.
 if (VD->getDeclContext()->isDependentContext() && VD->isStaticDataMember())


Index: test/clang-tidy/misc-definitions-in-headers.hpp
===
--- test/clang-tidy/misc-definitions-in-headers.hpp
+++ test/clang-tidy/misc-definitions-in-headers.hpp
@@ -29,6 +29,7 @@
 template <>
 int CA::f3() {
 // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: function 'f3' defined in a header file;
+// CHECK-FIXES: inline int CA::f3() {
   int a = 1;
   return a;
 }
@@ -90,8 +91,9 @@
 }
 
 template <>
-// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: function 'f3' defined in a header file;
 int f3() {
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f3' defined in a header file;
+// CHECK-FIXES: inline int f3() {
   int a = 1;
   return a;
 }
@@ -153,6 +155,7 @@
 
 int CD::f() {
 // CHECK-MESSAGES: :[[@LINE-1]]:19: warning: function 'f' defined in a header file;
+// CHECK-FIXES: inline int CD::f() {
   return 0;
 }
 
Index: clang-tidy/misc/DefinitionsInHeadersCheck.cpp
===
--- clang-tidy/misc/DefinitionsInHeadersCheck.cpp
+++ clang-tidy/misc/DefinitionsInHeadersCheck.cpp
@@ -126,8 +126,8 @@
 diag(FD->getLocation(),
  "function %0 defined in a header file; "
  "function definitions in header files can lead to ODR violations")
-<< FD << FixItHint::CreateInsertion(FD->getSourceRange().getBegin(),
-"inline ");
+<< FD << FixItHint::CreateInsertion(
+ FD->getReturnTypeSourceRange().getBegin(), "inline ");
   } else if (const auto *VD = dyn_cast(ND)) {
 // Static data members of a class template are allowed.
 if (VD->getDeclContext()->isDependentContext() && VD->isStaticDataMember())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22254: [ARM, AArch64] Adds builtins to get current SP and PC

2016-07-12 Thread Renato Golin via cfe-commits

rengolin requested changes to this revision.
rengolin added a reviewer: rengolin.
rengolin added a comment.
This revision now requires changes to proceed.

Hi Weiming,

We've discussed about creating builtins when I added support for named 
registers and the consensus was that, since there is already a way to access 
them, there is no point in adding a new builtin.

cheers,
--renato


http://reviews.llvm.org/D22254



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

Re: [PATCH] D21991: [libunwind][ARM] Improve unwinder stack usage - Make WMMX support optional

2016-07-12 Thread Asiri Rathnayake via cfe-commits

rmaprath added inline comments.


Comment at: src/Registers.hpp:1497
@@ -1479,3 +1496,3 @@
 _LIBUNWIND_ABORT("unsupported arm register");
 }
 

compnerd wrote:
> rmaprath wrote:
> > compnerd wrote:
> > > Early returns would be nicer imo.
> > Not sure if I follow, did you mean to check the bounds of `regNum` the 
> > first thing and `_LIBUNWIND_ABORT` sooner than later? Might convolute the 
> > code given the conditional on `__ARM_WMMX` and I'm not sure what benefit it 
> > brings? Or perhaps I misunderstood you?
> > 
> > I'll commit the current patch as it is for the moment and then do a 
> > clean-up (once I understand what you mean).
> > 
> > Thanks.
> Oh, that was meant, as, we can write the code a slight bit nicer, which is 
> beyond the scope of your change.  If you don't mind doing a bit more clean up 
> -- a follow up patch to improve this would be appreciated!
> 
> Basically, we have a number of if/else if cases with a unreachable.  We 
> should replace this with a series of
> 
> if () {
>   
>   return;
> }
Fixed in r274840

http://llvm.org/viewvc/llvm-project?view=revision&revision=274840

Thanks.

/ Asiri


Repository:
  rL LLVM

http://reviews.llvm.org/D21991



___
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

2016-07-12 Thread Dmitry Polukhin via cfe-commits

DmitryPolukhin added a comment.

Friendly ping, PTAL!


http://reviews.llvm.org/D21970



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

[PATCH] D22263: [clang-tidy] Fix syntax error in modernize-use-emplace.rst

2016-07-12 Thread Martin Böhme via cfe-commits

mboehme created this revision.
mboehme added a reviewer: alexfh.
mboehme added a subscriber: cfe-commits.

The missing newline after the ".. code:: c++" was causing a compile error when 
producing the documentation

http://reviews.llvm.org/D22263

Files:
  docs/clang-tidy/checks/modernize-use-emplace.rst

Index: docs/clang-tidy/checks/modernize-use-emplace.rst
===
--- docs/clang-tidy/checks/modernize-use-emplace.rst
+++ docs/clang-tidy/checks/modernize-use-emplace.rst
@@ -48,6 +48,7 @@
 In this case the calls of ``push_back`` won't be replaced.
 
 .. code:: c++
+
std::vector > v;
v.push_back(new int(5));
auto *ptr = int;


Index: docs/clang-tidy/checks/modernize-use-emplace.rst
===
--- docs/clang-tidy/checks/modernize-use-emplace.rst
+++ docs/clang-tidy/checks/modernize-use-emplace.rst
@@ -48,6 +48,7 @@
 In this case the calls of ``push_back`` won't be replaced.
 
 .. code:: c++
+
 	std::vector > v;
 	v.push_back(new int(5));
 	auto *ptr = int;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D21385: Adjust Registry interface to not require plugins to export a registry

2016-07-12 Thread Rudy Pons via cfe-commits

Ilod added a comment.

I don't have write access to SVN, so IIUC LLVM policy says I can't approve a 
patch.


Repository:
  rL LLVM

http://reviews.llvm.org/D21385



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

Re: [PATCH] D21599: [Libcxx][MIPS] Use LLVM CheckAtomic.cmake module to figure out whether we need to link with libatomic.

2016-07-12 Thread Daniel Sanders via cfe-commits

dsanders added a comment.

What sets HAVE_CXX_LIBATOMICS64? I don't see a reference to LLVM's CheckAtomic.


Repository:
  rL LLVM

http://reviews.llvm.org/D21599



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

Re: [PATCH] D22220: [clang-tidy] Add check 'misc-move-forwarding-reference'

2016-07-12 Thread Martin Böhme via cfe-commits

mboehme updated this revision to Diff 63663.
mboehme added a comment.

Addressed Prazek's review comments.


http://reviews.llvm.org/D0

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/MoveForwardingReferenceCheck.cpp
  clang-tidy/misc/MoveForwardingReferenceCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-move-forwarding-reference.rst
  test/clang-tidy/misc-move-forwarding-reference.cpp

Index: test/clang-tidy/misc-move-forwarding-reference.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-move-forwarding-reference.cpp
@@ -0,0 +1,83 @@
+// RUN: %check_clang_tidy %s misc-move-forwarding-reference %t
+
+namespace std {
+template  struct remove_reference;
+
+template  struct remove_reference { typedef _Tp type; };
+
+template  struct remove_reference<_Tp &> { typedef _Tp type; };
+
+template  struct remove_reference<_Tp &&> { typedef _Tp type; };
+
+template 
+constexpr typename std::remove_reference<_Tp>::type &&move(_Tp &&__t);
+
+} // namespace std
+
+// Standard case.
+template  void f(U &&SomeU) {
+  T SomeT(std::move(SomeU));
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: forwarding reference passed to
+  // CHECK-FIXES: T SomeT(std::forward(SomeU));
+}
+
+// Ignore parentheses around the argument to std::move().
+template  void f2(U &&SomeU) {
+  T SomeT(std::move((SomeU)));
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: forwarding reference passed to
+  // CHECK-FIXES: T SomeT(std::forward((SomeU)));
+}
+
+// Handle the case correctly where std::move() is being used through a using
+// declaration.
+template  void f3(U &&SomeU) {
+  using std::move;
+  T SomeT(move(SomeU));
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: forwarding reference passed to
+  // CHECK-FIXES: T SomeT(std::forward(SomeU));
+}
+
+// Handle the case correctly where a global specifier is prepended to
+// std::move().
+template  void f4(U &&SomeU) {
+  T SomeT(::std::move(SomeU));
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: forwarding reference passed to
+  // CHECK-FIXES: T SomeT(::std::forward(SomeU));
+}
+
+// Ignore const rvalue reference parameters.
+template  void f5(const U &&SomeU) {
+  T SomeT(std::move(SomeU));
+}
+
+// Ignore the case where the argument to std::move() is a lambda parameter (and
+// thus not actually a parameter of the function template).
+template  void f6() {
+  [](U &&SomeU) { T SomeT(std::move(SomeU)); };
+}
+
+// Ignore the case where the argument is a lvalue reference.
+template  void f7(U &SomeU) {
+  T SomeT(std::move(SomeU));
+}
+
+// Ignore the case where the template parameter is a class template parameter
+// (i.e. no template argument deduction is taking place).
+template  class SomeClass {
+  void f(U &&SomeU) { T SomeT(std::move(SomeU)); }
+};
+
+// No warning is output if the std::move happens inside a macro.
+#define MOVE(x) std::move((x))
+template  void f8(U &&SomeU) {
+  T SomeT(MOVE(SomeU));
+}
+
+// A warning is output, but no fix is suggested, if a macro is used to rename
+// std::move but the argument is passed outside of the macro.
+#undef MOVE
+#define MOVE std::move
+template  void f9(U &&SomeU) {
+  T SomeT(MOVE(SomeU));
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: forwarding reference passed to
+}
Index: docs/clang-tidy/checks/misc-move-forwarding-reference.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-move-forwarding-reference.rst
@@ -0,0 +1,60 @@
+.. title:: clang-tidy - misc-move-forwarding-reference
+
+misc-move-forwarding-reference
+==
+
+Warns if ``std::move`` is called on a forwarding reference, for example:
+
+  .. code-block:: c++
+
+template 
+void foo(T&& t) {
+  bar(std::move(t));
+}
+
+`Forwarding references
+`_ should
+typically be passed to ``std::forward`` instead of ``std::move``, and this is
+the fix that will be suggested.
+
+(A forwarding reference is an rvalue reference of a type that is a deduced
+function template argument.)
+
+In this example, the suggested fix would be
+
+  .. code-block:: c++
+
+bar(std::forward(t));
+
+Background
+--
+
+Code like the example above is often written in the expectation that ``T&&``
+will always end up being an rvalue reference, no matter what type is deduced for
+``T``, and that it is therefore not possible to pass an lvalue to ``foo()``.
+However, this is not true. Consider this example:
+
+  .. code-block:: c++
+
+std::string s = "Hello, world";
+foo(s);
+
+This code compiles and, after the call to ``foo()``, ``s`` is left in an
+indeterminate state because it has been moved from. This may be surprising to
+the caller of ``foo()`` because no ``std::move`` was used when calling
+``foo()``.
+
+The reason for this behavior lies in the special rule for t

Re: [PATCH] D22220: [clang-tidy] Add check 'misc-move-forwarding-reference'

2016-07-12 Thread Martin Böhme via cfe-commits

mboehme marked 5 inline comments as done.
mboehme added a comment.

In http://reviews.llvm.org/D0#480415, @mgehre wrote:

> Nice check. This should be mentioned in docs/ReleaseNotes.rst


Done.



Comment at: clang-tidy/misc/MoveForwardingReferenceCheck.cpp:34
@@ +33,3 @@
+  if (CallRange.isValid()) {
+const std::string ForwardName =
+"forward<" + TypeParmType->getDecl()->getName().str() + ">";

Prazek wrote:
> you could probably use llvm::StringRef here, but I am not sure about it - ask 
> Alex.
I've talked to Alex -- using a Twine to avoid multiple allocations is the best 
I can do here.


Comment at: docs/clang-tidy/checks/misc-move-forwarding-reference.rst:29
@@ +28,3 @@
+
+Background
+--

Prazek wrote:
> Very nice section! good idea.
> 
> So I have a thoughts about multiple sections in documentation (which is not a 
> issue for you).
> I think the check lists doc should not include sections - it doesn't look 
> good and it also prevents people from using sections in docs.
Do I understand correctly that you're not expecting me to change anything here?


http://reviews.llvm.org/D0



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

Re: [PATCH] D21599: [Libcxx][MIPS] Use LLVM CheckAtomic.cmake module to figure out whether we need to link with libatomic.

2016-07-12 Thread Daniel Sanders via cfe-commits

dsanders added a comment.

Have you tried a standalone build? I suspect HAVE_CXX_LIBATOMICS64 will never 
be set for that case. If that's the case, adding 'include(CheckAtomic)' will 
probably fix it.


Repository:
  rL LLVM

http://reviews.llvm.org/D21599



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

Re: [PATCH] D21599: [Libcxx][MIPS] Use LLVM CheckAtomic.cmake module to figure out whether we need to link with libatomic.

2016-07-12 Thread Daniel Sanders via cfe-commits

dsanders added a comment.

I haven't used it that way either and I'm not sure it's a supported build for 
libcxx but most LLVM projects support a standalone build as far as I know. Can 
someone from the libcxx project confirm whether standalone builds are supported?


Repository:
  rL LLVM

http://reviews.llvm.org/D21599



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

Re: [PATCH] D21599: [Libcxx][MIPS] Use LLVM CheckAtomic.cmake module to figure out whether we need to link with libatomic.

2016-07-12 Thread Nitesh Jain via cfe-commits

nitesh.jain added a comment.

Hi Daniel/Vasileios

Please could you find sometime to review this?

Thanks


Repository:
  rL LLVM

http://reviews.llvm.org/D21599



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

Re: [PATCH] D21599: [Libcxx][MIPS] Use LLVM CheckAtomic.cmake module to figure out whether we need to link with libatomic.

2016-07-12 Thread Nitesh Jain via cfe-commits

nitesh.jain added a comment.

In http://reviews.llvm.org/D21599#481553, @dsanders wrote:

> What sets HAVE_CXX_LIBATOMICS64? I don't see a reference to LLVM's 
> CheckAtomic.

The CheckAtomic.cmake module (http://reviews.llvm.org/D20896) in llvm will set  
HAVE_CXX_LIBATOMICS64 if library exit and atomics work with it. This value then 
can be read from LLVM CMake cache.

F2156495: CMakeCache.txt 

Repository:
  rL LLVM

http://reviews.llvm.org/D21599

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

Re: [PATCH] D22196: Fix Bug "28480 - cppcoreguidelines-pro-bounds-array-to-pointer-decay handling __PRETTY_FUNCTION__"

2016-07-12 Thread Eric Lemanissier via cfe-commits

ericLemanissier abandoned this revision.
ericLemanissier added a comment.

Well, C++ Core Guidelines advises in this case to correct function receiving 
__PRETTY_FUNCTION__: the parameter type should not be const char* ( 
https://github.com/isocpp/CppCoreGuidelines/issues/640 )
I'm not sure if it should be cstring_span, czstring_span, or czstring.
In case it is not possible to change this function, I guess the only solution 
is static_cast(__PRETTY_FUNCTION)


http://reviews.llvm.org/D22196



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

Re: [PATCH] D21599: [Libcxx][MIPS] Use LLVM CheckAtomic.cmake module to figure out whether we need to link with libatomic.

2016-07-12 Thread Nitesh Jain via cfe-commits

nitesh.jain added a comment.

In http://reviews.llvm.org/D21599#481588, @dsanders wrote:

> Have you tried a standalone build? I suspect HAVE_CXX_LIBATOMICS64 will never 
> be set for that case. If that's the case, adding 'include(CheckAtomic)' will 
> probably fix it.

I never tried a standalone build. Please can you shared standalone build steps 
(I can't find any doc's for that) ?

Thanks

Repository:
  rL LLVM

http://reviews.llvm.org/D21599

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

Re: [PATCH] D21968: [libcxx] Externally threaded libc++ variant - Take 2

2016-07-12 Thread Asiri Rathnayake via cfe-commits

rmaprath updated this revision to Diff 63670.
rmaprath added a comment.

Minor cleanup + Ping.


http://reviews.llvm.org/D21968

Files:
  CMakeLists.txt
  include/__config
  include/__config_site.in
  include/__threading_support
  lib/CMakeLists.txt
  test/CMakeLists.txt
  test/libcxx/test/config.py
  
test/libcxx/thread/thread.condition/thread.condition.condvar/native_handle.pass.cpp
  
test/libcxx/thread/thread.mutex/thread.mutex.requirements/thread.mutex.requirements.mutex/thread.mutex.class/native_handle.pass.cpp
  
test/libcxx/thread/thread.mutex/thread.mutex.requirements/thread.mutex.requirements.mutex/thread.mutex.recursive/native_handle.pass.cpp
  
test/libcxx/thread/thread.threads/thread.thread.class/thread.thread.member/native_handle.pass.cpp
  test/libcxx/thread/thread.threads/thread.thread.class/types.pass.cpp
  test/lit.site.cfg.in
  test/support/external_threads.cpp

Index: test/support/external_threads.cpp
===
--- /dev/null
+++ test/support/external_threads.cpp
@@ -0,0 +1,172 @@
+//===--===//
+//
+// 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.
+//
+//===--===//
+#ifndef SUPPORT_EXTERNAL_THREADS
+#define SUPPORT_EXTERNAL_THREADS
+
+#include <__threading_support>
+#include 
+#include 
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+//-- Mutex --//
+
+int __libcpp_recursive_mutex_init(__libcpp_mutex_t* __m)
+{
+// Initialize the allocated pthread_mutex_t object as a recursive mutex
+pthread_mutexattr_t attr;
+int __ec = pthread_mutexattr_init(&attr);
+if (__ec)
+  goto fail;
+
+__ec = pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
+if (__ec)
+{
+pthread_mutexattr_destroy(&attr);
+goto fail;
+}
+
+__ec = pthread_mutex_init(__m, &attr);
+if (__ec)
+{
+pthread_mutexattr_destroy(&attr);
+goto fail;
+}
+
+__ec = pthread_mutexattr_destroy(&attr);
+if (__ec)
+{
+pthread_mutex_destroy(__m);
+goto fail;
+}
+
+return 0;
+
+fail:
+return __ec;
+}
+
+int __libcpp_mutex_lock(__libcpp_mutex_t* __m)
+{
+return pthread_mutex_lock(__m);
+}
+
+int __libcpp_mutex_trylock(__libcpp_mutex_t* __m)
+{
+return pthread_mutex_trylock(__m);
+}
+
+int __libcpp_mutex_unlock(__libcpp_mutex_t* __m)
+{
+return pthread_mutex_unlock(__m);
+}
+
+int __libcpp_mutex_destroy(__libcpp_mutex_t* __m) {
+return pthread_mutex_destroy(__m);
+}
+
+//-- Condition variable --//
+
+int __libcpp_condvar_signal(__libcpp_condvar_t* __cv)
+{
+return pthread_cond_signal(__cv);
+}
+
+int __libcpp_condvar_broadcast(__libcpp_condvar_t* __cv)
+{
+return pthread_cond_broadcast(__cv);
+}
+
+int __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m)
+{
+return pthread_cond_wait(__cv, __m);
+}
+
+int __libcpp_condvar_timedwait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m, timespec* __ts)
+{
+return pthread_cond_timedwait(__cv, __m, __ts);
+}
+
+int __libcpp_condvar_destroy(__libcpp_condvar_t* __cv)
+{
+return pthread_cond_destroy(__cv);
+}
+
+//-- Thread --//
+
+bool __libcpp_thread_id_equal(__libcpp_thread_id t1, __libcpp_thread_id t2) {
+return pthread_equal(t1, t2) != 0;
+}
+
+bool __libcpp_thread_id_less(__libcpp_thread_id t1, __libcpp_thread_id t2) {
+return t1 < t2;
+}
+
+int __libcpp_thread_create(__libcpp_thread_t* __t, void* (*__func)(void*), void* __arg)
+{
+return pthread_create(__t, 0, __func, __arg);
+}
+
+__libcpp_thread_id __libcpp_thread_get_current_id()
+{
+return static_cast<__libcpp_thread_id>(pthread_self());
+}
+
+__libcpp_thread_id __libcpp_thread_get_id(const __libcpp_thread_t* __t)
+{
+return *__t;
+}
+
+int __libcpp_thread_join(__libcpp_thread_t* __t)
+{
+// Must return non-zero if the internal state has already been invalidated
+// This can happen for example, if std::thread::join() has been called
+// before.
+if (*__t == 0)
+return -1;
+
+return pthread_join(*__t, 0);
+}
+
+int __libcpp_thread_detach(__libcpp_thread_t* __t)
+{
+// Must return non-zero if the internal state has already been invalidated
+// This can happen for example, if std::thread::detach() has been called
+// before.
+if (*__t == 0)
+return -1;
+
+return pthread_detach(*__t);
+}
+
+void __libcpp_thread_yield()
+{
+sched_yield();
+}
+
+//-- TLS --//
+
+int __libcpp_tl_create(__libcpp_tl_key* __key, void (*__at_exit)(void*))
+{
+return pthread_key_create(__key, __at_exit);
+}
+
+void* __libcpp_tl_get(__libcpp_tl_key __key)
+{
+return pthread_getspecific(__key);
+}
+
+void __libcpp_tl_set(__libcpp_tl_key __key, void* __p)
+{
+pthread_setspecific(__key, __p);
+}

r275169 - [Clang][AVX512] Making cosmetic changes

2016-07-12 Thread Michael Zuckerman via cfe-commits

Author: mzuckerm
Date: Tue Jul 12 07:42:27 2016
New Revision: 275169

URL: http://llvm.org/viewvc/llvm-project?rev=275169&view=rev
Log:
[Clang][AVX512] Making cosmetic changes

Modified:
cfe/trunk/lib/Headers/avx512vbmiintrin.h

Modified: cfe/trunk/lib/Headers/avx512vbmiintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512vbmiintrin.h?rev=275169&r1=275168&r2=275169&view=diff
==
--- cfe/trunk/lib/Headers/avx512vbmiintrin.h (original)
+++ cfe/trunk/lib/Headers/avx512vbmiintrin.h Tue Jul 12 07:42:27 2016
@@ -40,8 +40,7 @@ _mm512_mask2_permutex2var_epi8 (__m512i
   (__v64qi) __I
   /* idx */ ,
   (__v64qi) __B,
-  (__mmask64)
-  __U);
+  (__mmask64) __U);
 }
 
 static __inline__ __m512i __DEFAULT_FN_ATTRS
@@ -51,8 +50,7 @@ _mm512_permutex2var_epi8 (__m512i __A, _
   /* idx */ ,
   (__v64qi) __A,
   (__v64qi) __B,
-  (__mmask64) -
-  1);
+  (__mmask64) -1);
 }
 
 static __inline__ __m512i __DEFAULT_FN_ATTRS
@@ -63,8 +61,7 @@ _mm512_mask_permutex2var_epi8 (__m512i _
   /* idx */ ,
   (__v64qi) __A,
   (__v64qi) __B,
-  (__mmask64)
-  __U);
+  (__mmask64) __U);
 }
 
 static __inline__ __m512i __DEFAULT_FN_ATTRS
@@ -75,8 +72,7 @@ _mm512_maskz_permutex2var_epi8 (__mmask6
/* idx */ ,
(__v64qi) __A,
(__v64qi) __B,
-   (__mmask64)
-   __U);
+   (__mmask64) __U);
 }
 
 static __inline__ __m512i __DEFAULT_FN_ATTRS
@@ -122,8 +118,7 @@ _mm512_maskz_multishift_epi64_epi8 (__mm
 {
   return (__m512i) __builtin_ia32_vpmultishiftqb512_mask ((__v64qi) __X,
 (__v64qi) __Y,
-(__v64qi)
-_mm512_setzero_si512 (),
+(__v64qi) _mm512_setzero_si512 (),
 (__mmask64) __M);
 }
 
@@ -132,8 +127,7 @@ _mm512_multishift_epi64_epi8 (__m512i __
 {
   return (__m512i) __builtin_ia32_vpmultishiftqb512_mask ((__v64qi) __X,
 (__v64qi) __Y,
-(__v64qi)
-_mm512_undefined_epi32 (),
+(__v64qi) _mm512_undefined_epi32 (),
 (__mmask64) -1);
 }
 


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

[PATCH] D22265: [libcxx][filesystem] Remove setgid from parent before testing permissions

2016-07-12 Thread Jonas Hahnfeld via cfe-commits

Hahnfeld created this revision.
Hahnfeld added a reviewer: EricWF.
Hahnfeld added a subscriber: cfe-commits.

man page for mkdir says: `If the parent directory has the set-group-ID bit set, 
then so will the newly created directory.`

http://reviews.llvm.org/D22265

Files:
  
test/std/experimental/filesystem/fs.op.funcs/fs.op.create_directory/create_directory_with_attributes.pass.cpp

Index: 
test/std/experimental/filesystem/fs.op.funcs/fs.op.create_directory/create_directory_with_attributes.pass.cpp
===
--- 
test/std/experimental/filesystem/fs.op.funcs/fs.op.create_directory/create_directory_with_attributes.pass.cpp
+++ 
test/std/experimental/filesystem/fs.op.funcs/fs.op.create_directory/create_directory_with_attributes.pass.cpp
@@ -60,6 +60,9 @@
 TEST_CASE(create_directory_one_level)
 {
 scoped_test_env env;
+// Remove setgid which mkdir would inherit
+permissions(env.test_root, perms::remove_perms | perms::set_gid);
+
 const path dir = env.make_env_path("dir1");
 const path attr_dir = env.create_dir("dir2");
 permissions(attr_dir, perms::none);


Index: test/std/experimental/filesystem/fs.op.funcs/fs.op.create_directory/create_directory_with_attributes.pass.cpp
===
--- test/std/experimental/filesystem/fs.op.funcs/fs.op.create_directory/create_directory_with_attributes.pass.cpp
+++ test/std/experimental/filesystem/fs.op.funcs/fs.op.create_directory/create_directory_with_attributes.pass.cpp
@@ -60,6 +60,9 @@
 TEST_CASE(create_directory_one_level)
 {
 scoped_test_env env;
+// Remove setgid which mkdir would inherit
+permissions(env.test_root, perms::remove_perms | perms::set_gid);
+
 const path dir = env.make_env_path("dir1");
 const path attr_dir = env.create_dir("dir2");
 permissions(attr_dir, perms::none);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r273694 - clang-format: [JS] Fix build breakage.

2016-07-12 Thread Daniel Jasper via cfe-commits

So, turns out top-level conditionals are actually used somewhat frequently.
Can I undo this change? It doesn't break any other tests. Do you have other
tests that I should run against?

On Fri, Jun 24, 2016 at 11:48 PM, Martin Probst  wrote:

> Yes, test breakage. The problem was that with the change fields and
> interfaces would still get incorrectly formatted (see also the comment on
> the diff). Will include it in the commit message next time.
>
>
> Daniel Jasper  schrieb am Fr., 24. Juni 2016 um
> 14:43 Uhr:
>
>> The patch description seems wrong as this doesn't fix a build breakage
>> AFAICT. Do you mean a test failure? If so, it would be helpful to #include
>> what's actually changing (before/after or calling out the failing test case
>> or something).
>>
>>
>> On Fri, Jun 24, 2016 at 7:45 PM, Martin Probst via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: mprobst
>>> Date: Fri Jun 24 12:45:13 2016
>>> New Revision: 273694
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=273694&view=rev
>>> Log:
>>> clang-format: [JS] Fix build breakage.
>>>
>>> Checking Line.MustBeDeclaration does actually break the field and param
>>> initializer use case.
>>>
>>> Modified:
>>> cfe/trunk/lib/Format/TokenAnnotator.cpp
>>> cfe/trunk/unittests/Format/FormatTestJS.cpp
>>>
>>> Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=273694&r1=273693&r2=273694&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
>>> +++ cfe/trunk/lib/Format/TokenAnnotator.cpp Fri Jun 24 12:45:13 2016
>>> @@ -639,7 +639,7 @@ private:
>>>}
>>>// Declarations cannot be conditional expressions, this can only
>>> be part
>>>// of a type declaration.
>>> -  if (Line.MustBeDeclaration && !Contexts.back().IsExpression &&
>>> +  if (!Contexts.back().IsExpression &&
>>>Style.Language == FormatStyle::LK_JavaScript)
>>>  break;
>>>parseConditional();
>>>
>>> Modified: cfe/trunk/unittests/Format/FormatTestJS.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJS.cpp?rev=273694&r1=273693&r2=273694&view=diff
>>>
>>> ==
>>> --- cfe/trunk/unittests/Format/FormatTestJS.cpp (original)
>>> +++ cfe/trunk/unittests/Format/FormatTestJS.cpp Fri Jun 24 12:45:13 2016
>>> @@ -1351,7 +1351,7 @@ TEST_F(FormatTestJS, NonNullAssertionOpe
>>>
>>>  TEST_F(FormatTestJS, Conditional) {
>>>verifyFormat("y = x ? 1 : 2;");
>>> -  verifyFormat("x ? 1 : 2;");
>>> +  verifyFormat("x ? 1: 2;"); // Known issue with top level conditionals.
>>>verifyFormat("class Foo {\n"
>>> "  field = true ? 1 : 2;\n"
>>> "  method(a = true ? 1 : 2) {}\n"
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r273694 - clang-format: [JS] Fix build breakage.

2016-07-12 Thread Martin Probst via cfe-commits

What do you mean by other tests? On my machine, reverting this change
breaks one of the tests in FormatTestJS.Conditional.

Martin

Daniel Jasper  schrieb am Di., 12. Juli 2016 um
06:03 Uhr:

> So, turns out top-level conditionals are actually used somewhat
> frequently. Can I undo this change? It doesn't break any other tests. Do
> you have other tests that I should run against?
>
> On Fri, Jun 24, 2016 at 11:48 PM, Martin Probst  wrote:
>
>> Yes, test breakage. The problem was that with the change fields and
>> interfaces would still get incorrectly formatted (see also the comment on
>> the diff). Will include it in the commit message next time.
>>
>>
>> Daniel Jasper  schrieb am Fr., 24. Juni 2016 um
>> 14:43 Uhr:
>>
>>> The patch description seems wrong as this doesn't fix a build breakage
>>> AFAICT. Do you mean a test failure? If so, it would be helpful to #include
>>> what's actually changing (before/after or calling out the failing test case
>>> or something).
>>>
>>>
>>> On Fri, Jun 24, 2016 at 7:45 PM, Martin Probst via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: mprobst
 Date: Fri Jun 24 12:45:13 2016
 New Revision: 273694

 URL: http://llvm.org/viewvc/llvm-project?rev=273694&view=rev
 Log:
 clang-format: [JS] Fix build breakage.

 Checking Line.MustBeDeclaration does actually break the field and param
 initializer use case.

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

 Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=273694&r1=273693&r2=273694&view=diff

 ==
 --- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
 +++ cfe/trunk/lib/Format/TokenAnnotator.cpp Fri Jun 24 12:45:13 2016
 @@ -639,7 +639,7 @@ private:
}
// Declarations cannot be conditional expressions, this can only
 be part
// of a type declaration.
 -  if (Line.MustBeDeclaration && !Contexts.back().IsExpression &&
 +  if (!Contexts.back().IsExpression &&
Style.Language == FormatStyle::LK_JavaScript)
  break;
parseConditional();

 Modified: cfe/trunk/unittests/Format/FormatTestJS.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJS.cpp?rev=273694&r1=273693&r2=273694&view=diff

 ==
 --- cfe/trunk/unittests/Format/FormatTestJS.cpp (original)
 +++ cfe/trunk/unittests/Format/FormatTestJS.cpp Fri Jun 24 12:45:13 2016
 @@ -1351,7 +1351,7 @@ TEST_F(FormatTestJS, NonNullAssertionOpe

  TEST_F(FormatTestJS, Conditional) {
verifyFormat("y = x ? 1 : 2;");
 -  verifyFormat("x ? 1 : 2;");
 +  verifyFormat("x ? 1: 2;"); // Known issue with top level
 conditionals.
verifyFormat("class Foo {\n"
 "  field = true ? 1 : 2;\n"
 "  method(a = true ? 1 : 2) {}\n"


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

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

[libcxx] r275170 - Mark P0067 as 'postponed', because it will be revised before the next meeting

2016-07-12 Thread Marshall Clow via cfe-commits

Author: marshall
Date: Tue Jul 12 09:37:39 2016
New Revision: 275170

URL: http://llvm.org/viewvc/llvm-project?rev=275170&view=rev
Log:
Mark P0067 as 'postponed', because it will be revised before the next meeting

Modified:
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=275170&r1=275169&r2=275170&view=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Tue Jul 12 09:37:39 2016
@@ -97,7 +97,7 @@
http://wg21.link/p0032r3";>p0032r3LWGHomogeneous 
interface for variant, any and optionalOulu
http://wg21.link/p0040r3";>p0040r3LWGExtending 
memory management toolsOulu
http://wg21.link/p0063r3";>p0063r3LWGC++17 should 
refer to C11 instead of C99Oulu
-   http://wg21.link/p0067r3";>p0067r3LWGElementary 
string conversionsOulu
+   http://wg21.link/p0067r3";>p0067r3LWGElementary 
string conversionsOuluPostponed to Issaquah
http://wg21.link/p0083r3";>p0083r3LWGSplicing Maps 
and SetsOulu
http://wg21.link/p0084r2";>p0084r2LWGEmplace Return 
TypeOulu
http://wg21.link/p0088r3";>p0088r3LWGVariant: a 
type-safe union for C++17Oulu
@@ -317,7 +317,7 @@
 
   
 
-  Last Updated: 30-Jun-2016
+  Last Updated: 12-Jul-2016
 
 
 


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

[libcxx] r275172 - Add option to disable __deallocate #warning

2016-07-12 Thread Saleem Abdulrasool via cfe-commits

Author: compnerd
Date: Tue Jul 12 09:39:13 2016
New Revision: 275172

URL: http://llvm.org/viewvc/llvm-project?rev=275172&view=rev
Log:
Add option to disable __deallocate #warning

From r229162:
  Visual Studio's SAL extension uses a macro named __deallocate. This
  macro is used pervasively
Using -Werror when building for Windows can force the use of -Wno-#warnings
specifically because of this __deallocate #warning. Instead of forcing
builds to disable all #warnings, this option allows libc++ to be built
without this particular warning, while leaving other #warnings enabled.

Patch by Dave Lee!

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/include/__undef___deallocate
libcxx/trunk/include/__undef_min_max

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=275172&r1=275171&r2=275172&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Jul 12 09:39:13 2016
@@ -135,6 +135,7 @@ option(LIBCXX_HAS_PTHREAD_API "Ignore au
 # about #include_next which is used everywhere.
 option(LIBCXX_ENABLE_PEDANTIC "Compile with pedantic enabled." OFF)
 option(LIBCXX_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
+option(LIBCXX_DISABLE_MACRO_CONFLICT_WARNINGS "Disable #warnings about 
conflicting macros." OFF)
 
 option(LIBCXX_GENERATE_COVERAGE "Enable generating code coverage." OFF)
 set(LIBCXX_COVERAGE_LIBRARY "" CACHE STRING
@@ -323,6 +324,9 @@ endif()
 if (LIBCXX_ENABLE_PEDANTIC)
   add_compile_flags_if_supported(-pedantic)
 endif()
+if (LIBCXX_DISABLE_MACRO_CONFLICT_WARNINGS)
+  add_definitions(-D_LIBCPP_DISABLE_MACRO_CONFLICT_WARNINGS)
+endif()
 
 # Exception flags =
 if (LIBCXX_ENABLE_EXCEPTIONS)

Modified: libcxx/trunk/include/__undef___deallocate
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__undef___deallocate?rev=275172&r1=275171&r2=275172&view=diff
==
--- libcxx/trunk/include/__undef___deallocate (original)
+++ libcxx/trunk/include/__undef___deallocate Tue Jul 12 09:39:13 2016
@@ -9,10 +9,12 @@
 
//===--===//
 
 #ifdef __deallocate
+#if !defined(_LIBCPP_DISABLE_MACRO_CONFLICT_WARNINGS)
 #if defined(_MSC_VER) && !defined(__clang__)
 _LIBCPP_WARNING("macro __deallocate is incompatible with C++.  #undefining 
__deallocate")
 #else
 #warning: macro __deallocate is incompatible with C++.  #undefining 
__deallocate
 #endif
+#endif
 #undef __deallocate
 #endif

Modified: libcxx/trunk/include/__undef_min_max
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__undef_min_max?rev=275172&r1=275171&r2=275172&view=diff
==
--- libcxx/trunk/include/__undef_min_max (original)
+++ libcxx/trunk/include/__undef_min_max Tue Jul 12 09:39:13 2016
@@ -9,21 +9,25 @@
 
//===--===//
 
 #ifdef min
+#if !defined(_LIBCPP_DISABLE_MACRO_CONFLICT_WARNINGS)
 #if defined(_MSC_VER) && ! defined(__clang__)
 _LIBCPP_WARNING("macro min is incompatible with C++.  Try #define NOMINMAX "
 "before any Windows header. #undefing min")
 #else
 #warning: macro min is incompatible with C++.  #undefing min
 #endif
+#endif
 #undef min
 #endif
 
 #ifdef max
+#if !defined(_LIBCPP_DISABLE_MACRO_CONFLICT_WARNINGS)
 #if defined(_MSC_VER) && ! defined(__clang__)
 _LIBCPP_WARNING("macro max is incompatible with C++.  Try #define NOMINMAX "
 "before any Windows header. #undefing max")
 #else
 #warning: macro max is incompatible with C++.  #undefing max
 #endif
+#endif
 #undef max
 #endif


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

[libcxx] r275171 - Put the status in the right column

2016-07-12 Thread Marshall Clow via cfe-commits

Author: marshall
Date: Tue Jul 12 09:38:59 2016
New Revision: 275171

URL: http://llvm.org/viewvc/llvm-project?rev=275171&view=rev
Log:
Put the status in the right column

Modified:
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=275171&r1=275170&r2=275171&view=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Tue Jul 12 09:38:59 2016
@@ -97,7 +97,7 @@
http://wg21.link/p0032r3";>p0032r3LWGHomogeneous 
interface for variant, any and optionalOulu
http://wg21.link/p0040r3";>p0040r3LWGExtending 
memory management toolsOulu
http://wg21.link/p0063r3";>p0063r3LWGC++17 should 
refer to C11 instead of C99Oulu
-   http://wg21.link/p0067r3";>p0067r3LWGElementary 
string conversionsOuluPostponed to Issaquah
+   http://wg21.link/p0067r3";>p0067r3LWGElementary 
string conversionsOuluPostponed to Issaquah
http://wg21.link/p0083r3";>p0083r3LWGSplicing Maps 
and SetsOulu
http://wg21.link/p0084r2";>p0084r2LWGEmplace Return 
TypeOulu
http://wg21.link/p0088r3";>p0088r3LWGVariant: a 
type-safe union for C++17Oulu


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

Re: [PATCH] D22254: [ARM, AArch64] Adds builtins to get current SP and PC

2016-07-12 Thread Tim Northover via cfe-commits

t.p.northover added a comment.

I agree with Renato too.

It seems like, as a compiler, we can provide virtually no guarantees about the 
value of `__builtin_arm_current_pc`: it's not necessarily in the PC-range of 
the dynamically innermost frame (inlining); it's not necessarily even in the 
callstack at all (you actually get PC+8 or PC+4).

About the only feasible use-case is a some kind of panic/abort implementation 
best-effort. And at that point you'll want r0-r14 as well.

Tim.


http://reviews.llvm.org/D22254



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

Re: [PATCH] D21070: Pass the ABI in the triple when appropriate (currently for MIPS) for 'clang -cc1' and 'clang -cc1as'

2016-07-12 Thread Daniel Sanders via cfe-commits

dsanders updated this revision to Diff 63676.
dsanders added a comment.

Updated to match latest version of http://reviews.llvm.org/D21467.

At this point Mips is in the X86/everyone-else camp but there's a loose end to
tie up in LLVM in order to prove it. Once LLVM rejects non-empty ABIName's
for Mips, we have proven we're in the X86/everyone-else camp and can start
uniting the Mips/X86/everyone-else camp with the ARM/PowerPC camp.


http://reviews.llvm.org/D21070

Files:
  lib/Basic/Targets.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  tools/driver/cc1as_main.cpp

Index: tools/driver/cc1as_main.cpp
===
--- tools/driver/cc1as_main.cpp
+++ tools/driver/cc1as_main.cpp
@@ -69,6 +69,10 @@
   /// The name of the target triple to assemble for.
   std::string Triple;
 
+  /// The name of the ABI to assembler for or the empty string for the default
+  /// ABI.
+  std::string ABI;
+
   /// If given, the name of the target CPU to determine which instructions
   /// are legal.
   std::string CPU;
@@ -134,6 +138,7 @@
 public:
   AssemblerInvocation() {
 Triple = "";
+ABI = "";
 NoInitialTextSection = 0;
 InputFile = "-";
 OutputPath = "-";
@@ -185,13 +190,24 @@
 
   // Target Options
   Opts.Triple = llvm::Triple::normalize(Args.getLastArgValue(OPT_triple));
+  Opts.ABI = Args.getLastArgValue(OPT_target_abi);
   Opts.CPU = Args.getLastArgValue(OPT_target_cpu);
   Opts.Features = Args.getAllArgValues(OPT_target_feature);
 
   // Use the default target triple if unspecified.
   if (Opts.Triple.empty())
 Opts.Triple = llvm::sys::getDefaultTargetTriple();
 
+  // Modify the Triple and ABI according to the Triple and ABI.
+  llvm::Triple ABITriple;
+  StringRef ABIName;
+  std::tie(ABITriple, ABIName) =
+  llvm::Triple(Opts.Triple).getABIVariant(Opts.ABI);
+  if (ABITriple.getArch() == llvm::Triple::UnknownArch)
+Diags.Report(diag::err_target_unknown_abi) << Opts.ABI;
+  Opts.Triple = ABITriple.str();
+  Opts.ABI = ABIName;
+
   // Language Options
   Opts.IncludePaths = Args.getAllArgValues(OPT_I);
   Opts.NoInitialTextSection = Args.hasArg(OPT_n);
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2301,6 +2301,16 @@
   // Use the default target triple if unspecified.
   if (Opts.Triple.empty())
 Opts.Triple = llvm::sys::getDefaultTargetTriple();
+
+  // Modify the Triple and ABI according to the Triple and ABI.
+  llvm::Triple ABITriple;
+  StringRef ABIName;
+  std::tie(ABITriple, ABIName) =
+  llvm::Triple(Opts.Triple).getABIVariant(Opts.ABI);
+  if (ABITriple.getArch() == llvm::Triple::UnknownArch)
+Diags.Report(diag::err_target_unknown_abi) << Opts.ABI;
+  Opts.Triple = ABITriple.str();
+  Opts.ABI = ABIName;
 }
 
 bool CompilerInvocation::CreateFromArgs(CompilerInvocation &Res,
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -1202,7 +1202,7 @@
   // MIPS32r6 is the default for mips(el)?-img-linux-gnu and MIPS64r6 is the
   // default for mips64(el)?-img-linux-gnu.
   if (Triple.getVendor() == llvm::Triple::ImaginationTechnologies &&
-  Triple.getEnvironment() == llvm::Triple::GNU) {
+  Triple.isGNUEnvironment()) {
 DefMips32CPU = "mips32r6";
 DefMips64CPU = "mips64r6";
   }
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -2344,7 +2344,7 @@
 
   if (TargetTriple.getVendor() == llvm::Triple::ImaginationTechnologies &&
   TargetTriple.getOS() == llvm::Triple::Linux &&
-  TargetTriple.getEnvironment() == llvm::Triple::GNU)
+  TargetTriple.isGNUEnvironment())
 return findMipsImgMultilibs(Flags, NonExistent, Result);
 
   if (findMipsCsMultilibs(Flags, NonExistent, Result))
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -7134,10 +7134,22 @@
 BigEndian = getTriple().getArch() == llvm::Triple::mips ||
 getTriple().getArch() == llvm::Triple::mips64;
 
-setABI((getTriple().getArch() == llvm::Triple::mips ||
-getTriple().getArch() == llvm::Triple::mipsel)
-   ? "o32"
-   : "n64");
+if (getTriple().getEnvironment() == llvm::Triple::ABI32 ||
+getTriple().getEnvironment() == llvm::Triple::GNUABI32 ||
+getTriple().getEnvironment() == llvm::Triple::AndroidABI32)
+  setABI("o32");
+else if (getTriple().getEnvironment() == llvm::Triple::ABIN32 ||
+getTriple().getEnvironment() == llvm::Triple::GNUABIN32)
+  setABI("n32");
+else if (getTriple().getEnvironment() == llvm::Triple::ABI64 ||
+

Re: [PATCH] D18171: [CUDA][OpenMP] Create generic offload action

2016-07-12 Thread Samuel Antao via cfe-commits

sfantao updated this revision to Diff 63680.
sfantao added a comment.

- Rebase.
- Remove static function no longer necessary.


http://reviews.llvm.org/D18171

Files:
  include/clang/Driver/Action.h
  include/clang/Driver/Compilation.h
  include/clang/Driver/Driver.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  lib/Frontend/CreateInvocationFromCommandLine.cpp

Index: lib/Frontend/CreateInvocationFromCommandLine.cpp
===
--- lib/Frontend/CreateInvocationFromCommandLine.cpp
+++ lib/Frontend/CreateInvocationFromCommandLine.cpp
@@ -60,25 +60,25 @@
   }
 
   // We expect to get back exactly one command job, if we didn't something
-  // failed. CUDA compilation is an exception as it creates multiple jobs. If
-  // that's the case, we proceed with the first job. If caller needs particular
-  // CUDA job, it should be controlled via --cuda-{host|device}-only option
-  // passed to the driver.
+  // failed. Offload compilation is an exception as it creates multiple jobs. If
+  // that's the case, we proceed with the first job. If caller needs a
+  // particular job, it should be controlled via options (e.g.
+  // --cuda-{host|device}-only for CUDA) passed to the driver.
   const driver::JobList &Jobs = C->getJobs();
-  bool CudaCompilation = false;
+  bool OffloadCompilation = false;
   if (Jobs.size() > 1) {
 for (auto &A : C->getActions()){
   // On MacOSX real actions may end up being wrapped in BindArchAction
   if (isa(A))
 A = *A->input_begin();
-  if (isa(A)) {
-CudaCompilation = true;
+  if (isa(A)) {
+OffloadCompilation = true;
 break;
   }
 }
   }
   if (Jobs.size() == 0 || !isa(*Jobs.begin()) ||
-  (Jobs.size() > 1 && !CudaCompilation)) {
+  (Jobs.size() > 1 && !OffloadCompilation)) {
 SmallString<256> Msg;
 llvm::raw_svector_ostream OS(Msg);
 Jobs.Print(OS, "; ", true);
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -57,8 +57,7 @@
const Driver &D, const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs,
const InputInfo &Output,
-   const InputInfoList &Inputs,
-   const ToolChain *AuxToolChain) const;
+   const InputInfoList &Inputs) const;
 
   void AddAArch64TargetArgs(const llvm::opt::ArgList &Args,
 llvm::opt::ArgStringList &CmdArgs) const;
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -296,12 +296,45 @@
  !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 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.
+}
+
 void Clang::AddPreprocessingOptions(Compilation &C, const JobAction &JA,
 const Driver &D, const ArgList &Args,
 ArgStringList &CmdArgs,
 const InputInfo &Output,
-const InputInfoList &Inputs,
-const ToolChain *AuxToolChain) const {
+const InputInfoList &Inputs) const {
   Arg *A;
   const bool IsIAMCU

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

2016-07-12 Thread Samuel Antao via cfe-commits

sfantao updated this revision to Diff 63681.
sfantao added a comment.

- Rebase.


http://reviews.llvm.org/D18172

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

Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -1388,132 +1388,524 @@
   }
 }
 
-// For each unique --cuda-gpu-arch= argument creates a TY_CUDA_DEVICE
-// input action and then wraps each in CudaDeviceAction paired with
-// appropriate GPU arch name. In case of partial (i.e preprocessing
-// only) or device-only compilation, each device action is added to /p
-// Actions and /p Current is released. Otherwise the function creates
-// and returns a new CudaHostAction which wraps /p Current and device
-// side actions.
-static Action *buildCudaActions(Compilation &C, DerivedArgList &Args,
-const Arg *InputArg, Action *HostAction,
-ActionList &Actions) {
-  Arg *PartialCompilationArg = Args.getLastArg(
-  options::OPT_cuda_host_only, options::OPT_cuda_device_only,
-  options::OPT_cuda_compile_host_device);
-  bool CompileHostOnly =
-  PartialCompilationArg &&
-  PartialCompilationArg->getOption().matches(options::OPT_cuda_host_only);
-  bool CompileDeviceOnly =
-  PartialCompilationArg &&
-  PartialCompilationArg->getOption().matches(options::OPT_cuda_device_only);
-
-  if (CompileHostOnly) {
+namespace {
+/// Provides a convenient interface for different programming models to generate
+/// the required device actions.
+class OffloadingActionBuilder final {
+  /// Flag used to trace errors in the builder.
+  bool IsValid = false;
+
+  /// The compilation that is using this builder.
+  Compilation &C;
+
+  /// The derived arguments associated with this builder.
+  DerivedArgList &Args;
+
+  /// Map between an input argument and the offload kinds used to process it.
+  std::map InputArgToOffloadKindMap;
+
+  /// Builder interface. It doesn't build anything or keep any state.
+  class DeviceActionBuilder {
+  public:
+typedef llvm::SmallVector PhasesTy;
+
+enum ActionBuilderReturnCode {
+  // The builder acted successfully on the current action.
+  ABRT_Success,
+  // The builder didn't have to act on the current action.
+  ABRT_Inactive,
+  // The builder was successful and requested the host action to not be
+  // generated.
+  ABRT_Ignore_Host,
+};
+
+  protected:
+/// Compilation associated with this builder.
+Compilation &C;
+
+/// Tool chains associated with this builder. The same programming
+/// model may have associated one or more tool chains.
+SmallVector ToolChains;
+
+/// The derived arguments associated with this builder.
+DerivedArgList &Args;
+
+/// The inputs associated with this builder.
+const Driver::InputList &Inputs;
+
+/// The associated offload kind.
+Action::OffloadKind AssociatedOffloadKind = Action::OFK_None;
+
+  public:
+DeviceActionBuilder(Compilation &C, DerivedArgList &Args,
+const Driver::InputList &Inputs,
+Action::OffloadKind AssociatedOffloadKind)
+: C(C), Args(Args), Inputs(Inputs),
+  AssociatedOffloadKind(AssociatedOffloadKind) {}
+virtual ~DeviceActionBuilder() {}
+
+/// Fill up the array \a DA with all the device dependences that should be
+/// added to the provided host action \a HostAction. By default it is
+/// inactive.
+virtual ActionBuilderReturnCode
+getDeviceDepences(OffloadAction::DeviceDependences &DA, phases::ID CurPhase,
+  phases::ID FinalPhase, PhasesTy &Phases) {
+  return ABRT_Inactive;
+}
+
+/// Update the state to include the provided host action \a HostAction as a
+/// dependency of the current device action. By default it is inactive.
+virtual ActionBuilderReturnCode addDeviceDepences(Action *HostAction) {
+  return ABRT_Inactive;
+}
+
+/// Append top level actions generated by the builder. Return true if errors
+/// were found.
+virtual void appendTopLevelActions(ActionList &AL) {}
+
+/// Append linker actions generated by the builder. Return true if errors
+/// were found.
+virtual void appendLinkDependences(OffloadAction::DeviceDependences &DA) {}
+
+/// Initialize the builder. Return true if any initialization errors are
+/// found.
+virtual bool initialize() { return false; }
+
+/// Return true if this builder is valid. We have a valid builder if we have
+/// associated device tool chains.
+bool isValid() { return !ToolChains.empty(); }
+
+/// Return the associated offload kind.
+Action::OffloadKind getAssociatedOffloadKind() {
+  return AssociatedOffloadKind;
+}
+  };
+
+  /// \brief CUDA action builder. It injects device code in the host backend
+  /// action.
+  class CudaActionBuilder final :

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

2016-07-12 Thread Samuel Antao via cfe-commits

sfantao updated this revision to Diff 63682.
sfantao added a comment.

- Rebase.


http://reviews.llvm.org/D21840

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

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

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

2016-07-12 Thread Samuel Antao via cfe-commits

sfantao updated this revision to Diff 63683.
sfantao added a comment.

- Rebase.


http://reviews.llvm.org/D21843

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

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

Re: [PATCH] D18171: [CUDA][OpenMP] Create generic offload action

2016-07-12 Thread Samuel Antao via cfe-commits

sfantao added a comment.

@tra, any more comments about this patch?

Thanks!
Samuel


http://reviews.llvm.org/D18171



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

[libcxx] r275176 - mark issue #2181 as complete; this was just a wording clarification

2016-07-12 Thread Marshall Clow via cfe-commits

Author: marshall
Date: Tue Jul 12 10:15:55 2016
New Revision: 275176

URL: http://llvm.org/viewvc/llvm-project?rev=275176&view=rev
Log:
mark issue #2181 as complete; this was just a wording clarification

Modified:
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=275176&r1=275175&r2=275176&view=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Tue Jul 12 10:15:55 2016
@@ -260,7 +260,7 @@
http://wg21.link/LWG2586";>2586Wrong value 
category used in 
scoped_allocator_adaptor::construct()Jacksonville
http://wg21.link/LWG2590";>2590Aggregate 
initialization for 
std::arrayJacksonvilleComplete

-   http://wg21.link/LWG2181";>2181Exceptions 
from seed sequence operationsOulu
+   http://wg21.link/LWG2181";>2181Exceptions 
from seed sequence operationsOuluComplete
http://wg21.link/LWG2309";>2309mutex::lock() should not throw 
device_or_resource_busyOuluComplete
http://wg21.link/LWG2310";>2310Public 
exposition only member in std::arrayOuluComplete
http://wg21.link/LWG2312";>2312tuple's 
constructor constraints need to be phrased more 
preciselyOuluComplete


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

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

2016-07-12 Thread John McCall via cfe-commits

rjmccall added inline comments.


Comment at: lib/CodeGen/CodeGenFunction.h:2725
@@ -2724,3 +2724,3 @@
   void EmitStoreOfScalar(llvm::Value *Value, Address Addr,
- bool Volatile, QualType Ty,
+ bool Volatile, bool Restrict, QualType Ty,
  AlignmentSource AlignSource = AlignmentSource::Type,

majnemer wrote:
> Multiple bool parameters aren't super great. Could we make it an enum and `|` 
> the two properties as needed?  If it's super painful, this could be done 
> later.
Alternatively, is there a reason that the qualifiers on Ty aren't sufficient 
for this?  If we're passing down the access type anyway, I'm not sure why we 
need to be separately passing Volatile.


http://reviews.llvm.org/D22189



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

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

2016-07-12 Thread Samuel Antao via cfe-commits

sfantao updated this revision to Diff 63684.
sfantao added a comment.

- Rebase.


http://reviews.llvm.org/D21845

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

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

[libcxx] r275177 - mark issue #2422 as complete; this was just a wording clarification

2016-07-12 Thread Marshall Clow via cfe-commits

Author: marshall
Date: Tue Jul 12 10:29:35 2016
New Revision: 275177

URL: http://llvm.org/viewvc/llvm-project?rev=275177&view=rev
Log:
mark issue #2422 as complete; this was just a wording clarification

Modified:
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=275177&r1=275176&r2=275177&view=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Tue Jul 12 10:29:35 2016
@@ -266,7 +266,7 @@
http://wg21.link/LWG2312";>2312tuple's 
constructor constraints need to be phrased more 
preciselyOuluComplete
http://wg21.link/LWG2328";>2328Rvalue 
stream extraction should use perfect forwardingOulu
http://wg21.link/LWG2393";>2393std::function's Callable 
definition is brokenOulu
-   http://wg21.link/LWG2422";>2422std::numeric_limits::is_modulo
 description: "most machines" errataOulu
+   http://wg21.link/LWG2422";>2422std::numeric_limits::is_modulo
 description: "most machines" errataOuluComplete
http://wg21.link/LWG2426";>2426Issue about 
compare_exchangeOulu
http://wg21.link/LWG2436";>2436Comparators 
for associative containers should always be 
CopyConstructibleOuluComplete
http://wg21.link/LWG2441";>2441Exact-width 
atomic typedefs should be providedOuluComplete


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

Re: [PATCH] D22170: [OpenCL] Fixes opencl.cl testcase issues and cl-strict-aliasing only allowed with cl-std=CL

2016-07-12 Thread Anastasia Stulova via cfe-commits

Anastasia added inline comments.


Comment at: test/Frontend/opencl-blocks.cl:9
@@ -8,1 +8,3 @@
 // RUN: %clang_cc1 %s -triple amdgcn--amdhsa -x c -std=c99 -verify 
-fsyntax-only
+// RUN: %clang_cc1 -cl-std=CL1.1 -cl-strict-aliasing %s 2>&1 | FileCheck 
--check-prefix=CHECK-INVALID-OPENCL-VERSION11 %s
+// RUN: %clang_cc1 -cl-std=CL1.2 -cl-strict-aliasing %s 2>&1 | FileCheck 
--check-prefix=CHECK-INVALID-OPENCL-VERSION12 %s

yaxunl wrote:
> ashi1 wrote:
> > yaxunl wrote:
> > > Anastasia wrote:
> > > > yaxunl wrote:
> > > > > Better separate these tests to another file, e.g. 
> > > > > cl-strict-aliasing.cl
> > > > I think it was right to have this in test/Driver/opencl.cl. Why was it 
> > > > moved in here?
> > > This is a frontend option and the warning is emitted by frontend, not the 
> > > driver. The driver does not consume the option. It just passes it to the 
> > > frontend.
> > > 
> > > The driver test is mostly testing whether the option is correctly passed 
> > > to the compiler invocation by using -###.
> > should it be called opencl-strict-aliasing.cl or cl-strict-aliasing.cl
> either is OK.
I would rather see fewer small test files populated and more compact/less 
fragmented testing. Is there any reason not put this with blocks and give it 
more generic name, let's say opencl.cl.


Repository:
  rL LLVM

http://reviews.llvm.org/D22170



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

r275183 - clang-format: [JS] Allow top-level conditionals again.

2016-07-12 Thread Daniel Jasper via cfe-commits

Author: djasper
Date: Tue Jul 12 10:45:53 2016
New Revision: 275183

URL: http://llvm.org/viewvc/llvm-project?rev=275183&view=rev
Log:
clang-format: [JS] Allow top-level conditionals again.

I am not sure exactly which test breakage Martin was trying to fix in
r273694. For now, fix the behavior for top-level conditionals, which
(surprisingly) are actually used somewhat commonly.

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

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=275183&r1=275182&r2=275183&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Tue Jul 12 10:45:53 2016
@@ -639,7 +639,7 @@ private:
   }
   // Declarations cannot be conditional expressions, this can only be part
   // of a type declaration.
-  if (!Contexts.back().IsExpression &&
+  if (Line.MustBeDeclaration && !Contexts.back().IsExpression &&
   Style.Language == FormatStyle::LK_JavaScript)
 break;
   parseConditional();

Modified: cfe/trunk/unittests/Format/FormatTestJS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJS.cpp?rev=275183&r1=275182&r2=275183&view=diff
==
--- cfe/trunk/unittests/Format/FormatTestJS.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp Tue Jul 12 10:45:53 2016
@@ -1351,7 +1351,7 @@ TEST_F(FormatTestJS, NonNullAssertionOpe
 
 TEST_F(FormatTestJS, Conditional) {
   verifyFormat("y = x ? 1 : 2;");
-  verifyFormat("x ? 1: 2;"); // Known issue with top level conditionals.
+  verifyFormat("x ? 1 : 2;");
   verifyFormat("class Foo {\n"
"  field = true ? 1 : 2;\n"
"  method(a = true ? 1 : 2) {}\n"


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

[libcxx] r275184 - Add tests for the meta.unary.props that do not require a complete type. This is part of LWG#2582

2016-07-12 Thread Marshall Clow via cfe-commits

Author: marshall
Date: Tue Jul 12 10:50:53 2016
New Revision: 275184

URL: http://llvm.org/viewvc/llvm-project?rev=275184&view=rev
Log:
Add tests for the meta.unary.props that do not require a complete type. This is 
part of LWG#2582

Modified:

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_const.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_signed.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_unsigned.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_volatile.pass.cpp

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_const.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_const.pass.cpp?rev=275184&r1=275183&r2=275184&view=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_const.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_const.pass.cpp
 Tue Jul 12 10:50:53 2016
@@ -29,6 +29,8 @@ void test_is_const()
 #endif
 }
 
+struct A; // incomplete
+
 int main()
 {
 test_is_const();
@@ -39,6 +41,8 @@ int main()
 test_is_const();
 test_is_const();
 
+test_is_const();
+
 static_assert(!std::is_const::value, "");
 static_assert(!std::is_const::value, "");
 }

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_signed.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_signed.pass.cpp?rev=275184&r1=275183&r2=275184&view=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_signed.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_signed.pass.cpp
 Tue Jul 12 10:50:53 2016
@@ -50,6 +50,8 @@ public:
 ~Class();
 };
 
+struct A; // incomplete
+
 int main()
 {
 test_is_not_signed();
@@ -61,6 +63,7 @@ int main()
 test_is_not_signed();
 test_is_not_signed();
 test_is_not_signed();
+test_is_not_signed();
 
 test_is_signed();
 test_is_signed();

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_unsigned.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_unsigned.pass.cpp?rev=275184&r1=275183&r2=275184&view=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_unsigned.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_unsigned.pass.cpp
 Tue Jul 12 10:50:53 2016
@@ -50,6 +50,8 @@ public:
 ~Class();
 };
 
+struct A; // incomplete
+
 int main()
 {
 test_is_not_unsigned();
@@ -61,6 +63,7 @@ int main()
 test_is_not_unsigned();
 test_is_not_unsigned();
 test_is_not_unsigned();
+test_is_not_unsigned();
 
 test_is_unsigned();
 test_is_unsigned();

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_volatile.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_volatile.pass.cpp?rev=275184&r1=275183&r2=275184&view=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_volatile.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_volatile.pass.cpp
 Tue Jul 12 10:50:53 2016
@@ -29,6 +29,8 @@ void test_is_volatile()
 #endif
 }
 
+struct A; // incomplete
+
 int main()
 {
 test_is_volatile();
@@ -39,6 +41,8 @@ int main()
 test_is_volatile();
 test_is_volatile();
 
+test_is_volatile();
+
 static_assert(!std::is_volatile::value, "");
 static_assert(!std::is_volatile::value, "");
 }


___
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

2016-07-12 Thread Anastasia Stulova via cfe-commits

Anastasia added inline comments.


Comment at: lib/CodeGen/CGOpenCLRuntime.cpp:83
@@ +82,3 @@
+SamplerTy = llvm::PointerType::get(llvm::StructType::create(
+  CGM.getLLVMContext(), "__sampler"),
+  CGM.getContext().getTargetAddressSpace(

I am wondering if we could at least name it __opencl_sampler_t. I kind of don't 
like that we have inconsistency with the rest here.

Btw, the types in Debug are all named opencl_. Perhaps we could correct 
them consistently across?


Comment at: lib/CodeGen/CodeGenModule.cpp:4309
@@ +4308,3 @@
+  // in SPIR spec v1.2 and also opencl-c.h
+  unsigned AddressingMode  = (0x0E & SamplerValue) >> 1;
+  unsigned FilterMode  = (0x30 & SamplerValue) >> 4;

Yes sounds good!


Comment at: lib/Sema/SemaInit.cpp:6907
@@ -6906,3 +6907,1 @@
 case SK_OCLSamplerInit: {
-  assert(Step->Type->isSamplerT() && 
- "Sampler initialization on non-sampler type.");

But I am guessing that holds for most of the assertions. :)


Comment at: lib/Sema/SemaInit.cpp:6915
@@ -6915,3 +6914,3 @@
 << SourceType;
-  } else if (Entity.getKind() != InitializedEntity::EK_Variable) {
-llvm_unreachable("Invalid EntityKind!");
+} else if (const DeclRefExpr *DRE = dyn_cast(Init)) {
+  Init = const_cast(cast(DRE->getDecl())->getInit());

Should you also check for type of Expr to be sampler? 

Btw is this covered in testing?


Comment at: test/CodeGenOpenCL/sampler.cl:1
@@ +1,2 @@
+// RUN: %clang_cc1 %s -emit-llvm -triple spir-unknown-unknown -o - -O0 
-Wspir-compat -verify -DCHECK_SAMPLER_VALUE | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -triple spir-unknown-unknown -o - -O0 -verify 
| FileCheck %s

I think we can give this warning for spir target or -Wspir-compat.


Comment at: test/CodeGenOpenCL/sampler.cl:17
@@ +16,3 @@
+#ifdef CHECK_SAMPLER_VALUE
+// expected-warning@-2{{sampler initializer has invalid Filter Mode bits}}
+#endif

This should go into SemaOpenCL tests!


Comment at: test/CodeGenOpenCL/sampler.cl:27
@@ +26,3 @@
+
+void fnc4smp(sampler_t s) {}
+// CHECK: define spir_func void @fnc4smp(%__sampler addrspace(2)* %

Could we add CHECK-NOT respectively?


Comment at: test/CodeGenOpenCL/sampler.cl:37
@@ +36,3 @@
+
+  fnc4smp(smp);
+  // CHECK: [[SAMP:%[0-9]+]] = call %__sampler addrspace(2)* 
@__translate_sampler_initializer(i32 19)

Can we add another call with smp and check that 
__translate_sampler_initializeris is not called again?


http://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] D21904: [OpenMP] Initial implementation of parse+sema for clause use_device_ptr of 'target data'

2016-07-12 Thread Carlo Bertolli via cfe-commits

carlo.bertolli marked 3 inline comments as done.


Comment at: lib/Sema/SemaOpenMP.cpp:11648
@@ +11647,3 @@
+// item should be a pointer or reference to pointer
+if (!Type.getNonReferenceType()->isPointerType()) {
+  Diag(ELoc, diag::err_omp_usedeviceptr_not_a_pointer)

ABataev wrote:
> What if Type is dependent?
In that case at line 8084 (function getPrivateItem) will return the pair 
(nullptr, true) and at line 11640 I will push nullptr for later analysis.
If this is not enough, can you please explain what needs to be done? Thanks!!


Repository:
  rL LLVM

http://reviews.llvm.org/D21904



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

Re: [PATCH] D21904: [OpenMP] Initial implementation of parse+sema for clause use_device_ptr of 'target data'

2016-07-12 Thread Carlo Bertolli via cfe-commits

carlo.bertolli updated this revision to Diff 63689.
carlo.bertolli added a comment.

[OpenMP] Add regression test to check correctness of ast building, remove 
'brief's, and rebase.


Repository:
  rL LLVM

http://reviews.llvm.org/D21904

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  test/OpenMP/target_data_use_device_ptr_ast_print.cpp
  test/OpenMP/target_data_use_device_ptr_messages.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -2275,6 +2275,9 @@
 void OMPClauseEnqueue::VisitOMPFromClause(const OMPFromClause *C) {
   VisitOMPClauseList(C);
 }
+void OMPClauseEnqueue::VisitOMPUseDevicePtrClause(const OMPUseDevicePtrClause *C) {
+  VisitOMPClauseList(C);
+}
 }
 
 void EnqueueVisitor::EnqueueChildren(const OMPClause *S) {
Index: test/OpenMP/target_data_use_device_ptr_messages.cpp
===
--- /dev/null
+++ test/OpenMP/target_data_use_device_ptr_messages.cpp
@@ -0,0 +1,206 @@
+// RUN: %clang_cc1 -std=c++11 -verify -fopenmp -ferror-limit 200 %s
+struct ST {
+  int *a;
+};
+struct SA {
+  const int d = 5;
+  const int da[5] = { 0 };
+  ST e;
+  ST g[10];
+  int i;
+  int &j = i;
+  int *k = &j;
+  int *&z = k;
+  int aa[10];
+  void func(int arg) {
+#pragma omp target data map(i) use_device_ptr // expected-error {{expected '(' after 'use_device_ptr'}}
+{}
+#pragma omp target data map(i) use_device_ptr( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}}
+{}
+#pragma omp target data map(i) use_device_ptr() // expected-error {{expected expression}}
+{}
+#pragma omp target data map(i) use_device_ptr(alloc) // expected-error {{use of undeclared identifier 'alloc'}}
+{}
+#pragma omp target data map(i) use_device_ptr(arg // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected pointer or reference to pointer in 'use_device_ptr' clause}}
+{}
+#pragma omp target data map(i) use_device_ptr(i) // expected-error {{expected pointer or reference to pointer in 'use_device_ptr' clause}}
+{}
+#pragma omp target data map(i) use_device_ptr(j) // expected-error {{expected pointer or reference to pointer in 'use_device_ptr' clause}}
+{}
+#pragma omp target data map(i) use_device_ptr(k) // OK
+{}
+#pragma omp target data map(i) use_device_ptr(z) // OK
+{}
+#pragma omp target data map(i) use_device_ptr(aa) // expected-error{{expected pointer or reference to pointer in 'use_device_ptr' clause}}
+{}
+#pragma omp target data map(i) use_device_ptr(e) // expected-error{{expected pointer or reference to pointer in 'use_device_ptr' clause}}
+{}
+#pragma omp target data map(i) use_device_ptr(g) // expected-error{{expected pointer or reference to pointer in 'use_device_ptr' clause}}
+{}
+#pragma omp target data map(i) use_device_ptr(k,i,j) // expected-error2 {{expected pointer or reference to pointer in 'use_device_ptr' clause}}
+{}
+#pragma omp target data map(i) use_device_ptr(d) // expected-error{{expected pointer or reference to pointer in 'use_device_ptr' clause}}
+{}
+#pragma omp target data map(i) use_device_ptr(da) // expected-error{{expected pointer or reference to pointer in 'use_device_ptr' clause}}
+{}
+  return;
+ }
+};
+struct SB {
+  unsigned A;
+  unsigned B;
+  float Arr[100];
+  float *Ptr;
+  float *foo() {
+return &Arr[0];
+  }
+};
+
+struct SC {
+  unsigned A : 2;
+  unsigned B : 3;
+  unsigned C;
+  unsigned D;
+  float Arr[100];
+  SB S;
+  SB ArrS[100];
+  SB *PtrS;
+  SB *&RPtrS;
+  float *Ptr;
+
+  SC(SB *&_RPtrS) : RPtrS(_RPtrS) {}
+};
+
+union SD {
+  unsigned A;
+  float B;
+};
+
+struct S1;
+extern S1 a;
+class S2 {
+  mutable int a;
+public:
+  S2():a(0) { }
+  S2(S2 &s2):a(s2.a) { }
+  static float S2s;
+  static const float S2sc;
+};
+const float S2::S2sc = 0;
+const S2 b;
+const S2 ba[5];
+class S3 {
+  int a;
+public:
+  S3():a(0) { }
+  S3(S3 &s3):a(s3.a) { }
+};
+const S3 c;
+const S3 ca[5];
+extern const int f;
+class S4 {
+  int a;
+  S4();
+  S4(const S4 &s4);
+public:
+  S4(int v):a(v) { }
+};
+class S5 {
+  int a;
+  S5():a(0) {}
+  S5(const S5 &s5):a(s5.a) { }
+public:
+  S5(int v):a(v) { }
+};
+
+S3 h;
+#pragma omp threadprivate(h)
+
+typedef int from;
+
+template 
+T tmain(T argc) {
+  const T d = 5;
+  const T da[5] = { 0 };
+  S4 e(4);
+  S5 g(5);
+  T i;
+  T &j = i;
+  T *k = &j;
+  T *&z =

Re: [PATCH] D22242: [analyzer] De-duplicate some code for discovering the origin of the symbol.

2016-07-12 Thread Artem Dergachev via cfe-commits

NoQ updated this revision to Diff 63688.
NoQ marked an inline comment as done.
NoQ added a comment.

Added a doxygen comment, made the function virtual instead of branching.


http://reviews.llvm.org/D22242

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h
  include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h
  lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp
  lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp

Index: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
+++ lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
@@ -2833,23 +2833,15 @@
   C.addTransition(State);
 }
 
-static bool wasLoadedFromIvar(SymbolRef Sym) {
-  if (auto DerivedVal = dyn_cast(Sym))
-return isa(DerivedVal->getRegion());
-  if (auto RegionVal = dyn_cast(Sym))
-return isa(RegionVal->getRegion());
-  return false;
-}
-
 void RetainCountChecker::checkPostStmt(const ObjCIvarRefExpr *IRE,
CheckerContext &C) const {
   Optional IVarLoc = C.getSVal(IRE).getAs();
   if (!IVarLoc)
 return;
 
   ProgramStateRef State = C.getState();
   SymbolRef Sym = State->getSVal(*IVarLoc).getAsSymbol();
-  if (!Sym || !wasLoadedFromIvar(Sym))
+  if (!Sym || !dyn_cast_or_null(Sym->getOriginRegion()))
 return;
 
   // Accessing an ivar directly is unusual. If we've done that, be more
Index: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp
===
--- lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp
+++ lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp
@@ -315,15 +315,7 @@
 /// Returns nullptr if the instance symbol cannot be found.
 const ObjCIvarRegion *
 ObjCDeallocChecker::getIvarRegionForIvarSymbol(SymbolRef IvarSym) const {
-  const MemRegion *RegionLoadedFrom = nullptr;
-  if (auto *DerivedSym = dyn_cast(IvarSym))
-RegionLoadedFrom = DerivedSym->getRegion();
-  else if (auto *RegionSym = dyn_cast(IvarSym))
-RegionLoadedFrom = RegionSym->getRegion();
-  else
-return nullptr;
-
-  return dyn_cast(RegionLoadedFrom);
+  return dyn_cast_or_null(IvarSym->getOriginRegion());
 }
 
 /// Given a symbol for an ivar, return a symbol for the instance containing
Index: include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h
===
--- include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h
+++ include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h
@@ -58,6 +58,7 @@
   }
 
   void dumpToStream(raw_ostream &os) const override;
+  const MemRegion *getOriginRegion() const override { return getRegion(); }
 
   QualType getType() const override;
 
@@ -127,6 +128,7 @@
   QualType getType() const override;
 
   void dumpToStream(raw_ostream &os) const override;
+  const MemRegion *getOriginRegion() const override { return getRegion(); }
 
   static void Profile(llvm::FoldingSetNodeID& profile, SymbolRef parent,
   const TypedValueRegion *r) {
Index: include/clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h
===
--- include/clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h
+++ include/clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h
@@ -22,6 +22,8 @@
 namespace clang {
 namespace ento {
 
+class MemRegion;
+
 /// \brief Symbolic value. These values used to capture symbolic execution of
 /// the program.
 class SymExpr : public llvm::FoldingSetNode {
@@ -76,6 +78,18 @@
   static symbol_iterator symbol_end() { return symbol_iterator(); }
 
   unsigned computeComplexity() const;
+
+  /// \brief Find the region from which this symbol originates.
+  ///
+  /// Whenever the symbol was constructed to denote an unknown value of
+  /// a certain memory region, return this region. This method
+  /// allows checkers to make decisions depending on the origin of the symbol.
+  /// Symbol classes for which the origin region is known include
+  /// SymbolRegionValue which denotes the value of the region before
+  /// the beginning of the analysis, and SymbolDerived which denotes the value
+  /// of a certain memory region after its super region (a memory space or
+  /// a larger record region) is default-bound with a certain symbol.
+  virtual const MemRegion *getOriginRegion() const { return nullptr; }
 };
 
 typedef const SymExpr *SymbolRef;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D21989: [OpenCL] Improve diagnostics of OpenCL types

2016-07-12 Thread Anastasia Stulova via cfe-commits

Anastasia added a comment.

Wondering if we should add similar restrictions for other OpenCL types incl 
events or queues?

Also I am guessing that the following

  pipe int (*p)

should be parsed as pointer to pipe and not a pointer to a pipe element type 
(by analogy to function pointers or other similar declarations).

This isn't legal code I believe but the diagnostic currently doesn't seem right:

  error: pipes packet types cannot be of reference type


http://reviews.llvm.org/D21989



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

r275190 - [ItaniumMangle] Correctly mangle BuiltinTemplateDecls

2016-07-12 Thread David Majnemer via cfe-commits

Author: majnemer
Date: Tue Jul 12 11:48:17 2016
New Revision: 275190

URL: http://llvm.org/viewvc/llvm-project?rev=275190&view=rev
Log:
[ItaniumMangle] Correctly mangle BuiltinTemplateDecls

A BuiltinTemplateDecl has no underlying templated decl and as such they
cannot be relied upon for mangling.  The ItaniumMangler had some bugs
here which lead to crashes.

This fixes PR28519.

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

Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=275190&r1=275189&r2=275190&view=diff
==
--- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)
+++ cfe/trunk/lib/AST/ItaniumMangle.cpp Tue Jul 12 11:48:17 2016
@@ -910,6 +910,8 @@ void CXXNameMangler::mangleUnscopedTempl
 assert(!AdditionalAbiTags &&
"template template param cannot have abi tags");
 mangleTemplateParameter(TTP->getIndex());
+  } else if (isa(ND)) {
+mangleUnscopedName(ND, AdditionalAbiTags);
   } else {
 mangleUnscopedName(ND->getTemplatedDecl(), AdditionalAbiTags);
   }
@@ -1715,7 +1717,10 @@ void CXXNameMangler::mangleTemplatePrefi
 mangleTemplateParameter(TTP->getIndex());
   } else {
 manglePrefix(getEffectiveDeclContext(ND), NoFunction);
-mangleUnqualifiedName(ND->getTemplatedDecl(), nullptr);
+if (isa(ND))
+  mangleUnqualifiedName(ND, nullptr);
+else
+  mangleUnqualifiedName(ND->getTemplatedDecl(), nullptr);
   }
 
   addSubstitution(ND);

Modified: cfe/trunk/test/CodeGenCXX/mangle-template.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/mangle-template.cpp?rev=275190&r1=275189&r2=275190&view=diff
==
--- cfe/trunk/test/CodeGenCXX/mangle-template.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/mangle-template.cpp Tue Jul 12 11:48:17 2016
@@ -201,3 +201,14 @@ namespace test14 {
 
   int call(bool b) { return inl(b); }
 }
+
+namespace std {
+template  struct integer_sequence {};
+}
+
+namespace test15 {
+template 
+__make_integer_seq make() {}
+template __make_integer_seq make<5>();
+// CHECK: define weak_odr void 
@_ZN6test154makeILi5EEE18__make_integer_seqISt16integer_sequenceiXT_EEv(
+}


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

Re: [PATCH] D21989: [OpenCL] Improve diagnostics of OpenCL types

2016-07-12 Thread Anastasia Stulova via cfe-commits

Anastasia closed this revision.
Anastasia added a comment.

r275061


http://reviews.llvm.org/D21989



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

Re: [PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation

2016-07-12 Thread David Li via cfe-commits

davidxl added a comment.

Please also update user manual: docs/UserManual.rst



Comment at: test/Driver/clang_f_opts.c:90
@@ -89,3 +89,2 @@
 // RUN: %clang -### -S -fprofile-instr-generate=file 
-fno-profile-instr-generate %s 2>&1 | FileCheck -check-prefix=CHECK-DISABLE-GEN 
%s
-// RUN: %clang -### -S -fprofile-instr-generate=file -fno-profile-generate %s 
2>&1 | FileCheck -check-prefix=CHECK-DISABLE-GEN %s
 // RUN: %clang -### -S -fprofile-generate=dir -fno-profile-generate %s 2>&1 | 
FileCheck -check-prefix=CHECK-DISABLE-GEN %s

Probably change this test into the check of disallowed option combination : 
-fprofile-instr-generate -fprofile-generate


Comment at: test/Profile/gcc-flag-compatibility.c:10
@@ -9,3 +9,3 @@
 
-// Check that -fprofile-generate uses the runtime default profile file.
+// Check that -fprofile-generate overrides the default profraw.
 // RUN: %clang %s -c -S -o - -emit-llvm -fprofile-generate | FileCheck 
-check-prefix=PROFILE-GEN %s

Please add a FIXME here. I noticed that there is a bug in IR PGO implementation 
that -fprofile-generate still invokes overrider api in instrumentation which is 
unnecessary.


Repository:
  rL LLVM

http://reviews.llvm.org/D21823



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

Re: [PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation

2016-07-12 Thread David Li via cfe-commits

davidxl added inline comments.


Comment at: lib/Driver/Tools.cpp:3596
@@ -3576,3 +3595,3 @@
Args.hasFlag(options::OPT_fprofile_generate,
-options::OPT_fno_profile_instr_generate, false) ||
+options::OPT_fno_profile_generate, false) ||
Args.hasFlag(options::OPT_fprofile_generate_EQ,

This should probably split out as a follow up.


Repository:
  rL LLVM

http://reviews.llvm.org/D21823



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

r275191 - Fix for the mingw builder

2016-07-12 Thread David Majnemer via cfe-commits

Author: majnemer
Date: Tue Jul 12 11:56:33 2016
New Revision: 275191

URL: http://llvm.org/viewvc/llvm-project?rev=275191&view=rev
Log:
Fix for the mingw builder

Modified:
cfe/trunk/test/CodeGenCXX/mangle-template.cpp

Modified: cfe/trunk/test/CodeGenCXX/mangle-template.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/mangle-template.cpp?rev=275191&r1=275190&r2=275191&view=diff
==
--- cfe/trunk/test/CodeGenCXX/mangle-template.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/mangle-template.cpp Tue Jul 12 11:56:33 2016
@@ -210,5 +210,5 @@ namespace test15 {
 template 
 __make_integer_seq make() {}
 template __make_integer_seq make<5>();
-// CHECK: define weak_odr void 
@_ZN6test154makeILi5EEE18__make_integer_seqISt16integer_sequenceiXT_EEv(
+// CHECK: define weak_odr {{.*}} 
@_ZN6test154makeILi5EEE18__make_integer_seqISt16integer_sequenceiXT_EEv(
 }


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

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

2016-07-12 Thread Anastasia Stulova via cfe-commits

Anastasia closed this revision.
Anastasia added a comment.

r262641


http://reviews.llvm.org/D17345



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

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

2016-07-12 Thread Anastasia Stulova via cfe-commits

Anastasia closed this revision.
Anastasia added a comment.

r262616


http://reviews.llvm.org/D16928



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

Re: [PATCH] D15293: [OpenCL] Correct NULL constant handling after applying default AS

2016-07-12 Thread Anastasia Stulova via cfe-commits

Anastasia closed this revision.
Anastasia added a comment.

r255346


http://reviews.llvm.org/D15293



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

Re: [PATCH] D13168: [OpenCL] OpenCL2.0 - Apply default address space rules

2016-07-12 Thread Anastasia Stulova via cfe-commits

Anastasia closed this revision.
Anastasia added a comment.

r253863


http://reviews.llvm.org/D13168



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

Re: [PATCH] D13105: [OpenCL] Enable program scope variables for OpenCL2.0

2016-07-12 Thread Anastasia Stulova via cfe-commits

Anastasia closed this revision.
Anastasia added a comment.

r248906 and r250892


http://reviews.llvm.org/D13105



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

Re: [PATCH] D17343: [OpenCL] Diagnose program scope pointers

2016-07-12 Thread Anastasia Stulova via cfe-commits

Anastasia abandoned this revision.
Anastasia added a comment.

After clarifying with Khronos, it doesn't seem like this is needed indeed!


http://reviews.llvm.org/D17343



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

Re: [PATCH] D20249: [OpenCL] Hierarchical/dynamic parallelism - enqueue kernel in OpenCL 2.0

2016-07-12 Thread Anastasia Stulova via cfe-commits

Anastasia closed this revision.
Anastasia added a comment.

r274540 and r274509


http://reviews.llvm.org/D20249



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

Re: [PATCH] D18171: [CUDA][OpenMP] Create generic offload action

2016-07-12 Thread Artem Belevich via cfe-commits

tra added a comment.

Few minor nits and suggestions. Other than that I'm OK with the patch.



Comment at: lib/Driver/Action.cpp:156
@@ +155,3 @@
+  // Propagate info to the dependencies.
+  for (unsigned i = 0; i < getInputs().size(); ++i)
+getInputs()[i]->propagateDeviceOffloadInfo(OKinds[i], BArchs[i]);

Minor style nit -- [[ 
http://llvm.org/docs/CodingStandards.html#don-t-evaluate-end-every-time-through-a-loop
 | LLVM coding standard says ]] :

> ... we strongly prefer loops to be written so that they evaluate it once 
> before the loop starts.

`for (unsigned i = 0, e = getInputs().size(); i != e; ++i)`

Please check other for loops throughout the patch.


Comment at: lib/Driver/Action.cpp:172-179
@@ +171,10 @@
+  for (unsigned i = 0; i < DDeps.getActions().size(); ++i) {
+auto *A = DDeps.getActions()[i];
+// Skip actions of empty dependences.
+if (!A)
+  continue;
+getInputs().push_back(A);
+A->propagateDeviceOffloadInfo(DDeps.getOffloadKinds()[i],
+  DDeps.getBoundArchs()[i]);
+  }
+}

It could be rephrased as "do work if we have dependencies" and make code a bit 
more concise.

```
if (auto *A = DDeps.getActions()[i]) {
   getInputs().push_back(A);
   A-> propagate...
}
```


Comment at: lib/Driver/Action.cpp:185
@@ +184,3 @@
+return;
+  auto *A = getInputs().front();
+  Work(A, HostTC, A->getOffloadingArch());

Please add assert to verify that getInputs() is not empty.
It may be worth doing throughout the patch as there are several places where we 
indexing into getInputs() result without verifying its size. It's not at all 
obvious from the code that it's always OK to do so.


Comment at: lib/Driver/Action.cpp:191-202
@@ +190,14 @@
+const OffloadActionWorkTy &Work) const {
+  auto I = getInputs().begin();
+  auto E = getInputs().end();
+  if (I == E)
+return;
+
+  // Skip host action
+  if (HostTC)
+++I;
+
+  auto TI = DevToolChains.begin();
+  for (; I != E; ++I, ++TI)
+Work(*I, *TI, (*I)->getOffloadingArch());
+}

You may want to add an assert that I and TI are both valid within the loop.


http://reviews.llvm.org/D18171



___
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

2016-07-12 Thread Piotr Padlewski via cfe-commits

Prazek added inline comments.


Comment at: clang-tidy/modernize/UseEmplaceCheck.cpp:129
@@ -95,1 +128,3 @@
+  auto CtorCallSourceRange = CharSourceRange::getTokenRange(
+  InnerCtorCall->getExprLoc(), CallParensRange.getBegin());
 

There is a bug here that I forgot about. Should be InnerCtorCall->getStartLoc()


Repository:
  rL LLVM

http://reviews.llvm.org/D22208



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

r275195 - AArch64: fix return type of vqmovun_high_*.

2016-07-12 Thread Tim Northover via cfe-commits

Author: tnorthover
Date: Tue Jul 12 12:38:50 2016
New Revision: 275195

URL: http://llvm.org/viewvc/llvm-project?rev=275195&view=rev
Log:
AArch64: fix return type of vqmovun_high_*.

These should be returning an unsigned quantity.

Added:
cfe/trunk/test/Sema/arm64-neon-header.c
Modified:
cfe/trunk/include/clang/Basic/arm_neon.td

Modified: cfe/trunk/include/clang/Basic/arm_neon.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/arm_neon.td?rev=275195&r1=275194&r2=275195&view=diff
==
--- cfe/trunk/include/clang/Basic/arm_neon.td (original)
+++ cfe/trunk/include/clang/Basic/arm_neon.td Tue Jul 12 12:38:50 2016
@@ -967,7 +967,7 @@ def XTN2 : SOpInst<"vmovn_high", "qhk",
 
 

 // Signed integer saturating extract and unsigned narrow to high
-def SQXTUN2 : SOpInst<"vqmovun_high", "qhk", "sil", OP_SQXTUN>;
+def SQXTUN2 : SOpInst<"vqmovun_high", "emd", "HsHiHl", OP_SQXTUN>;
 
 

 // Integer saturating extract and narrow to high

Added: cfe/trunk/test/Sema/arm64-neon-header.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/arm64-neon-header.c?rev=275195&view=auto
==
--- cfe/trunk/test/Sema/arm64-neon-header.c (added)
+++ cfe/trunk/test/Sema/arm64-neon-header.c Tue Jul 12 12:38:50 2016
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -triple arm64-apple-darwin -target-feature +neon 
-Wvector-conversion -fsyntax-only -ffreestanding -verify %s
+
+#include 
+
+int16x8_t foo(int8x8_t p0, int16x8_t p1) {
+  return vqmovun_high_s16(p0, p1); // expected-warning {{incompatible vector 
types returning 'uint8x16_t'}}
+}


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

[PATCH] D22270: [ASTImporter] Properly report the locations of anonymous structs declared as part of named fields

2016-07-12 Thread Sean Callanan via cfe-commits

spyffe created this revision.
spyffe added a reviewer: manmanren.
spyffe added a subscriber: cfe-commits.
spyffe set the repository for this revision to rL LLVM.

When importing classes and structs with anonymous structs, it is critical that 
distinct anonymous structs remain distinct despite having similar layout.
This is already ensured by distinguishing based on their placement in the 
parent struct, using the function `findAnonymousStructOrUnionIndex`.
The problem is that this function only handles 
```
class Foo { struct { int a; } }
```
and not
```
class Foo { struct { int a; } var; }
```
Both need to be handled, and this patch fixes that.  The test case ensures that 
this functionality doesn't regress.

Repository:
  rL LLVM

http://reviews.llvm.org/D22270

Files:
  lib/AST/ASTImporter.cpp
  test/ASTMerge/Inputs/anonymous-fields1.cpp
  test/ASTMerge/Inputs/anonymous-fields2.cpp
  test/ASTMerge/anonymous-fields.cpp

Index: test/ASTMerge/anonymous-fields.cpp
===
--- /dev/null
+++ test/ASTMerge/anonymous-fields.cpp
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -emit-pch -o %t.1.ast %S/Inputs/anonymous-fields1.cpp
+// RUN: %clang_cc1 -emit-pch -o %t.2.ast %S/Inputs/anonymous-fields2.cpp
+// RUN: %clang_cc1 -emit-obj -o /dev/null -ast-merge %t.1.ast -ast-merge 
%t.2.ast %s
+// expected-no-diagnostics
Index: test/ASTMerge/Inputs/anonymous-fields2.cpp
===
--- /dev/null
+++ test/ASTMerge/Inputs/anonymous-fields2.cpp
@@ -0,0 +1,9 @@
+class A {
+public:
+  struct { int foo; } f;
+  struct { int foo; } g;
+};
+
+inline int useA(A &a) {
+  return (a.f.foo + a.g.foo);
+}
Index: test/ASTMerge/Inputs/anonymous-fields1.cpp
===
--- /dev/null
+++ test/ASTMerge/Inputs/anonymous-fields1.cpp
@@ -0,0 +1,5 @@
+class A {
+public:
+  struct { int foo; } f;
+  struct { int foo; } g;
+};
Index: lib/AST/ASTImporter.cpp
===
--- lib/AST/ASTImporter.cpp
+++ lib/AST/ASTImporter.cpp
@@ -1040,11 +1040,27 @@
   unsigned Index = 0;
   for (const auto *D : Owner->noload_decls()) {
 const auto *F = dyn_cast(D);
-if (!F || !F->isAnonymousStructOrUnion())
+if (!F)
   continue;
-
-if (Context.hasSameType(F->getType(), AnonTy))
-  break;
+  
+if (F->isAnonymousStructOrUnion()) {
+  if (Context.hasSameType(F->getType(), AnonTy)) {
+break;
+  }
+} else {
+  // If the field looks like this:
+  // struct { ... } A;
+  QualType FieldType = F->getType();
+  if (const RecordType *RecType = dyn_cast(FieldType)) {
+const RecordDecl *RecDecl = RecType->getDecl();
+if (RecDecl->getDeclContext() == Owner &&
+!RecDecl->getIdentifier()) {
+  if (Context.hasSameType(FieldType, AnonTy)) {
+break;
+  }
+}
+  }
+}
 
 ++Index;
   }


Index: test/ASTMerge/anonymous-fields.cpp
===
--- /dev/null
+++ test/ASTMerge/anonymous-fields.cpp
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -emit-pch -o %t.1.ast %S/Inputs/anonymous-fields1.cpp
+// RUN: %clang_cc1 -emit-pch -o %t.2.ast %S/Inputs/anonymous-fields2.cpp
+// RUN: %clang_cc1 -emit-obj -o /dev/null -ast-merge %t.1.ast -ast-merge %t.2.ast %s
+// expected-no-diagnostics
Index: test/ASTMerge/Inputs/anonymous-fields2.cpp
===
--- /dev/null
+++ test/ASTMerge/Inputs/anonymous-fields2.cpp
@@ -0,0 +1,9 @@
+class A {
+public:
+  struct { int foo; } f;
+  struct { int foo; } g;
+};
+
+inline int useA(A &a) {
+  return (a.f.foo + a.g.foo);
+}
Index: test/ASTMerge/Inputs/anonymous-fields1.cpp
===
--- /dev/null
+++ test/ASTMerge/Inputs/anonymous-fields1.cpp
@@ -0,0 +1,5 @@
+class A {
+public:
+  struct { int foo; } f;
+  struct { int foo; } g;
+};
Index: lib/AST/ASTImporter.cpp
===
--- lib/AST/ASTImporter.cpp
+++ lib/AST/ASTImporter.cpp
@@ -1040,11 +1040,27 @@
   unsigned Index = 0;
   for (const auto *D : Owner->noload_decls()) {
 const auto *F = dyn_cast(D);
-if (!F || !F->isAnonymousStructOrUnion())
+if (!F)
   continue;
-
-if (Context.hasSameType(F->getType(), AnonTy))
-  break;
+  
+if (F->isAnonymousStructOrUnion()) {
+  if (Context.hasSameType(F->getType(), AnonTy)) {
+break;
+  }
+} else {
+  // If the field looks like this:
+  // struct { ... } A;
+  QualType FieldType = F->getType();
+  if (const RecordType *RecType = dyn_cast(FieldType)) {
+const RecordDecl *RecDecl = RecType->getDecl();
+if (RecDecl->getDeclContext() == Owner &&
+!RecDecl->getIdentifier()) {
+  if (Context.hasSameType(FieldType, An

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

2016-07-12 Thread Manman Ren via cfe-commits

manmanren added a comment.



> Before this patch, the testcase added used to take

>  5s to compile!!! A bit more elaborate NSDictionary literal with some

> undeclared enums would make the compiler take 22min to run, followed by a 
> crash.


--> this is a big improvement!

A few notes from discussions with Bruno:
This patch changes the base class 
TreeTransform::TransformObjCDictionaryLiteral, which is not specific 
to TransformTypos.

Here we have multiple TypoExprs in a single DictionaryLiteral, and the search 
space for each TypoExpr can be pretty big. That is why it takes a long time to 
go through all the possible corrections.

I applied your patch, looks like it returns an ObjCDictionaryLiteral that 
contains TypoExpr as valid and that is why we break out of the while loop in 
TransformTypos::Transform. That does not look right.

We can probably prune the search space if one of the TypoExprs has zero 
candidate (in the testing case, the 2nd TypoExpr has zero candidate).

Manman


http://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] D22254: [ARM, AArch64] Adds builtins to get current SP and PC

2016-07-12 Thread Mandeep Singh Grang via cfe-commits

mgrang added a comment.

Hi Tim/Renato,

On a similar note, I have a patch which adds the breakpoint intrinsic (for ARM 
and Thumb):
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/CJAHBCFH.html

Could you please let me know if this is something which the community would 
like to support. I can then push my patch.

Here are two other intrinsics which I wanted to implement:
enable_irq: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359124996163.html
disable_irq: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359125001077.html

The use case for these intrinsics is a customer who makes calls to 
__builtin_arm_breakpoint (and others) in their code base. Currently they 
compile with ARMCC, but LLVM does not have these intrinsics. So porting the 
code to build with LLVM becomes a hassle.
To facilitate customers to switch to LLVM we wanted to implement these 
intrinsics.

Thanks,
Mandeep


http://reviews.llvm.org/D22254



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

[PATCH] D22272: ARM: define __ARM_VFPV5__ when present.

2016-07-12 Thread Tim Northover via cfe-commits

t.p.northover created this revision.
t.p.northover added reviewers: rengolin, jmolloy.
t.p.northover added a subscriber: cfe-commits.
Herald added subscribers: mcrosier, rengolin, aemerson.

We've had embedded developers requesting we extend the __ARM_VFPVn__ series to 
support Cortex-M7, which sounds reasonable apart from the name bikeshedding.

The features added are equivalent to a v8 FPU and the LLVM codebase is pretty 
split on whether it's fp-armv8 or vfpv5. Since this is user-facing, I thought 
I'd ask for opinions. The obvious choices are:

  * `__ARM_VFPV5__` everywhere (including Cortex-A57 for example). This matches 
Cortex-M7 naming from ARM, but probably not Cortex-A57. It also matches our 
historical #defines.
  * `__ARM_FPV8__` (or similar) everywhere. Reverse problem from above.
  * Both, depending on whether the CPU really is v8. No naming mismatch, but 
two #defines for what's essentially the same thing. It's difficult to imagine 
code actually wanting to distinguish the two.

I've got a mild preference for the first, hence this patch. Any objections or 
other suggestions?

Tim.

http://reviews.llvm.org/D22272

Files:
  lib/Basic/Targets.cpp
  test/Preprocessor/arm-target-features.c

Index: test/Preprocessor/arm-target-features.c
===
--- test/Preprocessor/arm-target-features.c
+++ test/Preprocessor/arm-target-features.c
@@ -380,6 +380,7 @@
 // M7-THUMB:#define __ARM_ARCH_EXT_IDIV__ 1
 // M7-THUMB:#define __ARM_FEATURE_DSP 1
 // M7-THUMB:#define __ARM_FP 0xE
+// M7-THUMB:#define __ARM_VFPV5__ 1
 
 // Test whether predefines are as expected when targeting krait.
 // RUN: %clang -target armv7 -mcpu=krait -x c -E -dM %s -o - | FileCheck 
-match-full-lines --check-prefix=KRAIT %s
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -5219,6 +5219,8 @@
 Builder.defineMacro("__ARM_VFPV3__");
   if (FPU & VFP4FPU)
 Builder.defineMacro("__ARM_VFPV4__");
+  if (FPU & FPARMV8)
+Builder.defineMacro("__ARM_VFPV5__");
 }
 
 // This only gets set when Neon instructions are actually available, unlike


Index: test/Preprocessor/arm-target-features.c
===
--- test/Preprocessor/arm-target-features.c
+++ test/Preprocessor/arm-target-features.c
@@ -380,6 +380,7 @@
 // M7-THUMB:#define __ARM_ARCH_EXT_IDIV__ 1
 // M7-THUMB:#define __ARM_FEATURE_DSP 1
 // M7-THUMB:#define __ARM_FP 0xE
+// M7-THUMB:#define __ARM_VFPV5__ 1
 
 // Test whether predefines are as expected when targeting krait.
 // RUN: %clang -target armv7 -mcpu=krait -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=KRAIT %s
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -5219,6 +5219,8 @@
 Builder.defineMacro("__ARM_VFPV3__");
   if (FPU & VFP4FPU)
 Builder.defineMacro("__ARM_VFPV4__");
+  if (FPU & FPARMV8)
+Builder.defineMacro("__ARM_VFPV5__");
 }
 
 // This only gets set when Neon instructions are actually available, unlike
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D22273: Treat enumerator_too_large as an extension in MS ABI mode

2016-07-12 Thread Dave Bartolomeo via cfe-commits

DaveBartolomeo created this revision.
DaveBartolomeo added reviewers: rnk, cfe-commits.

When compiling as C targeting the MS ABI, but with -fno-ms-compatibility, an 
enumerator initializer that is not representable as an int is treated as an 
error. This is correct according to the C standard, but Clang already treats it 
as an extension both in -fms-compatibility mode and when compiling as C for 
non-MS ABI targets. It seemed odd that it would be treated as a hard error only 
in this one particular configuration, so I relaxed it to be an extension when 
targeting the MS ABI, regardless of MS compatibility mode.

There are dozens of occurrences of this issue in Windows SDK headers. By 
treating it as an extension, Clang users can include  in a C program 
without having to use -fms-compatibility.


http://reviews.llvm.org/D22273

Files:
  lib/Sema/SemaDecl.cpp

Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -14351,7 +14351,13 @@
   // we perform a non-narrowing conversion as part of converted 
constant
   // expression checking.
   if (!isRepresentableIntegerValue(Context, EnumVal, EltTy)) {
-if (getLangOpts().MSVCCompat) {
+if (getLangOpts().MSVCCompat ||
+Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+  // Treat as an extension in MSVC compat mode or if using the
+  // MSVC ABI. We already treat the equivalent case in C as an
+  // extension if we're not in Microsoft mode. Several Windows
+  // headers define enums with initializers like 0x8000 and
+  // 0x.
   Diag(IdLoc, diag::ext_enumerator_too_large) << EltTy;
   Val = ImpCastExprToType(Val, EltTy, CK_IntegralCast).get();
 } else


Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -14351,7 +14351,13 @@
   // we perform a non-narrowing conversion as part of converted constant
   // expression checking.
   if (!isRepresentableIntegerValue(Context, EnumVal, EltTy)) {
-if (getLangOpts().MSVCCompat) {
+if (getLangOpts().MSVCCompat ||
+Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+  // Treat as an extension in MSVC compat mode or if using the
+  // MSVC ABI. We already treat the equivalent case in C as an
+  // extension if we're not in Microsoft mode. Several Windows
+  // headers define enums with initializers like 0x8000 and
+  // 0x.
   Diag(IdLoc, diag::ext_enumerator_too_large) << EltTy;
   Val = ImpCastExprToType(Val, EltTy, CK_IntegralCast).get();
 } else
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D22275: Support -fno-delayed-template-parsing in clang-cl.exe

2016-07-12 Thread Dave Bartolomeo via cfe-commits

DaveBartolomeo created this revision.
DaveBartolomeo added reviewers: rnk, majnemer, cfe-commits.

This change adds support for the -fno-delayed-template-parsing option in 
clang-cl.exe. This allows developers using clang-cl.exe to opt out of emulation 
of MSVC's non-conformant template instantiation implementation while continuing 
to use clang-cl.exe for its emulation of cl.exe command-line options. The 
default behavior of clang-cl.exe (-fdelayed-template-parsing) is unchanged.

The MSVC Standard Library implementation uses clang-cl.exe with this switch in 
its tests to ensure that the library headers work on compilers with the 
conformant two-phase-lookup behavior.


http://reviews.llvm.org/D22275

Files:
  include/clang/Driver/Options.td

Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -813,7 +813,7 @@
"(default))">;
 def fdelayed_template_parsing : Flag<["-"], "fdelayed-template-parsing">, 
Group,
   HelpText<"Parse templated function definitions at the end of the "
-   "translation unit">,  Flags<[CC1Option]>;
+   "translation unit">,  Flags<[CC1Option, CoreOption]>;
 def fms_memptr_rep_EQ : Joined<["-"], "fms-memptr-rep=">, Group, 
Flags<[CC1Option]>;
 def fmodules_cache_path : Joined<["-"], "fmodules-cache-path=">, 
Group,
   Flags<[DriverOption, CC1Option]>, MetaVarName<"">,
@@ -950,7 +950,7 @@
   Flags<[CoreOption]>;
 def fno_ms_compatibility : Flag<["-"], "fno-ms-compatibility">, Group,
   Flags<[CoreOption]>;
-def fno_delayed_template_parsing : Flag<["-"], 
"fno-delayed-template-parsing">, Group;
+def fno_delayed_template_parsing : Flag<["-"], 
"fno-delayed-template-parsing">, Group, Flags<[CC1Option, CoreOption]>;
 def fno_objc_exceptions: Flag<["-"], "fno-objc-exceptions">, Group;
 def fno_objc_legacy_dispatch : Flag<["-"], "fno-objc-legacy-dispatch">, 
Group;
 def fno_objc_weak : Flag<["-"], "fno-objc-weak">, Group, 
Flags<[CC1Option]>;


Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -813,7 +813,7 @@
"(default))">;
 def fdelayed_template_parsing : Flag<["-"], "fdelayed-template-parsing">, Group,
   HelpText<"Parse templated function definitions at the end of the "
-   "translation unit">,  Flags<[CC1Option]>;
+   "translation unit">,  Flags<[CC1Option, CoreOption]>;
 def fms_memptr_rep_EQ : Joined<["-"], "fms-memptr-rep=">, Group, Flags<[CC1Option]>;
 def fmodules_cache_path : Joined<["-"], "fmodules-cache-path=">, Group,
   Flags<[DriverOption, CC1Option]>, MetaVarName<"">,
@@ -950,7 +950,7 @@
   Flags<[CoreOption]>;
 def fno_ms_compatibility : Flag<["-"], "fno-ms-compatibility">, Group,
   Flags<[CoreOption]>;
-def fno_delayed_template_parsing : Flag<["-"], "fno-delayed-template-parsing">, Group;
+def fno_delayed_template_parsing : Flag<["-"], "fno-delayed-template-parsing">, Group, Flags<[CC1Option, CoreOption]>;
 def fno_objc_exceptions: Flag<["-"], "fno-objc-exceptions">, Group;
 def fno_objc_legacy_dispatch : Flag<["-"], "fno-objc-legacy-dispatch">, Group;
 def fno_objc_weak : Flag<["-"], "fno-objc-weak">, Group, Flags<[CC1Option]>;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22273: Treat enumerator_too_large as an extension in MS ABI mode

2016-07-12 Thread David Majnemer via cfe-commits

majnemer added a subscriber: majnemer.
majnemer requested changes to this revision.
majnemer added a reviewer: majnemer.
majnemer added a comment.
This revision now requires changes to proceed.

This requires an associated test case.



Comment at: lib/Sema/SemaDecl.cpp:14354-14355
@@ -14353,2 +14353,4 @@
   if (!isRepresentableIntegerValue(Context, EnumVal, EltTy)) {
-if (getLangOpts().MSVCCompat) {
+if (getLangOpts().MSVCCompat ||
+Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+  // Treat as an extension in MSVC compat mode or if using the

I would remove the `getLangOpts().MSVCCompat`.


http://reviews.llvm.org/D22273



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

Re: [PATCH] D22273: Treat enumerator_too_large as an extension in MS ABI mode

2016-07-12 Thread Reid Kleckner via cfe-commits

rnk added a comment.

I think this is just a consequence of 
https://llvm.org/bugs/show_bug.cgi?id=27098

We should just fix the underlying bug so that `EnumDecl::isFixed()` doesn't 
return true for plain enums in C or C++ when targeting Windows.


http://reviews.llvm.org/D22273



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

Re: [PATCH] D22170: [OpenCL] Fixes opencl.cl testcase issues and cl-strict-aliasing only allowed with cl-std=CL

2016-07-12 Thread Aaron En Ye Shi via cfe-commits

ashi1 updated this revision to Diff 63722.
ashi1 marked 4 inline comments as done.
ashi1 added a comment.

Revised to Anastasia's comments. Removed opencl-blocks.cl, and created a 
generic opencl.cl inside test/Frontend folder.

This change passes clang-test.


Repository:
  rL LLVM

http://reviews.llvm.org/D22170

Files:
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/opencl.cl
  test/Frontend/opencl-blocks.cl
  test/Frontend/opencl.cl

Index: test/Frontend/opencl.cl
===
--- test/Frontend/opencl.cl
+++ test/Frontend/opencl.cl
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 %s -verify -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only -cl-std=CL1.1
+// RUN: %clang_cc1 %s -verify -fsyntax-only -cl-std=CL1.2
+// RUN: %clang_cc1 %s -verify -fsyntax-only -cl-std=CL2.0
+// RUN: %clang_cc1 %s -verify -fsyntax-only -fblocks -DBLOCKS
+// RUN: %clang_cc1 %s -verify -fsyntax-only -cl-std=CL1.1 -fblocks -DBLOCKS
+// RUN: %clang_cc1 %s -verify -fsyntax-only -cl-std=CL1.2 -fblocks -DBLOCKS
+// RUN: %clang_cc1 %s -triple amdgcn--amdhsa -x c -std=c99 -verify -fsyntax-only
+// RUN: %clang_cc1 -cl-std=CL1.1 -cl-strict-aliasing %s 2>&1 | FileCheck --check-prefix=CHECK-INVALID-OPENCL-VERSION11 %s
+// RUN: %clang_cc1 -cl-std=CL1.2 -cl-strict-aliasing %s 2>&1 | FileCheck --check-prefix=CHECK-INVALID-OPENCL-VERSION12 %s
+// RUN: %clang_cc1 -cl-std=CL2.0 -cl-strict-aliasing %s 2>&1 | FileCheck --check-prefix=CHECK-INVALID-OPENCL-VERSION20 %s
+
+void f(void (^g)(void)) {
+#ifdef __OPENCL_C_VERSION__
+#if __OPENCL_C_VERSION__ < CL_VERSION_2_0 && !defined(BLOCKS)
+  // expected-error@-3{{blocks support disabled - compile with -fblocks or for OpenCL 2.0 or above}}
+#else
+  // expected-no-diagnostics
+#endif
+#else
+  // expected-error@-8{{blocks support disabled - compile with -fblocks or pick a deployment target that supports them}}
+#endif
+}
+
+// CHECK-INVALID-OPENCL-VERSION11: warning: OpenCL version 1.1 does not support the option '-cl-strict-aliasing'
+// CHECK-INVALID-OPENCL-VERSION12: warning: OpenCL version 1.2 does not support the option '-cl-strict-aliasing'
+// CHECK-INVALID-OPENCL-VERSION20: warning: OpenCL version 2.0 does not support the option '-cl-strict-aliasing'
\ No newline at end of file
Index: test/Frontend/opencl-blocks.cl
===
--- test/Frontend/opencl-blocks.cl
+++ test/Frontend/opencl-blocks.cl
@@ -1,20 +0,0 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -cl-std=CL1.1
-// RUN: %clang_cc1 %s -verify -fsyntax-only -cl-std=CL1.2
-// RUN: %clang_cc1 %s -verify -fsyntax-only -cl-std=CL2.0
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fblocks -DBLOCKS
-// RUN: %clang_cc1 %s -verify -fsyntax-only -cl-std=CL1.1 -fblocks -DBLOCKS
-// RUN: %clang_cc1 %s -verify -fsyntax-only -cl-std=CL1.2 -fblocks -DBLOCKS
-// RUN: %clang_cc1 %s -triple amdgcn--amdhsa -x c -std=c99 -verify -fsyntax-only
-
-void f(void (^g)(void)) {
-#ifdef __OPENCL_C_VERSION__
-#if __OPENCL_C_VERSION__ < CL_VERSION_2_0 && !defined(BLOCKS)
-  // expected-error@-3{{blocks support disabled - compile with -fblocks or for OpenCL 2.0 or above}}
-#else
-  // expected-no-diagnostics
-#endif
-#else
-  // expected-error@-8{{blocks support disabled - compile with -fblocks or pick a deployment target that supports them}}
-#endif
-}
Index: test/Driver/opencl.cl
===
--- test/Driver/opencl.cl
+++ test/Driver/opencl.cl
@@ -1,42 +1,35 @@
-// XFAIL: *
-// RUN: %clang -S -### -cl-std=CL %s | FileCheck --check-prefix=CHECK-CL %s
-// RUN: %clang -S -### -cl-std=CL1.1 %s | FileCheck --check-prefix=CHECK-CL11 %s
-// RUN: %clang -S -### -cl-std=CL1.2 %s | FileCheck --check-prefix=CHECK-CL12 %s
-// RUN: %clang -S -### -cl-std=CL2.0 %s | FileCheck --check-prefix=CHECK-CL20 %s
-// RUN: %clang -S -### -cl-opt-disable %s | FileCheck --check-prefix=CHECK-OPT-DISABLE %s
-// RUN: %clang -S -### -cl-strict-aliasing %s | FileCheck --check-prefix=CHECK-STRICT-ALIASING %s
-// RUN: %clang -S -### -cl-std=CL1.1 -cl-strict-aliasing %s | FileCheck --check-prefix=CHECK-INVALID-OPENCL-VERSION11 %s
-// RUN: %clang -S -### -cl-std=CL1.2 -cl-strict-aliasing %s | FileCheck --check-prefix=CHECK-INVALID-OPENCL-VERSION12 %s
-// RUN: %clang -S -### -cl-std=CL2.0 -cl-strict-aliasing %s | FileCheck --check-prefix=CHECK-INVALID-OPENCL-VERSION20 %s
-// RUN: %clang -S -### -cl-single-precision-constant %s | FileCheck --check-prefix=CHECK-SINGLE-PRECISION-CONST %s
-// RUN: %clang -S -### -cl-finite-math-only %s | FileCheck --check-prefix=CHECK-FINITE-MATH-ONLY %s
-// RUN: %clang -S -### -cl-kernel-arg-info %s | FileCheck --check-prefix=CHECK-KERNEL-ARG-INFO %s
-// RUN: %clang -S -### -cl-unsafe-math-optimizations %s | FileCheck --check-prefix=CHECK-UNSAFE-MATH-OPT %s
-// RUN: %clang -S -### -cl-fast-relaxed-math %s | FileCheck --check-prefix=CHECK-FAST-RELAXED-MATH %s
-/

Re: [PATCH] D22073: libc++: test lock-free atomic alignment

2016-07-12 Thread JF Bastien via cfe-commits

jfb updated this revision to Diff 63723.
jfb added a comment.

- Move atomics.align to libcxx-specific
- Give names to anonymous structs


http://reviews.llvm.org/D22073

Files:
  test/libcxx/atomics/atomics.align/align.pass.cpp

Index: test/libcxx/atomics/atomics.align/align.pass.cpp
===
--- /dev/null
+++ test/libcxx/atomics/atomics.align/align.pass.cpp
@@ -0,0 +1,86 @@
+//===--===//
+//
+// 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: libcpp-has-no-threads, c++98, c++03
+
+// 
+
+// Verify that the content of atomic is properly aligned if the type is
+// lock-free. This can't be observed through the atomic API. It is
+// nonetheless required for correctness of the implementation: lock-free 
implies
+// that ISA instructions are used, and these instructions assume "suitable
+// alignment". Supported architectures all require natural alignment for
+// lock-freedom (e.g. load-linked / store-conditional, or cmpxchg).
+
+#include 
+#include 
+
+template  struct atomic_test : public std::__atomic_base {
+  atomic_test() {
+if (this->is_lock_free())
+  assert(alignof(this->__a_) >= sizeof(this->__a_) &&
+ "expected natural alignment for lock-free type");
+  }
+};
+
+int main() {
+
+// structs and unions can't be defined in the template invocation.
+// Work around this with a typedef.
+#define CHECK_ALIGNMENT(T) 
\
+  do { 
\
+typedef T type;
\
+atomic_test t;   
\
+  } while (0)
+
+  CHECK_ALIGNMENT(bool);
+  CHECK_ALIGNMENT(char);
+  CHECK_ALIGNMENT(signed char);
+  CHECK_ALIGNMENT(unsigned char);
+  CHECK_ALIGNMENT(char16_t);
+  CHECK_ALIGNMENT(char32_t);
+  CHECK_ALIGNMENT(wchar_t);
+  CHECK_ALIGNMENT(short);
+  CHECK_ALIGNMENT(unsigned short);
+  CHECK_ALIGNMENT(int);
+  CHECK_ALIGNMENT(unsigned int);
+  CHECK_ALIGNMENT(long);
+  CHECK_ALIGNMENT(unsigned long);
+  CHECK_ALIGNMENT(long long);
+  CHECK_ALIGNMENT(unsigned long long);
+  CHECK_ALIGNMENT(std::nullptr_t);
+  CHECK_ALIGNMENT(void *);
+  CHECK_ALIGNMENT(float);
+  CHECK_ALIGNMENT(double);
+  CHECK_ALIGNMENT(long double);
+  CHECK_ALIGNMENT(int __attribute__((vector_size(1 * sizeof(int);
+  CHECK_ALIGNMENT(int __attribute__((vector_size(2 * sizeof(int);
+  CHECK_ALIGNMENT(int __attribute__((vector_size(4 * sizeof(int);
+  CHECK_ALIGNMENT(int __attribute__((vector_size(16 * sizeof(int);
+  CHECK_ALIGNMENT(int __attribute__((vector_size(32 * sizeof(int);
+  CHECK_ALIGNMENT(float __attribute__((vector_size(1 * sizeof(float);
+  CHECK_ALIGNMENT(float __attribute__((vector_size(2 * sizeof(float);
+  CHECK_ALIGNMENT(float __attribute__((vector_size(4 * sizeof(float);
+  CHECK_ALIGNMENT(float __attribute__((vector_size(16 * sizeof(float);
+  CHECK_ALIGNMENT(float __attribute__((vector_size(32 * sizeof(float);
+  CHECK_ALIGNMENT(double __attribute__((vector_size(1 * sizeof(double);
+  CHECK_ALIGNMENT(double __attribute__((vector_size(2 * sizeof(double);
+  CHECK_ALIGNMENT(double __attribute__((vector_size(4 * sizeof(double);
+  CHECK_ALIGNMENT(double __attribute__((vector_size(16 * sizeof(double);
+  CHECK_ALIGNMENT(double __attribute__((vector_size(32 * sizeof(double);
+  CHECK_ALIGNMENT(struct Empty {});
+  CHECK_ALIGNMENT(struct OneInt { int i; });
+  CHECK_ALIGNMENT(struct IntArr2 { int i[2]; });
+  CHECK_ALIGNMENT(struct LLIArr2 { long long int i[2]; });
+  CHECK_ALIGNMENT(struct LLIArr4 { long long int i[4]; });
+  CHECK_ALIGNMENT(struct LLIArr8 { long long int i[8]; });
+  CHECK_ALIGNMENT(struct LLIArr16 { long long int i[16]; });
+  CHECK_ALIGNMENT(struct Padding { char c; /* padding */ long long int i; });
+  CHECK_ALIGNMENT(union IntFloat { int i; float f; });
+}


Index: test/libcxx/atomics/atomics.align/align.pass.cpp
===
--- /dev/null
+++ test/libcxx/atomics/atomics.align/align.pass.cpp
@@ -0,0 +1,86 @@
+//===--===//
+//
+// 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: libcpp-has-no-threads, c++98, c++03
+
+// 
+
+// Verify that the content of atomic is properly aligned if the

Re: [PATCH] D22073: libc++: test lock-free atomic alignment

2016-07-12 Thread JF Bastien via cfe-commits

jfb added a comment.

In http://reviews.llvm.org/D22073#481402, @EricWF wrote:

> - The test should be moved to `test/libcxx/atomics/atomics.align` since it's 
> libc++ specific.

Done.

> - Please give the anonymous struct declarations unique names. `T1`, `T2`, 
> ..., `TN` is fine. Currently they all mangle to `main::type` in diagnostic 
> output.

Done. I'll update test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp 
in a separate change to do the same (I wrote that one as well, didn't name the 
structs at the time).

> - The test fails to link on my machine unless I manually links `-latomic`. 
> The tests currently don't link `-latomic` and I don't want to turn it on by 
> default. I'll try and fix this.

OK, LMK if I can do anything. I build with:

  cmake -G Ninja ../llvm \
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
-DLLVM_BUILD_TESTS=ON \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DLLVM_ENABLE_ASSERTIONS=ON \
-DCMAKE_C_COMPILER=/path/to/bin/clang \
-DCMAKE_CXX_COMPILER=/path/to/bin/clang++ \
-DLLVM_PATH=/path/to/llvm \
-DLIBCXX_CXX_ABI=libcxxabi \
-DLIBCXX_CXX_ABI_INCLUDE_PATHS=/path/to/llvm/projects/libcxxabi/include \
-DLIBCXX_HAS_ATOMIC_LIB=True

I found it weird to have to specify `-DLIBCXX_HAS_ATOMIC_LIB=True` because it 
tells me that libc++ isn't tested *at all* with GCCMM atomic runtime functions 
! I was going to look into that 
afterwards.

IMO we may want to always link to it.

http://reviews.llvm.org/D22073

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

[libcxx] r275210 - libc++: name anonymous structs

2016-07-12 Thread JF Bastien via cfe-commits

Author: jfb
Date: Tue Jul 12 15:14:52 2016
New Revision: 275210

URL: http://llvm.org/viewvc/llvm-project?rev=275210&view=rev
Log:
libc++: name anonymous structs

As discussed in http://reviews.llvm.org/D22073

Modified:
libcxx/trunk/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp

Modified: 
libcxx/trunk/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp?rev=275210&r1=275209&r2=275210&view=diff
==
--- libcxx/trunk/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp 
(original)
+++ libcxx/trunk/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp 
Tue Jul 12 15:14:52 2016
@@ -70,15 +70,15 @@ int main()
 CHECK_ALWAYS_LOCK_FREE(double __attribute__((vector_size(4 * 
sizeof(double);
 CHECK_ALWAYS_LOCK_FREE(double __attribute__((vector_size(16 * 
sizeof(double);
 CHECK_ALWAYS_LOCK_FREE(double __attribute__((vector_size(32 * 
sizeof(double);
-CHECK_ALWAYS_LOCK_FREE(struct{});
-CHECK_ALWAYS_LOCK_FREE(struct{ int i; });
-CHECK_ALWAYS_LOCK_FREE(struct{ int i[2]; });
-CHECK_ALWAYS_LOCK_FREE(struct{ long long int i[2]; });
-CHECK_ALWAYS_LOCK_FREE(struct{ long long int i[4]; });
-CHECK_ALWAYS_LOCK_FREE(struct{ long long int i[8]; });
-CHECK_ALWAYS_LOCK_FREE(struct{ long long int i[16]; });
-CHECK_ALWAYS_LOCK_FREE(struct{ char c; /* padding */ long long int i; });
-CHECK_ALWAYS_LOCK_FREE(union{ int i; float f; });
+CHECK_ALWAYS_LOCK_FREE(struct Empty {});
+CHECK_ALWAYS_LOCK_FREE(struct OneInt { int i; });
+CHECK_ALWAYS_LOCK_FREE(struct IntArr2 { int i[2]; });
+CHECK_ALWAYS_LOCK_FREE(struct LLIArr2 { long long int i[2]; });
+CHECK_ALWAYS_LOCK_FREE(struct LLIArr4 { long long int i[4]; });
+CHECK_ALWAYS_LOCK_FREE(struct LLIArr8 { long long int i[8]; });
+CHECK_ALWAYS_LOCK_FREE(struct LLIArr16 { long long int i[16]; });
+CHECK_ALWAYS_LOCK_FREE(struct Padding { char c; /* padding */ long long 
int i; });
+CHECK_ALWAYS_LOCK_FREE(union IntFloat { int i; float f; });
 
 // C macro and static constexpr must be consistent.
 static_assert(std::atomic::is_always_lock_free == (2 == 
ATOMIC_BOOL_LOCK_FREE));


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

[libcxx] r275211 - Add more tests for LWG#2582. No code changes needed, just tests.

2016-07-12 Thread Marshall Clow via cfe-commits

Author: marshall
Date: Tue Jul 12 15:15:46 2016
New Revision: 275211

URL: http://llvm.org/viewvc/llvm-project?rev=275211&view=rev
Log:
Add more tests for LWG#2582. No code changes needed, just tests.

Modified:

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/array.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/class.pass.cpp
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/enum.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/floating_point.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/function.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/integral.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/is_array.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/lvalue_ref.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/member_function_pointer.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/member_function_pointer_no_variadics.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/member_object_pointer.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/nullptr.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/pointer.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/rvalue_ref.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/union.pass.cpp
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/void.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.comp/array.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.comp/class.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.comp/is_arithmetic.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.comp/is_compound.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.comp/is_fundamental.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.comp/is_member_pointer.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.comp/is_object.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.comp/is_reference.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.comp/is_scalar.pass.cpp
libcxx/trunk/www/cxx1z_status.html

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/array.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/array.pass.cpp?rev=275211&r1=275210&r2=275211&view=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/array.pass.cpp 
(original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/array.pass.cpp 
Tue Jul 12 15:15:46 2016
@@ -47,14 +47,15 @@ void test_array()
 typedef char array[3];
 typedef const char const_array[3];
 typedef char incomplete_array[];
-struct incomplete_type;
+struct Incomplete;
 
 int main()
 {
 test_array();
 test_array();
 test_array();
+test_array();
 
-//  LWG#2581
-static_assert(!std::is_array::value, "");
+//  LWG#2582
+static_assert(!std::is_array::value, "");
 }

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/class.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/class.pass.cpp?rev=275211&r1=275210&r2=275211&view=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/class.pass.cpp 
(original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/class.pass.cpp 
Tue Jul 12 15:15:46 2016
@@ -53,7 +53,8 @@ struct incomplete_type;
 int main()
 {
 test_class();
+test_class();
 
-//  LWG#2581
+//  LWG#2582
 static_assert( std::is_class::value, "");
 }

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/enum.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/enum.pass.cpp?rev=275211&r1=275210&r2=275211&view=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/enum.pass.cpp 
(original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/enum.pass.cpp 
Tue Jul 12 15:15:46 2016
@@ -51,6 +51,6 @@ int main()
 {
 test_enum();
 
-//  LWG#2581
+//  LWG#2582
 static_assert(!std::is_enum::value, "");
 }

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/floating_point.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.cat/floating_point.pas

Re: [PATCH] D22270: [ASTImporter] Properly report the locations of anonymous structs declared as part of named fields

2016-07-12 Thread Manman Ren via cfe-commits

manmanren added a comment.

I am not sure if we should handle this inside findAnonymousStructOrUnionIndex. 
Here is the definition of anonymous structure I found: An unnamed member whose 
type specifier is a structure specifier with no tag is called an anonymous 
structure.

Cheers,
Manman



Comment at: lib/AST/ASTImporter.cpp:1054
@@ +1053,3 @@
+  QualType FieldType = F->getType();
+  if (const RecordType *RecType = dyn_cast(FieldType)) {
+const RecordDecl *RecDecl = RecType->getDecl();

Use const auto * here?


Comment at: lib/AST/ASTImporter.cpp:1058
@@ +1057,3 @@
+!RecDecl->getIdentifier()) {
+  if (Context.hasSameType(FieldType, AnonTy)) {
+break;

Combining the two ifs?


Comment at: lib/AST/ASTImporter.cpp:1062
@@ +1061,3 @@
+}
+  }
+}

Should we continue here instead of increasing the Index?

Maybe we can reorder here to reduce nesting?
if (F->isAnonymousStructOrUnion() && ...)
  break;
if (F->isAnonymousStructOrUnion())
  Index++;
  continue;
// If the field looks like this: ...



Comment at: test/ASTMerge/anonymous-fields.cpp:3
@@ +2,3 @@
+// RUN: %clang_cc1 -emit-pch -o %t.2.ast %S/Inputs/anonymous-fields2.cpp
+// RUN: %clang_cc1 -emit-obj -o /dev/null -ast-merge %t.1.ast -ast-merge 
%t.2.ast %s
+// expected-no-diagnostics

Does this test fail without the change in ASTImporter.cpp? Should we check the 
output of the AST merging?


Repository:
  rL LLVM

http://reviews.llvm.org/D22270



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

RE: r275040 - [CodeGen] Treat imported static local variables as declarations

2016-07-12 Thread Robinson, Paul via cfe-commits

I was asking for the debug info to describe the entity as a declaration, rather 
than a definition.
Instead you eliminated the debug-info description entirely.  These are pretty 
different things.
--paulr

From: David Majnemer [mailto:david.majne...@gmail.com]
Sent: Monday, July 11, 2016 12:27 PM
To: Robinson, Paul
Cc: cfe-commits (cfe-commits@lists.llvm.org)
Subject: Re: r275040 - [CodeGen] Treat imported static local variables as 
declarations



On Mon, Jul 11, 2016 at 11:45 AM, Robinson, Paul 
mailto:paul.robin...@sony.com>> wrote:
It was not particularly obvious that by "static local variables" you actually 
meant "template static data members."
Now I can tell that this is not addressing what I was asking about in the 
comment on r274986.

I'm not sure I understand.  How is this not addressing what you are asking for? 
 We will no longer emit a DIGlobalVariable for the imported static data member.

--paulr

From: David Majnemer 
[mailto:david.majne...@gmail.com]
Sent: Monday, July 11, 2016 9:53 AM
To: Robinson, Paul
Cc: cfe-commits (cfe-commits@lists.llvm.org)
Subject: Re: r275040 - [CodeGen] Treat imported static local variables as 
declarations



On Mon, Jul 11, 2016 at 9:48 AM, Robinson, Paul 
mailto:paul.robin...@sony.com>> wrote:
This changes the IR but not the debug-info metadata?
--paulr

The net effect is that the debug-info metadata is not generated for such static 
members.


> -Original Message-
> From: cfe-commits 
> [mailto:cfe-commits-boun...@lists.llvm.org]
>  On Behalf Of
> David Majnemer via cfe-commits
> Sent: Sunday, July 10, 2016 9:28 PM
> To: cfe-commits@lists.llvm.org
> Subject: r275040 - [CodeGen] Treat imported static local variables as
> declarations
>
> Author: majnemer
> Date: Sun Jul 10 23:28:21 2016
> New Revision: 275040
>
> URL: http://llvm.org/viewvc/llvm-project?rev=275040&view=rev
> Log:
> [CodeGen] Treat imported static local variables as declarations
>
> Imported variables cannot really be definitions for the purposes of
> IR generation.
>
> Modified:
> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/test/CodeGenCXX/dllimport.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=275040&r1=275039&r2=275040
> &view=diff
> ==
> 
> --- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Sun Jul 10 23:28:21 2016
> @@ -323,10 +323,6 @@ CodeGenModule::EmitCXXGlobalVarDeclInitF
> D->hasAttr()))
>  return;
>
> -  // DLL imported variables will be initialized by the export side.
> -  if (D->hasAttr())
> -return;
> -
>// Check if we've already initialized this decl.
>auto I = DelayedCXXInitPosition.find(D);
>if (I != DelayedCXXInitPosition.end() && I->second == ~0U)
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=275040&r1=275039&r2=27
> 5040&view=diff
> ==
> 
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Sun Jul 10 23:28:21 2016
> @@ -2851,6 +2851,10 @@ static void ReplaceUsesOfNonProtoTypeWit
>  }
>
>  void CodeGenModule::HandleCXXStaticMemberVarInstantiation(VarDecl *VD) {
> +  auto DK = VD->isThisDeclarationADefinition();
> +  if (DK == VarDecl::Definition && VD->hasAttr())
> +return;
> +
>TemplateSpecializationKind TSK = VD->getTemplateSpecializationKind();
>// If we have a definition, this might be a deferred decl. If the
>// instantiation is explicit, make sure we emit it at the end.
>
> Modified: cfe/trunk/test/CodeGenCXX/dllimport.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/test/CodeGenCXX/dllimport.cpp?rev=275040&r1=275039&r2=27
> 5040&view=diff
> ==
> 
> --- cfe/trunk/test/CodeGenCXX/dllimport.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/dllimport.cpp Sun Jul 10 23:28:21 2016
> @@ -676,7 +676,7 @@ namespace ClassTemplateStaticDef {
>  static int x;
>};
>template  int S::x;
> -  // MSC-DAG: @"\01?x@?$S@H@ClassTemplateStaticDef@@2HA" =
> available_externally dllimport global i32 0
> +  // MSC-DAG: @"\01?x@?$S@H@ClassTemplateStaticDef@@2HA" = external
> dllimport global i32
>int f() { return S::x; }
>
>// Partial class template specialization static field:
> @@ -685,7 +685,7 @@ namespace ClassTemplateStaticDef {
>  static int x;
>};
>template  int T::x;
> -  // GNU-DAG: @_ZN22ClassTemplateStaticDef1TIPvE1xE =
> available_externally dllimport global i32 0
> +  // GNU-DAG: @_ZN22

Re: r275040 - [CodeGen] Treat imported static local variables as declarations

2016-07-12 Thread David Majnemer via cfe-commits

On Tue, Jul 12, 2016 at 2:02 PM, Robinson, Paul 
wrote:

> I was asking for the debug info to describe the entity as a declaration,
> rather than a definition.
>
> Instead you eliminated the debug-info description entirely.  These are
> pretty different things.
>

I treated the dllimported entity the same way we currently treat
declarations: ignore them.
I don't have the bandwidth to generically improve debug info beyond what we
can do for DWARF/GDB targets.


> --paulr
>
>
>
> *From:* David Majnemer [mailto:david.majne...@gmail.com]
> *Sent:* Monday, July 11, 2016 12:27 PM
>
> *To:* Robinson, Paul
> *Cc:* cfe-commits (cfe-commits@lists.llvm.org)
> *Subject:* Re: r275040 - [CodeGen] Treat imported static local variables
> as declarations
>
>
>
>
>
>
>
> On Mon, Jul 11, 2016 at 11:45 AM, Robinson, Paul 
> wrote:
>
> It was not particularly obvious that by "static local variables" you
> actually meant "template static data members."
>
> Now I can tell that this is not addressing what I was asking about in the
> comment on r274986.
>
>
>
> I'm not sure I understand.  How is this not addressing what you are asking
> for?  We will no longer emit a DIGlobalVariable for the imported static
> data member.
>
>
>
> --paulr
>
>
>
> *From:* David Majnemer [mailto:david.majne...@gmail.com]
> *Sent:* Monday, July 11, 2016 9:53 AM
> *To:* Robinson, Paul
> *Cc:* cfe-commits (cfe-commits@lists.llvm.org)
> *Subject:* Re: r275040 - [CodeGen] Treat imported static local variables
> as declarations
>
>
>
>
>
>
>
> On Mon, Jul 11, 2016 at 9:48 AM, Robinson, Paul 
> wrote:
>
> This changes the IR but not the debug-info metadata?
> --paulr
>
>
>
> The net effect is that the debug-info metadata is not generated for such
> static members.
>
>
>
>
> > -Original Message-
> > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of
> > David Majnemer via cfe-commits
> > Sent: Sunday, July 10, 2016 9:28 PM
> > To: cfe-commits@lists.llvm.org
> > Subject: r275040 - [CodeGen] Treat imported static local variables as
> > declarations
> >
> > Author: majnemer
> > Date: Sun Jul 10 23:28:21 2016
> > New Revision: 275040
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=275040&view=rev
> > Log:
> > [CodeGen] Treat imported static local variables as declarations
> >
> > Imported variables cannot really be definitions for the purposes of
> > IR generation.
> >
> > Modified:
> > cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> > cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> > cfe/trunk/test/CodeGenCXX/dllimport.cpp
> >
> > Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> > URL: http://llvm.org/viewvc/llvm-
> >
> project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=275040&r1=275039&r2=275040
> > &view=diff
> >
> ==
> > 
> > --- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Sun Jul 10 23:28:21 2016
> > @@ -323,10 +323,6 @@ CodeGenModule::EmitCXXGlobalVarDeclInitF
> > D->hasAttr()))
> >  return;
> >
> > -  // DLL imported variables will be initialized by the export side.
> > -  if (D->hasAttr())
> > -return;
> > -
> >// Check if we've already initialized this decl.
> >auto I = DelayedCXXInitPosition.find(D);
> >if (I != DelayedCXXInitPosition.end() && I->second == ~0U)
> >
> > Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> > URL: http://llvm.org/viewvc/llvm-
> >
> project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=275040&r1=275039&r2=27
> > 5040&view=diff
> >
> ==
> > 
> > --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Sun Jul 10 23:28:21 2016
> > @@ -2851,6 +2851,10 @@ static void ReplaceUsesOfNonProtoTypeWit
> >  }
> >
> >  void CodeGenModule::HandleCXXStaticMemberVarInstantiation(VarDecl *VD) {
> > +  auto DK = VD->isThisDeclarationADefinition();
> > +  if (DK == VarDecl::Definition && VD->hasAttr())
> > +return;
> > +
> >TemplateSpecializationKind TSK = VD->getTemplateSpecializationKind();
> >// If we have a definition, this might be a deferred decl. If the
> >// instantiation is explicit, make sure we emit it at the end.
> >
> > Modified: cfe/trunk/test/CodeGenCXX/dllimport.cpp
> > URL: http://llvm.org/viewvc/llvm-
> >
> project/cfe/trunk/test/CodeGenCXX/dllimport.cpp?rev=275040&r1=275039&r2=27
> > 5040&view=diff
> >
> ==
> > 
> > --- cfe/trunk/test/CodeGenCXX/dllimport.cpp (original)
> > +++ cfe/trunk/test/CodeGenCXX/dllimport.cpp Sun Jul 10 23:28:21 2016
> > @@ -676,7 +676,7 @@ namespace ClassTemplateStaticDef {
> >  static int x;
> >};
> >template  int S::x;
> > -  // MSC-DAG: @"\01?x@?$S@H@ClassTemplateStaticDef@@2HA" =
> > available_externally dllimport global i32 0
> > +  // MSC-DAG: @"\01?x@?$S@H@ClassTemplateStaticDef@@2HA" = exter

Re: [PATCH] D21695: [clang] Version support for UBSan handlers

2016-07-12 Thread Filipe Cabecinhas via cfe-commits

filcab added a comment.

Ping!


http://reviews.llvm.org/D21695



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

RE: r275040 - [CodeGen] Treat imported static local variables as declarations

2016-07-12 Thread Robinson, Paul via cfe-commits

A declaration that gets used within the CU generally does get a debug-info 
description.
I think no DWARF-using target has dllimport (yet) so you are actually handling 
a new situation here.  Being unable to find the entity in the dllimport-using 
CU is not a friendly debugging experience.
--paulr

From: David Majnemer [mailto:david.majne...@gmail.com]
Sent: Tuesday, July 12, 2016 2:07 PM
To: Robinson, Paul
Cc: cfe-commits (cfe-commits@lists.llvm.org)
Subject: Re: r275040 - [CodeGen] Treat imported static local variables as 
declarations



On Tue, Jul 12, 2016 at 2:02 PM, Robinson, Paul 
mailto:paul.robin...@sony.com>> wrote:
I was asking for the debug info to describe the entity as a declaration, rather 
than a definition.
Instead you eliminated the debug-info description entirely.  These are pretty 
different things.

I treated the dllimported entity the same way we currently treat declarations: 
ignore them.
I don't have the bandwidth to generically improve debug info beyond what we can 
do for DWARF/GDB targets.

--paulr

From: David Majnemer 
[mailto:david.majne...@gmail.com]
Sent: Monday, July 11, 2016 12:27 PM

To: Robinson, Paul
Cc: cfe-commits (cfe-commits@lists.llvm.org)
Subject: Re: r275040 - [CodeGen] Treat imported static local variables as 
declarations



On Mon, Jul 11, 2016 at 11:45 AM, Robinson, Paul 
mailto:paul.robin...@sony.com>> wrote:
It was not particularly obvious that by "static local variables" you actually 
meant "template static data members."
Now I can tell that this is not addressing what I was asking about in the 
comment on r274986.

I'm not sure I understand.  How is this not addressing what you are asking for? 
 We will no longer emit a DIGlobalVariable for the imported static data member.

--paulr

From: David Majnemer 
[mailto:david.majne...@gmail.com]
Sent: Monday, July 11, 2016 9:53 AM
To: Robinson, Paul
Cc: cfe-commits (cfe-commits@lists.llvm.org)
Subject: Re: r275040 - [CodeGen] Treat imported static local variables as 
declarations



On Mon, Jul 11, 2016 at 9:48 AM, Robinson, Paul 
mailto:paul.robin...@sony.com>> wrote:
This changes the IR but not the debug-info metadata?
--paulr

The net effect is that the debug-info metadata is not generated for such static 
members.


> -Original Message-
> From: cfe-commits 
> [mailto:cfe-commits-boun...@lists.llvm.org]
>  On Behalf Of
> David Majnemer via cfe-commits
> Sent: Sunday, July 10, 2016 9:28 PM
> To: cfe-commits@lists.llvm.org
> Subject: r275040 - [CodeGen] Treat imported static local variables as
> declarations
>
> Author: majnemer
> Date: Sun Jul 10 23:28:21 2016
> New Revision: 275040
>
> URL: http://llvm.org/viewvc/llvm-project?rev=275040&view=rev
> Log:
> [CodeGen] Treat imported static local variables as declarations
>
> Imported variables cannot really be definitions for the purposes of
> IR generation.
>
> Modified:
> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/test/CodeGenCXX/dllimport.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=275040&r1=275039&r2=275040
> &view=diff
> ==
> 
> --- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Sun Jul 10 23:28:21 2016
> @@ -323,10 +323,6 @@ CodeGenModule::EmitCXXGlobalVarDeclInitF
> D->hasAttr()))
>  return;
>
> -  // DLL imported variables will be initialized by the export side.
> -  if (D->hasAttr())
> -return;
> -
>// Check if we've already initialized this decl.
>auto I = DelayedCXXInitPosition.find(D);
>if (I != DelayedCXXInitPosition.end() && I->second == ~0U)
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=275040&r1=275039&r2=27
> 5040&view=diff
> ==
> 
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Sun Jul 10 23:28:21 2016
> @@ -2851,6 +2851,10 @@ static void ReplaceUsesOfNonProtoTypeWit
>  }
>
>  void CodeGenModule::HandleCXXStaticMemberVarInstantiation(VarDecl *VD) {
> +  auto DK = VD->isThisDeclarationADefinition();
> +  if (DK == VarDecl::Definition && VD->hasAttr())
> +return;
> +
>TemplateSpecializationKind TSK = VD->getTemplateSpecializationKind();
>// If we have a definition, this might be a deferred decl. If the
>// instantiation is explicit, make sure we emit it at the end.
>
> Modified: cfe/trunk/test/CodeGenCXX/dllimport.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/test/CodeGenCXX/dllim

Re: [PATCH] D21706: [libcxx] refactor for throw

2016-07-12 Thread Marshall Clow via cfe-commits

mclow.lists added a comment.

I just realized that this will break the following code:

  try {  __cxxabiv1:: __cxa_bad_cast(); }
  catch ( std::bad_cast &ex ) {}

because what gets thrown is a `const std::bad_cast &`

Yes, people should catch by value or const reference.
But that doesn't mean that they always do.



Comment at: include/exception:262
@@ -261,3 +261,3 @@
 _LIBCPP_INLINE_VISIBILITY
-inline void __libcpp_throw(_Exception const& __e) {
+inline __attribute__((noreturn)) void __libcpp_throw(_Exception const& __e) {
 #ifndef _LIBCPP_NO_EXCEPTIONS

weimingz wrote:
> mclow.lists wrote:
> > I thought that we were going to add a macro for the "no return if no 
> > exceptions"
> something like this?
> 
> #ifndef __LIBCPP_NO_EXCEPTIONS
>   #define NORETURN_EXP __attribute__((noreturn))
> #else
>   #define NORETURN_EXP
> #endif
> 
> inline NORETURN_EXP void __libcpp_throw(_Exception const& __e) {
>   ...
> }
There's another patch out for review that adds `noreturn` attributes for some 
functions when exceptions are disabled. I suggested a macro name like 
`_LIBCPP_NO_RETURN_WHEN_EXCEPTIONS_DISABLED` for this instead of using the 
`[[noreturn]]` or `__attribute__((noreturn)) `.

I can't find the review at the moment, but I'll turn it up.


http://reviews.llvm.org/D21706



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

[PATCH] D22285: Support -masm= flag for x86 assembly targets

2016-07-12 Thread Yunzhong Gao via cfe-commits

ygao created this revision.
ygao added subscribers: thakis, cfe-commits.

For assembly files without .intel_syntax or .att_syntax directives, allow the
-masm= flag to supply a default assembly dialect. For example,

C:\TMP> type intel.s
.text
mov al,0

C:\TMP> clang -masm=intel -c intel.s

Without this patch, one would need to pass an -mllvm -x86-asm-syntax= flag 
directly to the backend.
C:\TMP> clang -mllvm --x86-asm-syntax=intel -c intel.s

Does it seem acceptable to expose -masm= flag as a way to configure the input 
assembly syntax?


http://reviews.llvm.org/D22285

Files:
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  test/Driver/masm.s

Index: test/Driver/masm.s
===
--- test/Driver/masm.s
+++ test/Driver/masm.s
@@ -0,0 +1,11 @@
+// RUN: %clang -target i386-unknown-linux -masm=intel -c %s -### 2>&1 | 
FileCheck --check-prefix=CHECK-INTEL %s
+// RUN: %clang -target i386-unknown-linux -masm=att -c %s -### 2>&1 | 
FileCheck --check-prefix=CHECK-ATT %s
+// RUN: %clang -target i386-unknown-linux -c -masm=somerequired %s -### 2>&1 | 
FileCheck --check-prefix=CHECK-SOMEREQUIRED %s
+// RUN: %clang -target arm-unknown-eabi -c -masm=intel %s -### 2>&1 | 
FileCheck --check-prefix=CHECK-ARM %s
+
+// CHECK-INTEL: -x86-asm-syntax=intel
+// CHECK-ATT: -x86-asm-syntax=att
+// CHECK-SOMEREQUIRED: error: unsupported argument 'somerequired' to option 
'masm='
+// CHECK-ARM: warning: argument unused during compilation: '-masm=intel'
+.text
+moval, 0
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -126,6 +126,8 @@
   : Tool("clang::as", "clang integrated assembler", TC, RF_Full) {}
   void AddMIPSTargetArgs(const llvm::opt::ArgList &Args,
  llvm::opt::ArgStringList &CmdArgs) const;
+  void AddX86TargetArgs(const llvm::opt::ArgList &Args,
+llvm::opt::ArgStringList &CmdArgs) const;
   bool hasGoodDiagnostics() const override { return true; }
   bool hasIntegratedAssembler() const override { return false; }
   bool hasIntegratedCPP() const override { return false; }
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -6375,6 +6375,20 @@
   CmdArgs.push_back(ABIName.data());
 }
 
+void ClangAs::AddX86TargetArgs(const ArgList &Args,
+ArgStringList &CmdArgs) const {
+  if (Arg *A = Args.getLastArg(options::OPT_masm_EQ)) {
+StringRef Value = A->getValue();
+if (Value == "intel" || Value == "att") {
+  CmdArgs.push_back("-mllvm");
+  CmdArgs.push_back(Args.MakeArgString("-x86-asm-syntax=" + Value));
+} else {
+  
getToolChain().getDriver().Diag(diag::err_drv_unsupported_option_argument)
+  << A->getOption().getName() << Value;
+}
+  }
+}
+
 void ClangAs::ConstructJob(Compilation &C, const JobAction &JA,
const InputInfo &Output, const InputInfoList 
&Inputs,
const ArgList &Args,
@@ -6522,6 +6536,11 @@
   case llvm::Triple::mips64el:
 AddMIPSTargetArgs(Args, CmdArgs);
 break;
+
+  case llvm::Triple::x86:
+  case llvm::Triple::x86_64:
+AddX86TargetArgs(Args, CmdArgs);
+break;
   }
 
   // Consume all the warning flags. Usually this would be handled more


Index: test/Driver/masm.s
===
--- test/Driver/masm.s
+++ test/Driver/masm.s
@@ -0,0 +1,11 @@
+// RUN: %clang -target i386-unknown-linux -masm=intel -c %s -### 2>&1 | FileCheck --check-prefix=CHECK-INTEL %s
+// RUN: %clang -target i386-unknown-linux -masm=att -c %s -### 2>&1 | FileCheck --check-prefix=CHECK-ATT %s
+// RUN: %clang -target i386-unknown-linux -c -masm=somerequired %s -### 2>&1 | FileCheck --check-prefix=CHECK-SOMEREQUIRED %s
+// RUN: %clang -target arm-unknown-eabi -c -masm=intel %s -### 2>&1 | FileCheck --check-prefix=CHECK-ARM %s
+
+// CHECK-INTEL: -x86-asm-syntax=intel
+// CHECK-ATT: -x86-asm-syntax=att
+// CHECK-SOMEREQUIRED: error: unsupported argument 'somerequired' to option 'masm='
+// CHECK-ARM: warning: argument unused during compilation: '-masm=intel'
+.text
+moval, 0
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -126,6 +126,8 @@
   : Tool("clang::as", "clang integrated assembler", TC, RF_Full) {}
   void AddMIPSTargetArgs(const llvm::opt::ArgList &Args,
  llvm::opt::ArgStringList &CmdArgs) const;
+  void AddX86TargetArgs(const llvm::opt::ArgList &Args,
+llvm::opt::ArgStringList &CmdArgs) const;
   bool hasGoodDiagnostics() const override { return true; }
   bool hasIntegratedAssembler() const override { return false; }
   bool hasIntegratedCPP() const override { return false; }
Index: lib/Driver/T

Re: r275040 - [CodeGen] Treat imported static local variables as declarations

2016-07-12 Thread David Majnemer via cfe-commits

On Tue, Jul 12, 2016 at 2:55 PM, Robinson, Paul 
wrote:

> A declaration that gets used within the CU generally does get a debug-info
> description.
>

It does except if it is a static data member:
$ cat t.cpp
struct S {
  static int i;
};
int &gv = &S::i;
$ ~/llvm/Debug+Asserts/bin/clang t.cpp -target x86_64-gnu-linux -g -S
-emit-llvm -o -
; ModuleID = 't.cpp'
source_filename = "t.cpp"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64--linux-gnu"

@_ZN1S1iE = external global i32, align 4
@gv = global i32* @_ZN1S1iE, align 8

!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!7, !8}
!llvm.ident = !{!9}

!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1,
producer: "clang version 3.9.0 (trunk 275169) (llvm/trunk 275188)",
isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2,
globals: !3)
!1 = !DIFile(filename: "t.cpp", directory:
"/usr/local/google/home/majnemer")
!2 = !{}
!3 = !{!4}
!4 = distinct !DIGlobalVariable(name: "gv", scope: !0, file: !1, line: 4,
type: !5, isLocal: false, isDefinition: true, variable: i32** @gv)
!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64,
align: 64)
!6 = !DIBasicType(name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
!7 = !{i32 2, !"Dwarf Version", i32 4}
!8 = !{i32 2, !"Debug Info Version", i32 3}
!9 = !{!"clang version 3.9.0 (trunk 275169) (llvm/trunk 275188)"}

Note that there is no DIGlobalVariable for S::i.  I agree that this is not
great behavior.  I merely changed a dllimport'd template instantiation of a
static data member to behave the same way, poor, way a declaration is
treated.


> I think no DWARF-using target has dllimport (yet) so you are actually
> handling a new situation here.  Being unable to find the entity in the
> dllimport-using CU is not a friendly debugging experience.
>
> --paulr
>
>
>
> *From:* David Majnemer [mailto:david.majne...@gmail.com]
> *Sent:* Tuesday, July 12, 2016 2:07 PM
>
> *To:* Robinson, Paul
> *Cc:* cfe-commits (cfe-commits@lists.llvm.org)
> *Subject:* Re: r275040 - [CodeGen] Treat imported static local variables
> as declarations
>
>
>
>
>
>
>
> On Tue, Jul 12, 2016 at 2:02 PM, Robinson, Paul 
> wrote:
>
> I was asking for the debug info to describe the entity as a declaration,
> rather than a definition.
>
> Instead you eliminated the debug-info description entirely.  These are
> pretty different things.
>
>
>
> I treated the dllimported entity the same way we currently treat
> declarations: ignore them.
>
> I don't have the bandwidth to generically improve debug info beyond what
> we can do for DWARF/GDB targets.
>
>
>
> --paulr
>
>
>
> *From:* David Majnemer [mailto:david.majne...@gmail.com]
> *Sent:* Monday, July 11, 2016 12:27 PM
>
>
> *To:* Robinson, Paul
> *Cc:* cfe-commits (cfe-commits@lists.llvm.org)
> *Subject:* Re: r275040 - [CodeGen] Treat imported static local variables
> as declarations
>
>
>
>
>
>
>
> On Mon, Jul 11, 2016 at 11:45 AM, Robinson, Paul 
> wrote:
>
> It was not particularly obvious that by "static local variables" you
> actually meant "template static data members."
>
> Now I can tell that this is not addressing what I was asking about in the
> comment on r274986.
>
>
>
> I'm not sure I understand.  How is this not addressing what you are asking
> for?  We will no longer emit a DIGlobalVariable for the imported static
> data member.
>
>
>
> --paulr
>
>
>
> *From:* David Majnemer [mailto:david.majne...@gmail.com]
> *Sent:* Monday, July 11, 2016 9:53 AM
> *To:* Robinson, Paul
> *Cc:* cfe-commits (cfe-commits@lists.llvm.org)
> *Subject:* Re: r275040 - [CodeGen] Treat imported static local variables
> as declarations
>
>
>
>
>
>
>
> On Mon, Jul 11, 2016 at 9:48 AM, Robinson, Paul 
> wrote:
>
> This changes the IR but not the debug-info metadata?
> --paulr
>
>
>
> The net effect is that the debug-info metadata is not generated for such
> static members.
>
>
>
>
> > -Original Message-
> > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of
> > David Majnemer via cfe-commits
> > Sent: Sunday, July 10, 2016 9:28 PM
> > To: cfe-commits@lists.llvm.org
> > Subject: r275040 - [CodeGen] Treat imported static local variables as
> > declarations
> >
> > Author: majnemer
> > Date: Sun Jul 10 23:28:21 2016
> > New Revision: 275040
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=275040&view=rev
> > Log:
> > [CodeGen] Treat imported static local variables as declarations
> >
> > Imported variables cannot really be definitions for the purposes of
> > IR generation.
> >
> > Modified:
> > cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> > cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> > cfe/trunk/test/CodeGenCXX/dllimport.cpp
> >
> > Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> > URL: http://llvm.org/viewvc/llvm-
> >
> project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=275040&r1=275039&r2=275040
> > &view=diff
> >
> ==
> >

Re: [PATCH] D21912: [CUDA] Don't assume that destructors can't be overloaded.

2016-07-12 Thread Reid Kleckner via cfe-commits

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

lgtm


http://reviews.llvm.org/D21912



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

Re: [PATCH] D20100: [NFC] Header cleanup

2016-07-12 Thread Mehdi AMINI via cfe-commits

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

Looks like a nice cleanup.


http://reviews.llvm.org/D20100



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

r275231 - [CUDA] Don't assume that destructors can't be overloaded.

2016-07-12 Thread Justin Lebar via cfe-commits

Author: jlebar
Date: Tue Jul 12 18:23:01 2016
New Revision: 275231

URL: http://llvm.org/viewvc/llvm-project?rev=275231&view=rev
Log:
[CUDA] Don't assume that destructors can't be overloaded.

Summary:
You can overload a destructor in CUDA, and SemaOverload needs to be
tweaked not to crash when it sees an explicit call to an overloaded
destructor.

Reviewers: rsmith

Subscribers: cfe-commits, tra

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

Added:
cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu
Modified:
cfe/trunk/lib/Sema/SemaOverload.cpp

Modified: cfe/trunk/lib/Sema/SemaOverload.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOverload.cpp?rev=275231&r1=275230&r2=275231&view=diff
==
--- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOverload.cpp Tue Jul 12 18:23:01 2016
@@ -12407,8 +12407,7 @@ Sema::BuildCallToMemberFunction(Scope *S
   if (CXXDestructorDecl *DD =
   dyn_cast(TheCall->getMethodDecl())) {
 // a->A::f() doesn't go through the vtable, except in AppleKext mode.
-bool CallCanBeVirtual = !cast(NakedMemExpr)->hasQualifier() ||
-getLangOpts().AppleKext;
+bool CallCanBeVirtual = !MemExpr->hasQualifier() || 
getLangOpts().AppleKext;
 CheckVirtualDtorCall(DD, MemExpr->getLocStart(), /*IsDelete=*/false,
  CallCanBeVirtual, /*WarnOnNonAbstractTypes=*/true,
  MemExpr->getMemberLoc());

Added: cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu?rev=275231&view=auto
==
--- cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu (added)
+++ cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu Tue Jul 12 18:23:01 
2016
@@ -0,0 +1,17 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device 
-verify %s
+
+#include "Inputs/cuda.h"
+
+struct S {
+  __host__ ~S() {}
+  __device__ ~S() {}
+};
+
+__host__ __device__ void test() {
+  S s;
+  // This should not crash clang.
+  s.~S();
+}


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

r275232 - [CUDA] Add additional testcases for EraseUnwantedCUDAMatches.

2016-07-12 Thread Justin Lebar via cfe-commits

Author: jlebar
Date: Tue Jul 12 18:23:12 2016
New Revision: 275232

URL: http://llvm.org/viewvc/llvm-project?rev=275232&view=rev
Log:
[CUDA] Add additional testcases for EraseUnwantedCUDAMatches.

Summary:
Specifically, this patch adds testcases for all three calls to
EraseUnwantedCUDAMatches.  The addr-of-overloaded-fn test I accidentally
neutered in r264207, which moved much of
CodeGenCUDA/function-overload.cu into SemaCUDA/function-overload.cu.
The coverage from overloaded-delete test is new.

Reviewers: tra

Subscribers: cfe-commits

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

Added:
cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu
cfe/trunk/test/SemaCUDA/overloaded-delete.cu

Added: cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu?rev=275232&view=auto
==
--- cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu (added)
+++ cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu Tue Jul 12 18:23:12 2016
@@ -0,0 +1,24 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device 
-verify %s
+
+#include "Inputs/cuda.h"
+
+__host__ void overload() {}
+__device__ void overload() {}
+
+__host__ __device__ void test_hd() {
+  // This should not be ambiguous -- we choose the host or the device overload
+  // depending on whether or not we're compiling for host or device.
+  void (*x)() = overload;
+}
+
+// These also shouldn't be ambiguous, but they're an easier test than the HD
+// function above.
+__host__ void test_host() {
+  void (*x)() = overload;
+}
+__device__ void test_device() {
+  void (*x)() = overload;
+}

Added: cfe/trunk/test/SemaCUDA/overloaded-delete.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCUDA/overloaded-delete.cu?rev=275232&view=auto
==
--- cfe/trunk/test/SemaCUDA/overloaded-delete.cu (added)
+++ cfe/trunk/test/SemaCUDA/overloaded-delete.cu Tue Jul 12 18:23:12 2016
@@ -0,0 +1,25 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device 
-verify %s
+
+#include "Inputs/cuda.h"
+
+struct S {
+  __host__ static void operator delete(void*, size_t) {}
+  __device__ static void operator delete(void*, size_t) {}
+};
+
+__host__ __device__ void test(S* s) {
+  // This shouldn't be ambiguous -- we call the host overload in host mode and
+  // the device overload in device mode.
+  delete s;
+}
+
+__host__ void operator delete(void *ptr) {}
+__device__ void operator delete(void *ptr) {}
+
+__host__ __device__ void test_global_delete(int *ptr) {
+  // Again, there should be no ambiguity between which operator delete we call.
+  ::delete ptr;
+}


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

Re: [PATCH] D21912: [CUDA] Don't assume that destructors can't be overloaded.

2016-07-12 Thread Justin Lebar via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL275231: [CUDA] Don't assume that destructors can't be 
overloaded. (authored by jlebar).

Changed prior to commit:
  http://reviews.llvm.org/D21912?vs=62444&id=63749#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21912

Files:
  cfe/trunk/lib/Sema/SemaOverload.cpp
  cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu

Index: cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu
===
--- cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu
+++ cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu
@@ -0,0 +1,17 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device 
-verify %s
+
+#include "Inputs/cuda.h"
+
+struct S {
+  __host__ ~S() {}
+  __device__ ~S() {}
+};
+
+__host__ __device__ void test() {
+  S s;
+  // This should not crash clang.
+  s.~S();
+}
Index: cfe/trunk/lib/Sema/SemaOverload.cpp
===
--- cfe/trunk/lib/Sema/SemaOverload.cpp
+++ cfe/trunk/lib/Sema/SemaOverload.cpp
@@ -12407,8 +12407,7 @@
   if (CXXDestructorDecl *DD =
   dyn_cast(TheCall->getMethodDecl())) {
 // a->A::f() doesn't go through the vtable, except in AppleKext mode.
-bool CallCanBeVirtual = !cast(NakedMemExpr)->hasQualifier() ||
-getLangOpts().AppleKext;
+bool CallCanBeVirtual = !MemExpr->hasQualifier() || 
getLangOpts().AppleKext;
 CheckVirtualDtorCall(DD, MemExpr->getLocStart(), /*IsDelete=*/false,
  CallCanBeVirtual, /*WarnOnNonAbstractTypes=*/true,
  MemExpr->getMemberLoc());


Index: cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu
===
--- cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu
+++ cfe/trunk/test/SemaCUDA/call-overloaded-destructor.cu
@@ -0,0 +1,17 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device -verify %s
+
+#include "Inputs/cuda.h"
+
+struct S {
+  __host__ ~S() {}
+  __device__ ~S() {}
+};
+
+__host__ __device__ void test() {
+  S s;
+  // This should not crash clang.
+  s.~S();
+}
Index: cfe/trunk/lib/Sema/SemaOverload.cpp
===
--- cfe/trunk/lib/Sema/SemaOverload.cpp
+++ cfe/trunk/lib/Sema/SemaOverload.cpp
@@ -12407,8 +12407,7 @@
   if (CXXDestructorDecl *DD =
   dyn_cast(TheCall->getMethodDecl())) {
 // a->A::f() doesn't go through the vtable, except in AppleKext mode.
-bool CallCanBeVirtual = !cast(NakedMemExpr)->hasQualifier() ||
-getLangOpts().AppleKext;
+bool CallCanBeVirtual = !MemExpr->hasQualifier() || getLangOpts().AppleKext;
 CheckVirtualDtorCall(DD, MemExpr->getLocStart(), /*IsDelete=*/false,
  CallCanBeVirtual, /*WarnOnNonAbstractTypes=*/true,
  MemExpr->getMemberLoc());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D21914: [CUDA] Use the multi-element remove function in EraseUnwantedCUDAMatches.

2016-07-12 Thread Justin Lebar via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL275233: [CUDA] Use the multi-element remove function in 
EraseUnwantedCUDAMatches. (authored by jlebar).

Changed prior to commit:
  http://reviews.llvm.org/D21914?vs=62446&id=63751#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21914

Files:
  cfe/trunk/lib/Sema/SemaCUDA.cpp

Index: cfe/trunk/lib/Sema/SemaCUDA.cpp
===
--- cfe/trunk/lib/Sema/SemaCUDA.cpp
+++ cfe/trunk/lib/Sema/SemaCUDA.cpp
@@ -163,8 +163,10 @@
   [&](const T &M1, const T &M2) { return GetCFP(M1) < GetCFP(M2); }));
 
   // Erase all functions with lower priority.
-  Matches.erase(llvm::remove_if(
-  Matches, [&](const T &Match) { return GetCFP(Match) < BestCFP; }));
+  Matches.erase(
+  llvm::remove_if(Matches,
+  [&](const T &Match) { return GetCFP(Match) < BestCFP; }),
+  Matches.end());
 }
 
 void Sema::EraseUnwantedCUDAMatches(const FunctionDecl *Caller,


Index: cfe/trunk/lib/Sema/SemaCUDA.cpp
===
--- cfe/trunk/lib/Sema/SemaCUDA.cpp
+++ cfe/trunk/lib/Sema/SemaCUDA.cpp
@@ -163,8 +163,10 @@
   [&](const T &M1, const T &M2) { return GetCFP(M1) < GetCFP(M2); }));
 
   // Erase all functions with lower priority.
-  Matches.erase(llvm::remove_if(
-  Matches, [&](const T &Match) { return GetCFP(Match) < BestCFP; }));
+  Matches.erase(
+  llvm::remove_if(Matches,
+  [&](const T &Match) { return GetCFP(Match) < BestCFP; }),
+  Matches.end());
 }
 
 void Sema::EraseUnwantedCUDAMatches(const FunctionDecl *Caller,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r275233 - [CUDA] Use the multi-element remove function in EraseUnwantedCUDAMatches.

2016-07-12 Thread Justin Lebar via cfe-commits

Author: jlebar
Date: Tue Jul 12 18:23:13 2016
New Revision: 275233

URL: http://llvm.org/viewvc/llvm-project?rev=275233&view=rev
Log:
[CUDA] Use the multi-element remove function in EraseUnwantedCUDAMatches.

Summary:
Bug pointed out by Benjamin Kramer in r264008.  I think the bug is
benign because by the time this is called, we should only have at most
two overloads to consider (either a host and a device overload, or a
host+device overload, but not all three).

Reviewers: tra

Subscribers: cfe-commits, bkramer

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

Modified:
cfe/trunk/lib/Sema/SemaCUDA.cpp

Modified: cfe/trunk/lib/Sema/SemaCUDA.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCUDA.cpp?rev=275233&r1=275232&r2=275233&view=diff
==
--- cfe/trunk/lib/Sema/SemaCUDA.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCUDA.cpp Tue Jul 12 18:23:13 2016
@@ -163,8 +163,10 @@ static void EraseUnwantedCUDAMatchesImpl
   [&](const T &M1, const T &M2) { return GetCFP(M1) < GetCFP(M2); }));
 
   // Erase all functions with lower priority.
-  Matches.erase(llvm::remove_if(
-  Matches, [&](const T &Match) { return GetCFP(Match) < BestCFP; }));
+  Matches.erase(
+  llvm::remove_if(Matches,
+  [&](const T &Match) { return GetCFP(Match) < BestCFP; }),
+  Matches.end());
 }
 
 void Sema::EraseUnwantedCUDAMatches(const FunctionDecl *Caller,


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

Re: [PATCH] D21913: [CUDA] Add additional testcases for EraseUnwantedCUDAMatches.

2016-07-12 Thread Justin Lebar via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL275232: [CUDA] Add additional testcases for 
EraseUnwantedCUDAMatches. (authored by jlebar).

Changed prior to commit:
  http://reviews.llvm.org/D21913?vs=62445&id=63750#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21913

Files:
  cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu
  cfe/trunk/test/SemaCUDA/overloaded-delete.cu

Index: cfe/trunk/test/SemaCUDA/overloaded-delete.cu
===
--- cfe/trunk/test/SemaCUDA/overloaded-delete.cu
+++ cfe/trunk/test/SemaCUDA/overloaded-delete.cu
@@ -0,0 +1,25 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device 
-verify %s
+
+#include "Inputs/cuda.h"
+
+struct S {
+  __host__ static void operator delete(void*, size_t) {}
+  __device__ static void operator delete(void*, size_t) {}
+};
+
+__host__ __device__ void test(S* s) {
+  // This shouldn't be ambiguous -- we call the host overload in host mode and
+  // the device overload in device mode.
+  delete s;
+}
+
+__host__ void operator delete(void *ptr) {}
+__device__ void operator delete(void *ptr) {}
+
+__host__ __device__ void test_global_delete(int *ptr) {
+  // Again, there should be no ambiguity between which operator delete we call.
+  ::delete ptr;
+}
Index: cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu
===
--- cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu
+++ cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu
@@ -0,0 +1,24 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device 
-verify %s
+
+#include "Inputs/cuda.h"
+
+__host__ void overload() {}
+__device__ void overload() {}
+
+__host__ __device__ void test_hd() {
+  // This should not be ambiguous -- we choose the host or the device overload
+  // depending on whether or not we're compiling for host or device.
+  void (*x)() = overload;
+}
+
+// These also shouldn't be ambiguous, but they're an easier test than the HD
+// function above.
+__host__ void test_host() {
+  void (*x)() = overload;
+}
+__device__ void test_device() {
+  void (*x)() = overload;
+}


Index: cfe/trunk/test/SemaCUDA/overloaded-delete.cu
===
--- cfe/trunk/test/SemaCUDA/overloaded-delete.cu
+++ cfe/trunk/test/SemaCUDA/overloaded-delete.cu
@@ -0,0 +1,25 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device -verify %s
+
+#include "Inputs/cuda.h"
+
+struct S {
+  __host__ static void operator delete(void*, size_t) {}
+  __device__ static void operator delete(void*, size_t) {}
+};
+
+__host__ __device__ void test(S* s) {
+  // This shouldn't be ambiguous -- we call the host overload in host mode and
+  // the device overload in device mode.
+  delete s;
+}
+
+__host__ void operator delete(void *ptr) {}
+__device__ void operator delete(void *ptr) {}
+
+__host__ __device__ void test_global_delete(int *ptr) {
+  // Again, there should be no ambiguity between which operator delete we call.
+  ::delete ptr;
+}
Index: cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu
===
--- cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu
+++ cfe/trunk/test/SemaCUDA/addr-of-overloaded-fn.cu
@@ -0,0 +1,24 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device -verify %s
+
+#include "Inputs/cuda.h"
+
+__host__ void overload() {}
+__device__ void overload() {}
+
+__host__ __device__ void test_hd() {
+  // This should not be ambiguous -- we choose the host or the device overload
+  // depending on whether or not we're compiling for host or device.
+  void (*x)() = overload;
+}
+
+// These also shouldn't be ambiguous, but they're an easier test than the HD
+// function above.
+__host__ void test_host() {
+  void (*x)() = overload;
+}
+__device__ void test_device() {
+  void (*x)() = overload;
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22272: ARM: define __ARM_VFPV5__ when present.

2016-07-12 Thread Renato Golin via cfe-commits

rengolin added a reviewer: kristof.beyls.
rengolin added a comment.

I don't mind either way, but would be good to be compatible with gcc in that 
respect. Least surprise and all.

ARM was naming it fpv8 for the command line options and other things, might 
also be good to keep the consistency.

Would it be too bad to have both?


http://reviews.llvm.org/D22272



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

[PATCH] D22289: [PATCH 1/2] [Driver] Make Driver::DefaultTargetTriple private (NFCI)

2016-07-12 Thread Vedant Kumar via cfe-commits

vsk created this revision.
vsk added a reviewer: dexonsmith.
vsk added a subscriber: cfe-commits.

The clang driver knows about two kinds of target triples: default and
effective. Default triples are needed to get ToolChains. ToolChains can
then be used to determine more specific effective triples.

Inconsistent use of two different kinds of target triples leads to
inconsistent error reporting and wasted computation (n.b that effective
triples are not cached).

Ideally, default triples would only be used as a means of getting
effective triples. Make Driver::DefaultTargetTriple private in the hopes
of discouraging further use of default triples.

http://reviews.llvm.org/D22289

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

Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -55,12 +55,12 @@
   Mode(GCCMode), SaveTemps(SaveTempsNone), BitcodeEmbed(EmbedNone),
   LTOMode(LTOK_None), ClangExecutable(ClangExecutable),
   SysRoot(DEFAULT_SYSROOT), UseStdLib(true),
-  DefaultTargetTriple(DefaultTargetTriple),
   DriverTitle("clang LLVM compiler"), CCPrintOptionsFilename(nullptr),
   CCPrintHeadersFilename(nullptr), CCLogDiagnosticsFilename(nullptr),
   CCCPrintBindings(false), CCPrintHeaders(false), CCLogDiagnostics(false),
-  CCGenDiagnostics(false), CCCGenericGCCName(""), CheckInputsExist(true),
-  CCCUsePCH(true), SuppressMissingInputWarning(false) {
+  CCGenDiagnostics(false), DefaultTargetTriple(DefaultTargetTriple),
+  CCCGenericGCCName(""), CheckInputsExist(true), CCCUsePCH(true),
+  SuppressMissingInputWarning(false) {
 
   // Provide a sane fallback if no VFS is specified.
   if (!this->VFS)
Index: include/clang/Driver/Driver.h
===
--- include/clang/Driver/Driver.h
+++ include/clang/Driver/Driver.h
@@ -132,9 +132,6 @@
   /// If the standard library is used
   bool UseStdLib;
 
-  /// Default target triple.
-  std::string DefaultTargetTriple;
-
   /// Driver title to use with help.
   std::string DriverTitle;
 
@@ -183,6 +180,9 @@
   unsigned CCGenDiagnostics : 1;
 
 private:
+  /// Default target triple.
+  std::string DefaultTargetTriple;
+
   /// Name to use when invoking gcc/g++.
   std::string CCCGenericGCCName;
 


Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -55,12 +55,12 @@
   Mode(GCCMode), SaveTemps(SaveTempsNone), BitcodeEmbed(EmbedNone),
   LTOMode(LTOK_None), ClangExecutable(ClangExecutable),
   SysRoot(DEFAULT_SYSROOT), UseStdLib(true),
-  DefaultTargetTriple(DefaultTargetTriple),
   DriverTitle("clang LLVM compiler"), CCPrintOptionsFilename(nullptr),
   CCPrintHeadersFilename(nullptr), CCLogDiagnosticsFilename(nullptr),
   CCCPrintBindings(false), CCPrintHeaders(false), CCLogDiagnostics(false),
-  CCGenDiagnostics(false), CCCGenericGCCName(""), CheckInputsExist(true),
-  CCCUsePCH(true), SuppressMissingInputWarning(false) {
+  CCGenDiagnostics(false), DefaultTargetTriple(DefaultTargetTriple),
+  CCCGenericGCCName(""), CheckInputsExist(true), CCCUsePCH(true),
+  SuppressMissingInputWarning(false) {
 
   // Provide a sane fallback if no VFS is specified.
   if (!this->VFS)
Index: include/clang/Driver/Driver.h
===
--- include/clang/Driver/Driver.h
+++ include/clang/Driver/Driver.h
@@ -132,9 +132,6 @@
   /// If the standard library is used
   bool UseStdLib;
 
-  /// Default target triple.
-  std::string DefaultTargetTriple;
-
   /// Driver title to use with help.
   std::string DriverTitle;
 
@@ -183,6 +180,9 @@
   unsigned CCGenDiagnostics : 1;
 
 private:
+  /// Default target triple.
+  std::string DefaultTargetTriple;
+
   /// Name to use when invoking gcc/g++.
   std::string CCCGenericGCCName;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

2016-07-12 Thread Vedant Kumar via cfe-commits

vsk created this revision.
vsk added a reviewer: dexonsmith.
vsk added a subscriber: cfe-commits.
Herald added subscribers: srhines, danalbert, tberghammer, aemerson.

Compute an effective target triple exactly once in ConstructJob(), and
then simply pass around const references to it. This eliminates wasteful
re-computation of effective triples (e.g in getARMFloatABI()).

http://reviews.llvm.org/D22290

Files:
  include/clang/Driver/SanitizerArgs.h
  include/clang/Driver/Tool.h
  include/clang/Driver/ToolChain.h
  lib/Driver/Driver.cpp
  lib/Driver/SanitizerArgs.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h

Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -60,7 +60,8 @@
const InputInfoList &Inputs,
const ToolChain *AuxToolChain) const;
 
-  void AddAArch64TargetArgs(const llvm::opt::ArgList &Args,
+  void AddAArch64TargetArgs(const llvm::Triple &EffectiveTriple,
+const llvm::opt::ArgList &Args,
 llvm::opt::ArgStringList &CmdArgs) const;
   void AddARMTargetArgs(const llvm::Triple &Triple,
 const llvm::opt::ArgList &Args,
@@ -115,6 +116,7 @@
 
   void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const override;
 };
@@ -132,6 +134,7 @@
 
   void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const override;
 };
@@ -159,6 +162,7 @@
   bool hasIntegratedAssembler() const override { return true; }
   void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const override;
 
@@ -218,6 +222,7 @@
llvm::opt::ArgStringList &CmdArgs) const;
   void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const override;
 };
@@ -233,6 +238,7 @@
llvm::opt::ArgStringList &CmdArgs) const;
   void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const override;
 };
@@ -247,6 +253,7 @@
   bool hasIntegratedCPP() const override { return false; }
   void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const override;
 };
@@ -262,6 +269,7 @@
   bool hasIntegratedCPP() const override;
   void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const override;
 };
@@ -323,6 +331,7 @@
 
   void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const override;
 };
@@ -362,6 +371,7 @@
 
   void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const override;
 };
@@ -382,6 +392,7 @@
 
   void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOut

[PATCH] D22292: [libunwind] Fix unw_getcontext for ARMv6-m

2016-07-12 Thread Weiming Zhao via cfe-commits

weimingz created this revision.
weimingz added reviewers: rengolin, rmaprath.
weimingz added a subscriber: cfe-commits.
Herald added subscribers: rengolin, aemerson.

ARMv6-m requires the writeback suffix for stm. 

http://reviews.llvm.org/D22292

Files:
  src/UnwindRegistersSave.S

Index: src/UnwindRegistersSave.S
===
--- src/UnwindRegistersSave.S
+++ src/UnwindRegistersSave.S
@@ -310,7 +310,8 @@
   .p2align 2
 DEFINE_LIBUNWIND_FUNCTION(unw_getcontext)
 #if !defined(__ARM_ARCH_ISA_ARM)
-  stm r0, {r0-r7}
+  stm r0!, {r0-r7}
+  subs r0, r0, #32
   mov r2, sp
   mov r3, lr
   str r2, [r0, #52]


Index: src/UnwindRegistersSave.S
===
--- src/UnwindRegistersSave.S
+++ src/UnwindRegistersSave.S
@@ -310,7 +310,8 @@
   .p2align 2
 DEFINE_LIBUNWIND_FUNCTION(unw_getcontext)
 #if !defined(__ARM_ARCH_ISA_ARM)
-  stm r0, {r0-r7}
+  stm r0!, {r0-r7}
+  subs r0, r0, #32
   mov r2, sp
   mov r3, lr
   str r2, [r0, #52]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

2016-07-12 Thread Duncan P. N. Exon Smith via cfe-commits


> On 2016-Jul-12, at 16:53, Vedant Kumar  wrote:
> 
> vsk created this revision.
> vsk added a reviewer: dexonsmith.
> vsk added a subscriber: cfe-commits.
> Herald added subscribers: srhines, danalbert, tberghammer, aemerson.
> 
> Compute an effective target triple exactly once in ConstructJob(), and
> then simply pass around const references to it. This eliminates wasteful
> re-computation of effective triples (e.g in getARMFloatABI()).
> 
> http://reviews.llvm.org/D22290
> 
> Files:
>  include/clang/Driver/SanitizerArgs.h
>  include/clang/Driver/Tool.h
>  include/clang/Driver/ToolChain.h
>  lib/Driver/Driver.cpp
>  lib/Driver/SanitizerArgs.cpp
>  lib/Driver/ToolChain.cpp
>  lib/Driver/ToolChains.cpp
>  lib/Driver/ToolChains.h
>  lib/Driver/Tools.cpp
>  lib/Driver/Tools.h
> 
> 

> Index: lib/Driver/Driver.cpp
> ===
> --- lib/Driver/Driver.cpp
> +++ lib/Driver/Driver.cpp
> @@ -2112,7 +2112,21 @@
>   AtTopLevel, MultipleArchs),
> BaseInput);
>  
> +  llvm::Triple EffectiveTriple;
> +  const ArgList &Args = C.getArgsForToolChain(TC, BoundArch);
> +  if (InputInfos.size() != 1) {
> +EffectiveTriple = llvm::Triple(
> +T->getToolChain().ComputeEffectiveClangTriple(Args));
> +  } else {
> +// Pass along the input type if it can be unambiguously determined.
> +EffectiveTriple =
> +llvm::Triple(T->getToolChain().ComputeEffectiveClangTriple(
> +Args, InputInfos[0].getType()));
> +  }
> +
>if (CCCPrintBindings && !CCGenDiagnostics) {
> +// FIXME: We should be able to use the effective triple here, but doing 
> so
> +// breaks some multi-arch tests.

This is interesting.  Why does it break the tests?

>  llvm::errs() << "# \"" << T->getToolChain().getTripleString() << '"'
>   << " - \"" << T->getName() << "\", inputs: [";
>  for (unsigned i = 0, e = InputInfos.size(); i != e; ++i) {
> @@ -2122,7 +2136,7 @@
>  }
>  llvm::errs() << "], output: " << Result.getAsString() << "\n";
>} else {
> -T->ConstructJob(C, *JA, Result, InputInfos,
> +T->ConstructJob(C, *JA, Result, InputInfos, EffectiveTriple,
>  C.getArgsForToolChain(TC, BoundArch), LinkingOutput);

Why doesn't this have the same problem as above?  I.e., what happens for
multi-arch cases?

>}
>return Result;
> 

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

Re: [PATCH] D22289: [PATCH 1/2] [Driver] Make Driver::DefaultTargetTriple private (NFCI)

2016-07-12 Thread Duncan P. N. Exon Smith via cfe-commits

If no one is using it, making it private is obvious goodness.  LGTM.

> On 2016-Jul-12, at 16:52, Vedant Kumar  wrote:
> 
> vsk created this revision.
> vsk added a reviewer: dexonsmith.
> vsk added a subscriber: cfe-commits.
> 
> The clang driver knows about two kinds of target triples: default and
> effective. Default triples are needed to get ToolChains. ToolChains can
> then be used to determine more specific effective triples.
> 
> Inconsistent use of two different kinds of target triples leads to
> inconsistent error reporting and wasted computation (n.b that effective
> triples are not cached).
> 
> Ideally, default triples would only be used as a means of getting
> effective triples. Make Driver::DefaultTargetTriple private in the hopes
> of discouraging further use of default triples.
> 
> http://reviews.llvm.org/D22289
> 
> Files:
>  include/clang/Driver/Driver.h
>  lib/Driver/Driver.cpp
> 
> Index: lib/Driver/Driver.cpp
> ===
> --- lib/Driver/Driver.cpp
> +++ lib/Driver/Driver.cpp
> @@ -55,12 +55,12 @@
>   Mode(GCCMode), SaveTemps(SaveTempsNone), BitcodeEmbed(EmbedNone),
>   LTOMode(LTOK_None), ClangExecutable(ClangExecutable),
>   SysRoot(DEFAULT_SYSROOT), UseStdLib(true),
> -  DefaultTargetTriple(DefaultTargetTriple),
>   DriverTitle("clang LLVM compiler"), CCPrintOptionsFilename(nullptr),
>   CCPrintHeadersFilename(nullptr), CCLogDiagnosticsFilename(nullptr),
>   CCCPrintBindings(false), CCPrintHeaders(false), CCLogDiagnostics(false),
> -  CCGenDiagnostics(false), CCCGenericGCCName(""), CheckInputsExist(true),
> -  CCCUsePCH(true), SuppressMissingInputWarning(false) {
> +  CCGenDiagnostics(false), DefaultTargetTriple(DefaultTargetTriple),
> +  CCCGenericGCCName(""), CheckInputsExist(true), CCCUsePCH(true),
> +  SuppressMissingInputWarning(false) {
> 
>   // Provide a sane fallback if no VFS is specified.
>   if (!this->VFS)
> Index: include/clang/Driver/Driver.h
> ===
> --- include/clang/Driver/Driver.h
> +++ include/clang/Driver/Driver.h
> @@ -132,9 +132,6 @@
>   /// If the standard library is used
>   bool UseStdLib;
> 
> -  /// Default target triple.
> -  std::string DefaultTargetTriple;
> -
>   /// Driver title to use with help.
>   std::string DriverTitle;
> 
> @@ -183,6 +180,9 @@
>   unsigned CCGenDiagnostics : 1;
> 
> private:
> +  /// Default target triple.
> +  std::string DefaultTargetTriple;
> +
>   /// Name to use when invoking gcc/g++.
>   std::string CCCGenericGCCName;
> 
> 
> 
> 

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

Re: [PATCH] D22289: [PATCH 1/2] [Driver] Make Driver::DefaultTargetTriple private (NFCI)

2016-07-12 Thread Duncan P. N. Exon Smith via cfe-commits

dexonsmith added a subscriber: dexonsmith.
dexonsmith added a comment.

If no one is using it, making it private is obvious goodness.  LGTM.


http://reviews.llvm.org/D22289



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

Re: [PATCH] D20867: [PCH] Fix timestamp check on windows hosts.

2016-07-12 Thread Richard Smith via cfe-commits

rsmith added a comment.

You have two independent functional changes in this patch: one adds a flag to 
control the emission of timestamps into PCH files, and the other re-enables 
timestamp checking on Win32. Please separate them out into distinct patches to 
be committed separately.

Both parts of this LGTM.


http://reviews.llvm.org/D20867



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

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

2016-07-12 Thread Vedant Kumar via cfe-commits


> On Jul 12, 2016, at 5:41 PM, Duncan P. N. Exon Smith  
> wrote:
> 
> 
>> On 2016-Jul-12, at 16:53, Vedant Kumar  wrote:
>> 
>> vsk created this revision.
>> vsk added a reviewer: dexonsmith.
>> vsk added a subscriber: cfe-commits.
>> Herald added subscribers: srhines, danalbert, tberghammer, aemerson.
>> 
>> Compute an effective target triple exactly once in ConstructJob(), and
>> then simply pass around const references to it. This eliminates wasteful
>> re-computation of effective triples (e.g in getARMFloatABI()).
>> 
>> http://reviews.llvm.org/D22290
>> 
>> Files:
>> include/clang/Driver/SanitizerArgs.h
>> include/clang/Driver/Tool.h
>> include/clang/Driver/ToolChain.h
>> lib/Driver/Driver.cpp
>> lib/Driver/SanitizerArgs.cpp
>> lib/Driver/ToolChain.cpp
>> lib/Driver/ToolChains.cpp
>> lib/Driver/ToolChains.h
>> lib/Driver/Tools.cpp
>> lib/Driver/Tools.h
>> 
>> 
> 
>> Index: lib/Driver/Driver.cpp
>> ===
>> --- lib/Driver/Driver.cpp
>> +++ lib/Driver/Driver.cpp
>> @@ -2112,7 +2112,21 @@
>>  AtTopLevel, MultipleArchs),
>>BaseInput);
>> 
>> +  llvm::Triple EffectiveTriple;
>> +  const ArgList &Args = C.getArgsForToolChain(TC, BoundArch);
>> +  if (InputInfos.size() != 1) {
>> +EffectiveTriple = llvm::Triple(
>> +T->getToolChain().ComputeEffectiveClangTriple(Args));
>> +  } else {
>> +// Pass along the input type if it can be unambiguously determined.
>> +EffectiveTriple =
>> +llvm::Triple(T->getToolChain().ComputeEffectiveClangTriple(
>> +Args, InputInfos[0].getType()));
>> +  }
>> +
>>   if (CCCPrintBindings && !CCGenDiagnostics) {
>> +// FIXME: We should be able to use the effective triple here, but doing 
>> so
>> +// breaks some multi-arch tests.
> 
> This is interesting.  Why does it break the tests?

It breaks these two tests:

  test/Driver/darwin-dsymutil.c
  test/Driver/darwin-debug-version.c

The tests expect "-ccc-print-bindings" to spit out a default triple, namely:

  x86_64-apple-darwin10

Printing out the effective triple means we get this instead:

  x86_64-apple-macosx10.6.0

There's some chance that the test is too strict. I'm planning on keeping this
patch NFCI and following up with the test authors later.

thanks,
vedant

> 
>> llvm::errs() << "# \"" << T->getToolChain().getTripleString() << '"'
>>  << " - \"" << T->getName() << "\", inputs: [";
>> for (unsigned i = 0, e = InputInfos.size(); i != e; ++i) {
>> @@ -2122,7 +2136,7 @@
>> }
>> llvm::errs() << "], output: " << Result.getAsString() << "\n";
>>   } else {
>> -T->ConstructJob(C, *JA, Result, InputInfos,
>> +T->ConstructJob(C, *JA, Result, InputInfos, EffectiveTriple,
>> C.getArgsForToolChain(TC, BoundArch), LinkingOutput);
> 
> Why doesn't this have the same problem as above?  I.e., what happens for
> multi-arch cases?

Methods which override ConstructJob used to call ComputeEffectiveClangTriple
themselves, so they "expect" effective triples.

> 
>>   }
>>   return Result;
>> 
> 

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

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

2016-07-12 Thread Vedant Kumar via cfe-commits


> On Jul 12, 2016, at 5:47 PM, Vedant Kumar via cfe-commits 
>  wrote:
> 
>> 
>> On Jul 12, 2016, at 5:41 PM, Duncan P. N. Exon Smith  
>> wrote:
>> 
>> 
>>> On 2016-Jul-12, at 16:53, Vedant Kumar  wrote:
>>> 
>>> vsk created this revision.
>>> vsk added a reviewer: dexonsmith.
>>> vsk added a subscriber: cfe-commits.
>>> Herald added subscribers: srhines, danalbert, tberghammer, aemerson.
>>> 
>>> Compute an effective target triple exactly once in ConstructJob(), and
>>> then simply pass around const references to it. This eliminates wasteful
>>> re-computation of effective triples (e.g in getARMFloatABI()).
>>> 
>>> http://reviews.llvm.org/D22290
>>> 
>>> Files:
>>> include/clang/Driver/SanitizerArgs.h
>>> include/clang/Driver/Tool.h
>>> include/clang/Driver/ToolChain.h
>>> lib/Driver/Driver.cpp
>>> lib/Driver/SanitizerArgs.cpp
>>> lib/Driver/ToolChain.cpp
>>> lib/Driver/ToolChains.cpp
>>> lib/Driver/ToolChains.h
>>> lib/Driver/Tools.cpp
>>> lib/Driver/Tools.h
>>> 
>>> 
>> 
>>> Index: lib/Driver/Driver.cpp
>>> ===
>>> --- lib/Driver/Driver.cpp
>>> +++ lib/Driver/Driver.cpp
>>> @@ -2112,7 +2112,21 @@
>>> AtTopLevel, MultipleArchs),
>>>   BaseInput);
>>> 
>>> +  llvm::Triple EffectiveTriple;
>>> +  const ArgList &Args = C.getArgsForToolChain(TC, BoundArch);
>>> +  if (InputInfos.size() != 1) {
>>> +EffectiveTriple = llvm::Triple(
>>> +T->getToolChain().ComputeEffectiveClangTriple(Args));
>>> +  } else {
>>> +// Pass along the input type if it can be unambiguously determined.
>>> +EffectiveTriple =
>>> +llvm::Triple(T->getToolChain().ComputeEffectiveClangTriple(
>>> +Args, InputInfos[0].getType()));
>>> +  }
>>> +
>>>  if (CCCPrintBindings && !CCGenDiagnostics) {
>>> +// FIXME: We should be able to use the effective triple here, but 
>>> doing so
>>> +// breaks some multi-arch tests.
>> 
>> This is interesting.  Why does it break the tests?
> 
> It breaks these two tests:
> 
>  test/Driver/darwin-dsymutil.c
>  test/Driver/darwin-debug-version.c
> 
> The tests expect "-ccc-print-bindings" to spit out a default triple, namely:
> 
>  x86_64-apple-darwin10
> 
> Printing out the effective triple means we get this instead:
> 
>  x86_64-apple-macosx10.6.0
> 
> There's some chance that the test is too strict. I'm planning on keeping this
> patch NFCI and following up with the test authors later.
> 
> thanks,
> vedant
> 
>> 
>>>llvm::errs() << "# \"" << T->getToolChain().getTripleString() << '"'
>>> << " - \"" << T->getName() << "\", inputs: [";
>>>for (unsigned i = 0, e = InputInfos.size(); i != e; ++i) {
>>> @@ -2122,7 +2136,7 @@
>>>}
>>>llvm::errs() << "], output: " << Result.getAsString() << "\n";
>>>  } else {
>>> -T->ConstructJob(C, *JA, Result, InputInfos,
>>> +T->ConstructJob(C, *JA, Result, InputInfos, EffectiveTriple,
>>>C.getArgsForToolChain(TC, BoundArch), LinkingOutput);
>> 
>> Why doesn't this have the same problem as above?  I.e., what happens for
>> multi-arch cases?
> 
> Methods which override ConstructJob used to call ComputeEffectiveClangTriple
> themselves, so they "expect" effective triples.

^ Er, I meant: methods which override or are called by ConstructJob() expect
effective triples.

This patch consolidates all calls to ComputeEffectiveClangTriple() into this
one site.

vedant

> 
>> 
>>>  }
>>>  return Result;
>>> 
>> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[PATCH] D22293: Fix MSVC mangling of consecutive pack template arguments

2016-07-12 Thread Dave Bartolomeo via cfe-commits

DaveBartolomeo created this revision.
DaveBartolomeo added reviewers: rnk, majnemer, cfe-commits.

When mangling a template specialization where two consecutive template 
arguments are both packs, MSVC inserts the separator "$$Z" between the two 
arguments to disambiguate between the case of { { int, int }, { int } } and { { 
int }, { int, int } }. I've updated Clang's MSVC mangler to do the same, and 
added a test case to check that the separator is inserted correctly.


http://reviews.llvm.org/D22293

Files:
  lib/AST/MicrosoftMangle.cpp
  test/CodeGenCXX/mangle-ms-cxx11.cpp

Index: test/CodeGenCXX/mangle-ms-cxx11.cpp
===
--- test/CodeGenCXX/mangle-ms-cxx11.cpp
+++ test/CodeGenCXX/mangle-ms-cxx11.cpp
@@ -318,3 +318,16 @@
 
 // CHECK-DAG: @"\01?unaligned_foo8@unaligned_foo8_S@@QFCEXXZ"
 
+template
+struct my_tuple {};
+
+template
+void print_tuples(const my_tuple& a, const my_tuple& b);
+
+void f() {
+  print_tuples(my_tuple(), my_tuple());
+  print_tuples(my_tuple(), my_tuple());
+}
+
+// CHECK-DAG: 
@"\01??$print_tuples@H$$ZHH@@YAXABU?$my_tuple@H@@ABU?$my_tuple@HH@@@Z"
+// CHECK-DAG: 
@"\01??$print_tuples@HH$$ZH@@YAXABU?$my_tuple@HH@@ABU?$my_tuple@H@@@Z"
Index: lib/AST/MicrosoftMangle.cpp
===
--- lib/AST/MicrosoftMangle.cpp
+++ lib/AST/MicrosoftMangle.cpp
@@ -357,7 +357,7 @@
   void mangleTemplateArgs(const TemplateDecl *TD,
   const TemplateArgumentList &TemplateArgs);
   void mangleTemplateArg(const TemplateDecl *TD, const TemplateArgument &TA,
- const NamedDecl *Parm);
+ const NamedDecl *Parm, bool &PrevArgWasPack);
 };
 }
 
@@ -1219,13 +1219,15 @@
  "size mismatch between args and parms!");
 
   unsigned Idx = 0;
+  bool PrevArgWasPack = false;
   for (const TemplateArgument &TA : TemplateArgs.asArray())
-mangleTemplateArg(TD, TA, TPL->getParam(Idx++));
+mangleTemplateArg(TD, TA, TPL->getParam(Idx++), PrevArgWasPack);
 }
 
 void MicrosoftCXXNameMangler::mangleTemplateArg(const TemplateDecl *TD,
 const TemplateArgument &TA,
-const NamedDecl *Parm) {
+const NamedDecl *Parm,
+bool &PrevArgWasPack) {
   //  ::= 
   //::= 
   //::= 
@@ -1235,6 +1237,9 @@
   //::= $0A@
   //::= 
 
+  bool NeedsSeparatorBeforePack = PrevArgWasPack;
+  PrevArgWasPack = false;
+
   switch (TA.getKind()) {
   case TemplateArgument::Null:
 llvm_unreachable("Can't mangle null template arguments!");
@@ -1302,6 +1307,14 @@
 mangleExpression(TA.getAsExpr());
 break;
   case TemplateArgument::Pack: {
+PrevArgWasPack = true;
+if (NeedsSeparatorBeforePack) {
+  // If two consecutive template args are packs, we need to distinguish
+  // between {{int}, {int, int}} and {{int, int}, {int}}. We emit a
+  // separator ("$$Z") between the two packs to mark where one pack ends
+  // and the next begins.
+  Out << "$$Z";
+}
 ArrayRef TemplateArgs = TA.getPackAsArray();
 if (TemplateArgs.empty()) {
   if (isa(Parm) ||
@@ -1317,8 +1330,9 @@
   else
 llvm_unreachable("unexpected template parameter decl!");
 } else {
+  bool PrevArgInPackWasPack = false;
   for (const TemplateArgument &PA : TemplateArgs)
-mangleTemplateArg(TD, PA, Parm);
+mangleTemplateArg(TD, PA, Parm, PrevArgInPackWasPack);
 }
 break;
   }


Index: test/CodeGenCXX/mangle-ms-cxx11.cpp
===
--- test/CodeGenCXX/mangle-ms-cxx11.cpp
+++ test/CodeGenCXX/mangle-ms-cxx11.cpp
@@ -318,3 +318,16 @@
 
 // CHECK-DAG: @"\01?unaligned_foo8@unaligned_foo8_S@@QFCEXXZ"
 
+template
+struct my_tuple {};
+
+template
+void print_tuples(const my_tuple& a, const my_tuple& b);
+
+void f() {
+  print_tuples(my_tuple(), my_tuple());
+  print_tuples(my_tuple(), my_tuple());
+}
+
+// CHECK-DAG: @"\01??$print_tuples@H$$ZHH@@YAXABU?$my_tuple@H@@ABU?$my_tuple@HH@@@Z"
+// CHECK-DAG: @"\01??$print_tuples@HH$$ZH@@YAXABU?$my_tuple@HH@@ABU?$my_tuple@H@@@Z"
Index: lib/AST/MicrosoftMangle.cpp
===
--- lib/AST/MicrosoftMangle.cpp
+++ lib/AST/MicrosoftMangle.cpp
@@ -357,7 +357,7 @@
   void mangleTemplateArgs(const TemplateDecl *TD,
   const TemplateArgumentList &TemplateArgs);
   void mangleTemplateArg(const TemplateDecl *TD, const TemplateArgument &TA,
- const NamedDecl *Parm);
+ const NamedDecl *Parm, bool &PrevArgWasPack);
 };
 }
 
@@ -1219,13 +1219,15 @@
  "size mismatch between args and parms!");
 
   unsigned Idx = 0;
+  bool PrevArgWasPack = f

1 2 >

1 - 100 of 112 matches

Mail list logo