r274212 - [cmake] Remove stale comment. NFC.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Thu Jun 30 00:51:18 2016
New Revision: 274212

URL: http://llvm.org/viewvc/llvm-project?rev=274212=rev
Log:
[cmake] Remove stale comment. NFC.

Modified:
cfe/trunk/cmake/modules/ClangConfig.cmake.in

Modified: cfe/trunk/cmake/modules/ClangConfig.cmake.in
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/ClangConfig.cmake.in?rev=274212=274211=274212=diff
==
--- cfe/trunk/cmake/modules/ClangConfig.cmake.in (original)
+++ cfe/trunk/cmake/modules/ClangConfig.cmake.in Thu Jun 30 00:51:18 2016
@@ -1,9 +1,5 @@
 # This file allows users to call find_package(Clang) and pick up our targets.
 
-# Clang doesn't have any CMake configuration settings yet because it mostly
-# uses LLVM's. When it does, we should move this file to ClangConfig.cmake.in
-# and call configure_file() on it.
-
 find_package(LLVM REQUIRED CONFIG)
 
 @CLANG_CONFIG_CODE@


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


[libcxx] r274211 - Make futures.overview enum tests more portable. Patch from s...@microsoft.com

2016-06-29 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Thu Jun 30 00:00:32 2016
New Revision: 274211

URL: http://llvm.org/viewvc/llvm-project?rev=274211=rev
Log:
Make futures.overview enum tests more portable. Patch from s...@microsoft.com

Modified:
libcxx/trunk/test/std/thread/futures/futures.overview/future_errc.pass.cpp
libcxx/trunk/test/std/thread/futures/futures.overview/launch.pass.cpp

Modified: 
libcxx/trunk/test/std/thread/futures/futures.overview/future_errc.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/futures/futures.overview/future_errc.pass.cpp?rev=274211=274210=274211=diff
==
--- libcxx/trunk/test/std/thread/futures/futures.overview/future_errc.pass.cpp 
(original)
+++ libcxx/trunk/test/std/thread/futures/futures.overview/future_errc.pass.cpp 
Thu Jun 30 00:00:32 2016
@@ -13,18 +13,25 @@
 
 // enum class future_errc
 // {
-// future_already_retrieved = 1,
-// promise_already_satisfied,
-// no_state
-// broken_promise,
+// broken_promise = implementation-defined,
+// future_already_retrieved = implementation-defined,
+// promise_already_satisfied = implementation-defined,
+// no_state = implementation-defined
 // };
 
 #include 
 
 int main()
 {
-static_assert(static_cast(std::future_errc::future_already_retrieved) 
== 1, "");
-
static_assert(static_cast(std::future_errc::promise_already_satisfied) == 
2, "");
-static_assert(static_cast(std::future_errc::no_state) == 3, "");
-static_assert(static_cast(std::future_errc::broken_promise) == 4, "");
+static_assert(std::future_errc::broken_promise != 
std::future_errc::future_already_retrieved, "");
+static_assert(std::future_errc::broken_promise != 
std::future_errc::promise_already_satisfied, "");
+static_assert(std::future_errc::broken_promise != 
std::future_errc::no_state, "");
+static_assert(std::future_errc::future_already_retrieved != 
std::future_errc::promise_already_satisfied, "");
+static_assert(std::future_errc::future_already_retrieved != 
std::future_errc::no_state, "");
+static_assert(std::future_errc::promise_already_satisfied != 
std::future_errc::no_state, "");
+
+static_assert(std::future_errc::broken_promise != 
static_cast(0), "");
+static_assert(std::future_errc::future_already_retrieved != 
static_cast(0), "");
+static_assert(std::future_errc::promise_already_satisfied != 
static_cast(0), "");
+static_assert(std::future_errc::no_state != 
static_cast(0), "");
 }

Modified: libcxx/trunk/test/std/thread/futures/futures.overview/launch.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/futures/futures.overview/launch.pass.cpp?rev=274211=274210=274211=diff
==
--- libcxx/trunk/test/std/thread/futures/futures.overview/launch.pass.cpp 
(original)
+++ libcxx/trunk/test/std/thread/futures/futures.overview/launch.pass.cpp Thu 
Jun 30 00:00:32 2016
@@ -32,7 +32,7 @@ int main()
 LIBCPP_STATIC_ASSERT(std::launch::any == (std::launch::async | 
std::launch::deferred), "");
 static_assert(std::launch(0) == (std::launch::async & 
std::launch::deferred), "");
 LIBCPP_STATIC_ASSERT(std::launch::any == (std::launch::async ^ 
std::launch::deferred), "");
-static_assert(std::launch::deferred == ~std::launch::async, "");
+LIBCPP_STATIC_ASSERT(std::launch::deferred == ~std::launch::async, "");
 std::launch x = std::launch::async;
 x &= std::launch::deferred;
 assert(x == std::launch(0));


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


[libcxx] r274210 - Make std::array typedef tests more portable.

2016-06-29 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Wed Jun 29 23:54:00 2016
New Revision: 274210

URL: http://llvm.org/viewvc/llvm-project?rev=274210=rev
Log:
Make std::array typedef tests more portable.

Modified:
libcxx/trunk/test/std/containers/sequences/array/types.pass.cpp

Modified: libcxx/trunk/test/std/containers/sequences/array/types.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/array/types.pass.cpp?rev=274210=274209=274210=diff
==
--- libcxx/trunk/test/std/containers/sequences/array/types.pass.cpp (original)
+++ libcxx/trunk/test/std/containers/sequences/array/types.pass.cpp Wed Jun 29 
23:54:00 2016
@@ -29,6 +29,25 @@
 #include 
 #include 
 
+#include "test_macros.h"
+
+template 
+void test_iterators() {
+typedef std::iterator_traits ItT;
+typedef std::iterator_traits CItT;
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+}
+
 int main()
 {
 {
@@ -36,8 +55,9 @@ int main()
 typedef std::array C;
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+test_iterators();
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
@@ -57,8 +77,9 @@ int main()
 typedef std::array C;
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+test_iterators();
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");


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


Re: [PATCH] D21875: [libcxx] [test] The Standard requires meow_insert_iterator::reference to be void.

2016-06-29 Thread Eric Fiselier via cfe-commits
EricWF accepted this revision.
EricWF added a comment.
This revision is now accepted and ready to land.

I fixed both the libc++ implementation and tests in r274209.


http://reviews.llvm.org/D21875



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


[libcxx] r274209 - Fix ::reference typedef in insert iterators.

2016-06-29 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Wed Jun 29 23:40:50 2016
New Revision: 274209

URL: http://llvm.org/viewvc/llvm-project?rev=274209=rev
Log:
Fix ::reference typedef in insert iterators.

Since at least the C++11 standard insert iterators are specified
as having ::reference typedef void. Libc++ was not doing that.
This patch corrects the typedef.

This patch changes the std::iterator base class of insert_iterator,
front_insert_iterator and back_insert_iterator. This should not
be an ABI breaking change.

Modified:
libcxx/trunk/include/iterator

libcxx/trunk/test/std/iterators/predef.iterators/insert.iterators/back.insert.iterator/types.pass.cpp

libcxx/trunk/test/std/iterators/predef.iterators/insert.iterators/front.insert.iterator/types.pass.cpp

libcxx/trunk/test/std/iterators/predef.iterators/insert.iterators/insert.iterator/types.pass.cpp

Modified: libcxx/trunk/include/iterator
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=274209=274208=274209=diff
==
--- libcxx/trunk/include/iterator (original)
+++ libcxx/trunk/include/iterator Wed Jun 29 23:40:50 2016
@@ -149,7 +149,7 @@ public:
 typedef Container   container_type;
 typedef voidvalue_type;
 typedef voiddifference_type;
-typedef back_insert_iterator& reference;
+typedef voidreference;
 typedef voidpointer;
 
 explicit back_insert_iterator(Container& x);
@@ -170,7 +170,7 @@ public:
 typedef Containercontainer_type;
 typedef void value_type;
 typedef void difference_type;
-typedef front_insert_iterator& reference;
+typedef void reference;
 typedef void pointer;
 
 explicit front_insert_iterator(Container& x);
@@ -192,7 +192,7 @@ public:
 typedef Container  container_type;
 typedef void   value_type;
 typedef void   difference_type;
-typedef insert_iterator& reference;
+typedef void   reference;
 typedef void   pointer;
 
 insert_iterator(Container& x, typename Container::iterator i);
@@ -663,7 +663,7 @@ class _LIBCPP_TYPE_VIS_ONLY back_insert_
   void,
   void,
   void,
-  back_insert_iterator<_Container>&>
+  void>
 {
 protected:
 _Container* container;
@@ -696,7 +696,7 @@ class _LIBCPP_TYPE_VIS_ONLY front_insert
   void,
   void,
   void,
-  front_insert_iterator<_Container>&>
+  void>
 {
 protected:
 _Container* container;
@@ -729,7 +729,7 @@ class _LIBCPP_TYPE_VIS_ONLY insert_itera
   void,
   void,
   void,
-  insert_iterator<_Container>&>
+  void>
 {
 protected:
 _Container* container;

Modified: 
libcxx/trunk/test/std/iterators/predef.iterators/insert.iterators/back.insert.iterator/types.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/iterators/predef.iterators/insert.iterators/back.insert.iterator/types.pass.cpp?rev=274209=274208=274209=diff
==
--- 
libcxx/trunk/test/std/iterators/predef.iterators/insert.iterators/back.insert.iterator/types.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/iterators/predef.iterators/insert.iterators/back.insert.iterator/types.pass.cpp
 Wed Jun 29 23:40:50 2016
@@ -21,7 +21,7 @@
 //   typedef Contcontainer_type;
 //   typedef voidvalue_type;
 //   typedef voiddifference_type;
-//   typedef back_insert_iterator& reference;
+//   typedef voidreference;
 //   typedef voidpointer;
 // };
 
@@ -48,7 +48,7 @@ test()
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), 
"");
-static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 }

Modified: 
libcxx/trunk/test/std/iterators/predef.iterators/insert.iterators/front.insert.iterator/types.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/iterators/predef.iterators/insert.iterators/front.insert.iterator/types.pass.cpp?rev=274209=274208=274209=diff
==
--- 

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

2016-06-29 Thread Alexey Bataev via cfe-commits
ABataev added a comment.

No '\brief's



Comment at: include/clang/Driver/Action.h:204
@@ -159,1 +203,3 @@
+/// kind to its dependences.
+class OffloadAction : public Action {
   virtual void anchor();

'final'


Comment at: include/clang/Driver/Action.h:209
@@ +208,3 @@
+  /// architecture, toolchain, and offload kind to each action.
+  class DeviceDependences {
+  public:

'final'


Comment at: include/clang/Driver/Action.h:247
@@ +246,3 @@
+  /// architecture, toolchain, and offload kinds to the host action.
+  class HostDependence {
+/// \brief The dependence action.

'final'


Comment at: include/clang/Driver/Action.h:253-255
@@ +252,5 @@
+/// \brief The architectures that should be used with this action.
+const char *HostBoundArch;
+/// \brief The offload kind of each dependence.
+unsigned HostOffloadKinds;
+

default initializers


Comment at: include/clang/Driver/Action.h:277
@@ +276,3 @@
+  /// \brief The host offloading toolchain that should be used with the action.
+  const ToolChain *HostTC;
+

Default initializer


Comment at: lib/Driver/Driver.cpp:1942-1945
@@ -1877,2 +1941,6 @@
 }
-
+// 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 

Three slashes


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] r274207 - Make instreambuf.iterator/types.pass.cpp more portable.

2016-06-29 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Wed Jun 29 23:31:09 2016
New Revision: 274207

URL: http://llvm.org/viewvc/llvm-project?rev=274207=rev
Log:
Make instreambuf.iterator/types.pass.cpp more portable.

Modified:

libcxx/trunk/test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp

Modified: 
libcxx/trunk/test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp?rev=274207=274206=274207=diff
==
--- 
libcxx/trunk/test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp
 Wed Jun 29 23:31:09 2016
@@ -33,12 +33,16 @@
 #include 
 #include 
 
+#include "test_macros.h"
+
 int main()
 {
 typedef std::istreambuf_iterator I1;
-static_assert((std::is_convertible >::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
@@ -49,9 +53,11 @@ int main()
 static_assert((std::is_trivially_destructible::value), "" );
 
 typedef std::istreambuf_iterator I2;
-static_assert((std::is_convertible >::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");


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


[libcxx] r274206 - Fix use of terse static assert. Patch from s...@microsoft.com

2016-06-29 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Wed Jun 29 23:29:12 2016
New Revision: 274206

URL: http://llvm.org/viewvc/llvm-project?rev=274206=rev
Log:
Fix use of terse static assert. Patch from s...@microsoft.com

Modified:

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

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_swappable_include_order.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_swappable_include_order.pass.cpp?rev=274206=274205=274206=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_swappable_include_order.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_swappable_include_order.pass.cpp
 Wed Jun 29 23:29:12 2016
@@ -31,7 +31,7 @@ int main()
 {
 LIBCPP_STATIC_ASSERT(std::__is_swappable::value, "");
 #if TEST_STD_VER > 14
-static_assert(std::is_swappable_v);
+static_assert(std::is_swappable_v, "");
 #endif
 }
 {


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


Re: [PATCH] D21877: [libcxx] [test] is_swappable_include_order.pass.cpp was using a terse static_assert.

2016-06-29 Thread Eric Fiselier via cfe-commits
EricWF closed this revision.
EricWF added a comment.

r274206.


http://reviews.llvm.org/D21877



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


[libcxx] r274205 - Fix unary_function inheritance assumption. Patch from s...@microsoft.com

2016-06-29 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Wed Jun 29 23:28:12 2016
New Revision: 274205

URL: http://llvm.org/viewvc/llvm-project?rev=274205=rev
Log:
Fix unary_function inheritance assumption. Patch from s...@microsoft.com

Modified:
libcxx/trunk/test/std/containers/sequences/vector.bool/vector_bool.pass.cpp

Modified: 
libcxx/trunk/test/std/containers/sequences/vector.bool/vector_bool.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/vector.bool/vector_bool.pass.cpp?rev=274205=274204=274205=diff
==
--- libcxx/trunk/test/std/containers/sequences/vector.bool/vector_bool.pass.cpp 
(original)
+++ libcxx/trunk/test/std/containers/sequences/vector.bool/vector_bool.pass.cpp 
Wed Jun 29 23:28:12 2016
@@ -41,8 +41,8 @@ int main()
 {
 typedef std::vector T;
 typedef std::hash H;
-static_assert((std::is_base_of,
-   H>::value), "");
+static_assert((std::is_same::value), "" );
+static_assert((std::is_same::value), "" );
 bool ba[] = {true, false, true, true, false};
 T vb(std::begin(ba), std::end(ba));
 H h;


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


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

2016-06-29 Thread Alexey Bataev via cfe-commits
ABataev added a comment.

No '\brief's



Comment at: lib/Driver/Driver.cpp:1393
@@ +1392,3 @@
+/// generate the required device actions.
+class OffloadingActionBuilder {
+  /// \brief Flag used to trace errors in the builder.

1. 'final'
2. default initializers for fields


Comment at: lib/Driver/Driver.cpp:1437
@@ +1436,3 @@
+/// \brief The associated offload kind.
+Action::OffloadKind AssociatedOffloadKind;
+

default initializer


Comment at: lib/Driver/Driver.cpp:1486
@@ +1485,3 @@
+  /// action.
+  class CudaActionBuilder : public DeviceActionBuilder {
+/// \brief Flags to signal if the user requested host-only or device-only

'final'


http://reviews.llvm.org/D18172



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


Re: [PATCH] D21879: [libcxx] [test] Fix MSVC "warning C4100: 'argv': unreferenced formal parameter".

2016-06-29 Thread Eric Fiselier via cfe-commits
EricWF closed this revision.
EricWF added a comment.

r274204.


http://reviews.llvm.org/D21879



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


[libcxx] r274204 - Fix unreferenced parameter warning. Patch from s...@microsoft.com

2016-06-29 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Wed Jun 29 23:22:58 2016
New Revision: 274204

URL: http://llvm.org/viewvc/llvm-project?rev=274204=rev
Log:
Fix unreferenced parameter warning. Patch from s...@microsoft.com

Modified:

libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp

Modified: 
libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp?rev=274204=274203=274204=diff
==
--- 
libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
 Wed Jun 29 23:22:58 2016
@@ -17,7 +17,7 @@
 #include 
 #include 
 
-int main(int, char const **argv) {
+int main() {
   std::ostrstream oss;
   std::string s;
 


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


Re: [PATCH] D21870: [libcxx] [test] Avoid applying unary minus to unsigned integers.

2016-06-29 Thread Eric Fiselier via cfe-commits
EricWF closed this revision.
EricWF added a comment.

r274203.


http://reviews.llvm.org/D21870



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


[libcxx] r274203 - Avoid applying unary minus to unsigned integers. Patch from s...@microsoft.com

2016-06-29 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Wed Jun 29 23:21:52 2016
New Revision: 274203

URL: http://llvm.org/viewvc/llvm-project?rev=274203=rev
Log:
Avoid applying unary minus to unsigned integers. Patch from s...@microsoft.com

Modified:
libcxx/trunk/test/std/depr/depr.c.headers/stdint_h.pass.cpp
libcxx/trunk/test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp

Modified: libcxx/trunk/test/std/depr/depr.c.headers/stdint_h.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/depr/depr.c.headers/stdint_h.pass.cpp?rev=274203=274202=274203=diff
==
--- libcxx/trunk/test/std/depr/depr.c.headers/stdint_h.pass.cpp (original)
+++ libcxx/trunk/test/std/depr/depr.c.headers/stdint_h.pass.cpp Wed Jun 29 
23:21:52 2016
@@ -171,8 +171,8 @@ int main()
 // INTN_MIN
 static_assert(INT8_MIN == -128, "INT8_MIN == -128");
 static_assert(INT16_MIN == -32768, "INT16_MIN == -32768");
-static_assert(INT32_MIN == -2147483648U, "INT32_MIN == -2147483648");
-static_assert(INT64_MIN == -9223372036854775808ULL, "INT64_MIN == 
-9223372036854775808LL");
+static_assert(INT32_MIN == -2147483647 - 1, "INT32_MIN == -2147483648");
+static_assert(INT64_MIN == -9223372036854775807LL - 1, "INT64_MIN == 
-9223372036854775808LL");
 
 // INTN_MAX
 static_assert(INT8_MAX == 127, "INT8_MAX == 127");
@@ -189,8 +189,8 @@ int main()
 // INT_FASTN_MIN
 static_assert(INT_FAST8_MIN <= -128, "INT_FAST8_MIN <= -128");
 static_assert(INT_FAST16_MIN <= -32768, "INT_FAST16_MIN <= -32768");
-static_assert(INT_FAST32_MIN <= -2147483648U, "INT_FAST32_MIN <= 
-2147483648");
-static_assert(INT_FAST64_MIN <= -9223372036854775808ULL, "INT_FAST64_MIN 
<= -9223372036854775808LL");
+static_assert(INT_FAST32_MIN <= -2147483647 - 1, "INT_FAST32_MIN <= 
-2147483648");
+static_assert(INT_FAST64_MIN <= -9223372036854775807LL - 1, 
"INT_FAST64_MIN <= -9223372036854775808LL");
 
 // INT_FASTN_MAX
 static_assert(INT_FAST8_MAX >= 127, "INT_FAST8_MAX >= 127");

Modified: 
libcxx/trunk/test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp?rev=274203=274202=274203=diff
==
--- libcxx/trunk/test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp 
(original)
+++ libcxx/trunk/test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp 
Wed Jun 29 23:21:52 2016
@@ -172,8 +172,8 @@ int main()
 // INTN_MIN
 static_assert(INT8_MIN == -128, "INT8_MIN == -128");
 static_assert(INT16_MIN == -32768, "INT16_MIN == -32768");
-static_assert(INT32_MIN == -2147483648U, "INT32_MIN == -2147483648");
-static_assert(INT64_MIN == -9223372036854775808ULL, "INT64_MIN == 
-9223372036854775808LL");
+static_assert(INT32_MIN == -2147483647 - 1, "INT32_MIN == -2147483648");
+static_assert(INT64_MIN == -9223372036854775807LL - 1, "INT64_MIN == 
-9223372036854775808LL");
 
 // INTN_MAX
 static_assert(INT8_MAX == 127, "INT8_MAX == 127");
@@ -190,8 +190,8 @@ int main()
 // INT_FASTN_MIN
 static_assert(INT_FAST8_MIN <= -128, "INT_FAST8_MIN <= -128");
 static_assert(INT_FAST16_MIN <= -32768, "INT_FAST16_MIN <= -32768");
-static_assert(INT_FAST32_MIN <= -2147483648U, "INT_FAST32_MIN <= 
-2147483648");
-static_assert(INT_FAST64_MIN <= -9223372036854775808ULL, "INT_FAST64_MIN 
<= -9223372036854775808LL");
+static_assert(INT_FAST32_MIN <= -2147483647 - 1, "INT_FAST32_MIN <= 
-2147483648");
+static_assert(INT_FAST64_MIN <= -9223372036854775807LL - 1, 
"INT_FAST64_MIN <= -9223372036854775808LL");
 
 // INT_FASTN_MAX
 static_assert(INT_FAST8_MAX >= 127, "INT_FAST8_MAX >= 127");


___
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-06-29 Thread Alexey Bataev via cfe-commits
ABataev added inline comments.


Comment at: lib/Driver/Driver.cpp:1778
@@ +1777,3 @@
+  /// phase.
+  class OpenMPActionBuilder : public DeviceActionBuilder {
+/// \brief The OpenMP actions for the current input.

'final'


http://reviews.llvm.org/D21845



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


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

2016-06-29 Thread Alexey Bataev via cfe-commits
ABataev added inline comments.


Comment at: lib/Driver/Tools.cpp:297
@@ +296,3 @@
+  StringRef Name = llvm::sys::path::filename(Output.getFilename());
+  StringRef Prefix = Name.rsplit('.').first;
+  if (C.getDriver().isSaveTempsEnabled()) {

Use llvm::sys::path::replace_extension()


http://reviews.llvm.org/D21847



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


Re: [PATCH] D13909: clang-offload-bundler - offload files bundling/unbundling tool

2016-06-29 Thread Alexey Bataev via cfe-commits
ABataev added a comment.

Remove empty 'return' and ';' statements where they are not required.



Comment at: test/Driver/clang-offload-bundler.c:14
@@ +13,3 @@
+//
+// RUN: touch %t.empty
+

Hmm, will it work on Windows? Maybe it is better just to add an empty test file?


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:174
@@ +173,3 @@
+  /// \brief Information about the bundles extracted from the header.
+  struct BundleInfo {
+/// \brief Size of the bundle.

1. 'final'
2. Default field initializers instead of default constructor


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:304-305
@@ +303,4 @@
+  }
+  void WriteBundleStart(raw_fd_ostream , StringRef TargetTriple) { return; }
+  void WriteBundleEnd(raw_fd_ostream , StringRef TargetTriple) { return; }
+  void WriteBundle(raw_fd_ostream , MemoryBuffer ) {

remove empty 'return's


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:308
@@ +307,3 @@
+OS.write(Input.getBufferStart(), Input.getBufferSize());
+return;
+  }

Remove it


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:335
@@ +334,3 @@
+  /// \brief Number of chars read from input.
+  size_t ReadChars;
+

Default initializer


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:453
@@ +452,3 @@
+  unsigned Idx = 0;
+  for (auto I : InputFileNames) {
+ErrorOr CodeOrErr =

auto  instead of auto I?


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:477-478
@@ +476,4 @@
+  auto Input = InputBuffers.begin();
+  for (auto Triple = TargetNames.begin(); Triple < TargetNames.end();
+   ++Triple, ++Input) {
+FH.get()->WriteBundleStart(OutputFile, *Triple);

for (auto  : TargetNames)



Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:513-514
@@ +512,4 @@
+  auto Output = OutputFileNames.begin();
+  for (auto Triple = TargetNames.begin(); Triple < TargetNames.end();
+   ++Triple, ++Output)
+Worklist[*Triple] = *Output;

for (auto  : TargetNames)


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:677-680
@@ +676,6 @@
+
+  if (Unbundle)
+return UnbundleFiles();
+  else
+return BundleFiles();
+

Maybe 'return Unbundle ? UnbundleFiles() : BundleFiles();'?


http://reviews.llvm.org/D13909



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


Re: [PATCH] D21836: [AVX512][BUILTIN][vpermilps][intrinsics] Fixing two incorrect IMM check.

2016-06-29 Thread Craig Topper via cfe-commits
craig.topper added inline comments.


Comment at: lib/Sema/SemaChecking.cpp:1568
@@ -1569,1 +1567,3 @@
+  case X86::BI__builtin_ia32_vpermilps_mask:
+  case X86::BI__builtin_ia32_vpermilps256_mask:
 i = 1; l = 0; u = 255;

Can you put these adjacent to vpermilps512_mask?


http://reviews.llvm.org/D21836



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


Re: [PATCH] D21851: [Driver][OpenMP][CUDA] Add capability to bundle object files in sections of the host binary format.

2016-06-29 Thread Alexey Bataev via cfe-commits
ABataev added inline comments.


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:324-334
@@ -314,1 +323,13 @@
 
+// Handler for object files. The bundles are organized by sections with a
+// designated name.
+//
+// In order to bundle we create an IR file with the content of each section and
+// use incremental linking to produce the resulting object. We also add section
+// with a single byte to state the name of the component the main object file
+// (the one we are bundling into) refers to.
+//
+// To unbundle, we use just copy the contents of the designated section. If the
+// requested bundle refer to the main object file, we just copy it with no
+// changes.
+class ObjectFileHandler : public FileHandler {

3 slashes, please


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:335
@@ +334,3 @@
+// changes.
+class ObjectFileHandler : public FileHandler {
+

'final'?


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:337
@@ +336,3 @@
+
+  /// \brief The object file we are currently dealing with.
+  ObjectFile 

No '\brief's


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:345
@@ +344,3 @@
+  /// return the triple by reference.
+  bool isOffloadSection(SectionRef CurSection, StringRef ) {
+StringRef SectionName;

'const'? or 'static'?


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:450
@@ +449,3 @@
+ BitcodeFileName))
+  llvm_unreachable("Error trying to create temporary file!");
+

Not sure that this a good solution to crash the compiler in this case. I think 
it must exit gracefully.


Comment at: tools/clang-offload-bundler/ClangOffloadBundler.cpp:468
@@ +467,3 @@
+  sys::fs::remove(BitcodeFileName);
+  llvm_unreachable("Can't find clang in path!");
+}

Again, maybe just emit an error an exit?


http://reviews.llvm.org/D21851



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


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

2016-06-29 Thread Alexey Bataev via cfe-commits
ABataev added inline comments.


Comment at: include/clang/Driver/Action.h:493
@@ -491,1 +492,3 @@
 
+class OffloadUnbundlingJobAction : public JobAction {
+  void anchor() override;

'final'?


Comment at: include/clang/Driver/Action.h:499
@@ +498,3 @@
+  /// this unbundling action.
+  struct DependingActionInfoTy {
+/// \brief The tool chain of the depending action.

1. 'final'?
2. Default initializers for fields


Comment at: include/clang/Driver/Types.h:78
@@ +77,3 @@
+  /// compilation phase is a preprocessor one.
+  bool isSrcFile(ID Id);
+

'const'?


http://reviews.llvm.org/D21853



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


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

2016-06-29 Thread Alexey Bataev via cfe-commits
ABataev added a comment.

Remove '\brief'



Comment at: include/clang/Driver/Action.h:158-160
@@ -158,1 +157,5 @@
+  /// non-device kinds, except if \a CreatePrefixForHost is set.
+  static std::string
+  getOffloadingFileNamePrefix(OffloadKind Kind, StringRef NormalizedTriple,
+  bool CreatePrefixForHost = false);
   /// \brief Return a string containing a offload kind name.

Can this be 'static'? Also, name of the function must start from capital letter.


Comment at: include/clang/Driver/Tool.h:132-140
@@ -131,1 +131,11 @@
 const char *LinkingOutput) const = 0;
+  /// ConstructJob - Construct jobs to perform the action \p JA,
+  /// writing to the \p Outputs and with \p Inputs, and add the jobs to
+  /// \p C. The default implementation assumes a single output and is expected
+  /// to be overloaded for the tools that support multiple inputs.
+  ///
+  /// \param TCArgs - The argument list for this toolchain, with any
+  /// tool chain specific translations applied.
+  /// \param LinkingOutput - If this output will eventually feed the
+  /// linker, then this is the final output name of the linked image.
+  virtual void ConstructJob(Compilation , const JobAction ,

Please, format properly. Remove the name of the function and '-' signs after 
params


http://reviews.llvm.org/D21857



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


Re: [PATCH] D21863: Fix typo in atomic macros

2016-06-29 Thread David Majnemer via cfe-commits
majnemer added a subscriber: majnemer.
majnemer accepted this revision.
majnemer added a reviewer: majnemer.
majnemer added a comment.
This revision is now accepted and ready to land.

LGTM


http://reviews.llvm.org/D21863



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


r274201 - [CodeView] Implement support for bitfields in Clang

2016-06-29 Thread David Majnemer via cfe-commits
Author: majnemer
Date: Wed Jun 29 22:01:59 2016
New Revision: 274201

URL: http://llvm.org/viewvc/llvm-project?rev=274201=rev
Log:
[CodeView] Implement support for bitfields in Clang

Emit the underlying storage offset in addition to the starting bit
position of the field.

This fixes PR28162.

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

Added:
cfe/trunk/test/CodeGenCXX/debug-info-ms-bitfields.cpp
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h
cfe/trunk/test/CodeGen/debug-info-packed-struct.c

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=274201=274200=274201=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Wed Jun 29 22:01:59 2016
@@ -13,6 +13,7 @@
 
 #include "CGDebugInfo.h"
 #include "CGBlocks.h"
+#include "CGRecordLayout.h"
 #include "CGCXXABI.h"
 #include "CGObjCRuntime.h"
 #include "CodeGenFunction.h"
@@ -905,10 +906,38 @@ static unsigned getAccessFlag(AccessSpec
   llvm_unreachable("unexpected access enumerator");
 }
 
-llvm::DIType *CGDebugInfo::createFieldType(
-StringRef name, QualType type, uint64_t sizeInBitsOverride,
-SourceLocation loc, AccessSpecifier AS, uint64_t offsetInBits,
-llvm::DIFile *tunit, llvm::DIScope *scope, const RecordDecl *RD) {
+llvm::DIType *CGDebugInfo::createBitFieldType(const FieldDecl *BitFieldDecl,
+  llvm::DIScope *RecordTy,
+  const RecordDecl *RD) {
+  StringRef Name = BitFieldDecl->getName();
+  QualType Ty = BitFieldDecl->getType();
+  SourceLocation Loc = BitFieldDecl->getLocation();
+  llvm::DIFile *VUnit = getOrCreateFile(Loc);
+  llvm::DIType *DebugType = getOrCreateType(Ty, VUnit);
+
+  // Get the location for the field.
+  llvm::DIFile *File = getOrCreateFile(Loc);
+  unsigned Line = getLineNumber(Loc);
+
+  const CGBitFieldInfo  =
+  CGM.getTypes().getCGRecordLayout(RD).getBitFieldInfo(BitFieldDecl);
+  uint64_t SizeInBits = BitFieldInfo.Size;
+  assert(SizeInBits > 0 && "found named 0-width bitfield");
+  unsigned AlignInBits = CGM.getContext().getTypeAlign(Ty);
+  uint64_t StorageOffsetInBits =
+  CGM.getContext().toBits(BitFieldInfo.StorageOffset);
+  uint64_t OffsetInBits = StorageOffsetInBits + BitFieldInfo.Offset;
+  unsigned Flags = getAccessFlag(BitFieldDecl->getAccess(), RD);
+  return DBuilder.createBitFieldMemberType(
+  RecordTy, Name, File, Line, SizeInBits, AlignInBits, OffsetInBits,
+  StorageOffsetInBits, Flags, DebugType);
+}
+
+llvm::DIType *
+CGDebugInfo::createFieldType(StringRef name, QualType type, SourceLocation loc,
+ AccessSpecifier AS, uint64_t offsetInBits,
+ llvm::DIFile *tunit, llvm::DIScope *scope,
+ const RecordDecl *RD) {
   llvm::DIType *debugType = getOrCreateType(type, tunit);
 
   // Get the location for the field.
@@ -921,9 +950,6 @@ llvm::DIType *CGDebugInfo::createFieldTy
 TypeInfo TI = CGM.getContext().getTypeInfo(type);
 SizeInBits = TI.Width;
 AlignInBits = TI.Align;
-
-if (sizeInBitsOverride)
-  SizeInBits = sizeInBitsOverride;
   }
 
   unsigned flags = getAccessFlag(AS, RD);
@@ -945,19 +971,15 @@ void CGDebugInfo::CollectRecordLambdaFie
I != E; ++I, ++Field, ++fieldno) {
 const LambdaCapture  = *I;
 if (C.capturesVariable()) {
+  SourceLocation Loc = C.getLocation();
+  assert(!Field->isBitField() && "lambdas don't have bitfield members!");
   VarDecl *V = C.getCapturedVar();
-  llvm::DIFile *VUnit = getOrCreateFile(C.getLocation());
   StringRef VName = V->getName();
-  uint64_t SizeInBitsOverride = 0;
-  if (Field->isBitField()) {
-SizeInBitsOverride = Field->getBitWidthValue(CGM.getContext());
-assert(SizeInBitsOverride && "found named 0-width bitfield");
-  }
-  llvm::DIType *fieldType = createFieldType(
-  VName, Field->getType(), SizeInBitsOverride, C.getLocation(),
-  Field->getAccess(), layout.getFieldOffset(fieldno), VUnit, RecordTy,
-  CXXDecl);
-  elements.push_back(fieldType);
+  llvm::DIFile *VUnit = getOrCreateFile(Loc);
+  llvm::DIType *FieldType = createFieldType(
+  VName, Field->getType(), Loc, Field->getAccess(),
+  layout.getFieldOffset(fieldno), VUnit, RecordTy, CXXDecl);
+  elements.push_back(FieldType);
 } else if (C.capturesThis()) {
   // TODO: Need to handle 'this' in some way by probably renaming the
   // this of the lambda class and having a field member of 'this' or
@@ -967,7 +989,7 @@ void CGDebugInfo::CollectRecordLambdaFie
   llvm::DIFile *VUnit = getOrCreateFile(f->getLocation());
   QualType type = f->getType();
   llvm::DIType *fieldType = 

Re: [PATCH] D21783: [CodeView] Implement support for bitfields in Clang

2016-06-29 Thread David Majnemer via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274201: [CodeView] Implement support for bitfields in Clang 
(authored by majnemer).

Changed prior to commit:
  http://reviews.llvm.org/D21783?vs=62095=62333#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21783

Files:
  cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
  cfe/trunk/lib/CodeGen/CGDebugInfo.h
  cfe/trunk/test/CodeGen/debug-info-packed-struct.c
  cfe/trunk/test/CodeGenCXX/debug-info-ms-bitfields.cpp

Index: cfe/trunk/test/CodeGen/debug-info-packed-struct.c
===
--- cfe/trunk/test/CodeGen/debug-info-packed-struct.c
+++ cfe/trunk/test/CodeGen/debug-info-packed-struct.c
@@ -21,7 +21,7 @@
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "l0_ofs8",
 // CHECK-SAME: {{.*}}size: 64, align: 64, offset: 64)
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "l0_ofs16",
-// CHECK-SAME: {{.*}}size: 1, align: 32, offset: 128)
+// CHECK-SAME: {{.*}}size: 1, align: 32, offset: 128, flags: DIFlagBitField, extraData: i64 128)
 
 
 // -
@@ -40,7 +40,7 @@
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "l1_ofs1",
 // CHECK-SAME: {{.*}}size: 64, align: 8, offset: 8)
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "l1_ofs9",
-// CHECK-SAME: {{.*}}size: 1, align: 32, offset: 72)
+// CHECK-SAME: {{.*}}size: 1, align: 32, offset: 72, flags: DIFlagBitField, extraData: i64 72)
 
 
 // -
@@ -61,7 +61,7 @@
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "l2_ofs1",
 // CHECK-SAME: {{.*}}size: 64, align: 8, offset: 8)
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "l2_ofs9",
-// CHECK-SAME: {{.*}}size: 1, align: 32, offset: 72)
+// CHECK-SAME: {{.*}}size: 1, align: 32, offset: 72, flags: DIFlagBitField, extraData: i64 72)
 
 
 
@@ -83,7 +83,7 @@
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "l3_ofs4",
 // CHECK-SAME: {{.*}}size: 64, align: 32, offset: 32)
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "l3_ofs12",
-// CHECK-SAME: {{.*}}size: 1, align: 32, offset: 96)
+// CHECK-SAME: {{.*}}size: 1, align: 32, offset: 96, flags: DIFlagBitField, extraData: i64 96)
 
 struct layout0 l0;
 struct layout1 l1;
Index: cfe/trunk/test/CodeGenCXX/debug-info-ms-bitfields.cpp
===
--- cfe/trunk/test/CodeGenCXX/debug-info-ms-bitfields.cpp
+++ cfe/trunk/test/CodeGenCXX/debug-info-ms-bitfields.cpp
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -triple x86_64-pc-win32 -debug-info-kind=limited -gcodeview %s -emit-llvm -o - | FileCheck %s
+
+#pragma pack(1)
+struct S {
+  char : 8;
+  short   : 8;
+  short x : 8;
+} s;
+
+// CHECK: !DIDerivedType(tag: DW_TAG_member, name: "x", {{.*}}, size: 8, align: 16, offset: 16, flags: DIFlagBitField, extraData: i64 8)
Index: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
===
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
@@ -13,6 +13,7 @@
 
 #include "CGDebugInfo.h"
 #include "CGBlocks.h"
+#include "CGRecordLayout.h"
 #include "CGCXXABI.h"
 #include "CGObjCRuntime.h"
 #include "CodeGenFunction.h"
@@ -905,10 +906,38 @@
   llvm_unreachable("unexpected access enumerator");
 }
 
-llvm::DIType *CGDebugInfo::createFieldType(
-StringRef name, QualType type, uint64_t sizeInBitsOverride,
-SourceLocation loc, AccessSpecifier AS, uint64_t offsetInBits,
-llvm::DIFile *tunit, llvm::DIScope *scope, const RecordDecl *RD) {
+llvm::DIType *CGDebugInfo::createBitFieldType(const FieldDecl *BitFieldDecl,
+  llvm::DIScope *RecordTy,
+  const RecordDecl *RD) {
+  StringRef Name = BitFieldDecl->getName();
+  QualType Ty = BitFieldDecl->getType();
+  SourceLocation Loc = BitFieldDecl->getLocation();
+  llvm::DIFile *VUnit = getOrCreateFile(Loc);
+  llvm::DIType *DebugType = getOrCreateType(Ty, VUnit);
+
+  // Get the location for the field.
+  llvm::DIFile *File = getOrCreateFile(Loc);
+  unsigned Line = getLineNumber(Loc);
+
+  const CGBitFieldInfo  =
+  CGM.getTypes().getCGRecordLayout(RD).getBitFieldInfo(BitFieldDecl);
+  uint64_t SizeInBits = BitFieldInfo.Size;
+  assert(SizeInBits > 0 && "found named 0-width bitfield");
+  unsigned AlignInBits = CGM.getContext().getTypeAlign(Ty);
+  uint64_t StorageOffsetInBits =
+  CGM.getContext().toBits(BitFieldInfo.StorageOffset);
+  uint64_t OffsetInBits = StorageOffsetInBits + BitFieldInfo.Offset;
+  unsigned Flags = getAccessFlag(BitFieldDecl->getAccess(), RD);
+  return DBuilder.createBitFieldMemberType(
+  RecordTy, Name, File, Line, SizeInBits, AlignInBits, OffsetInBits,
+  StorageOffsetInBits, Flags, DebugType);
+}
+
+llvm::DIType *

r274202 - [MS ABI] Pick an inheritance model if we resolve an overload set

2016-06-29 Thread David Majnemer via cfe-commits
Author: majnemer
Date: Wed Jun 29 22:02:03 2016
New Revision: 274202

URL: http://llvm.org/viewvc/llvm-project?rev=274202=rev
Log:
[MS ABI] Pick an inheritance model if we resolve an overload set

We didn't assign an inheritance model for 'Foo' if the event an
exrepssion like '::Bar' occured if 'Bar' could resolve to multiple
functions.

Once the overload set is resolved to a particular member, we enforce a
specific inheritance model.

This fixes PR28360.

Added:
cfe/trunk/test/CodeGenCXX/pr28360.cpp
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=274202=274201=274202=diff
==
--- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOverload.cpp Wed Jun 29 22:02:03 2016
@@ -13021,6 +13021,9 @@ Expr *Sema::FixOverloadedFunctionReferen
   = 
Context.getTypeDeclType(cast(Method->getDeclContext()));
 QualType MemPtrType
   = Context.getMemberPointerType(Fn->getType(), 
ClassType.getTypePtr());
+// Under the MS ABI, lock down the inheritance model now.
+if (Context.getTargetInfo().getCXXABI().isMicrosoft())
+  (void)isCompleteType(UnOp->getOperatorLoc(), MemPtrType);
 
 return new (Context) UnaryOperator(SubExpr, UO_AddrOf, MemPtrType,
VK_RValue, OK_Ordinary,

Added: cfe/trunk/test/CodeGenCXX/pr28360.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pr28360.cpp?rev=274202=auto
==
--- cfe/trunk/test/CodeGenCXX/pr28360.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/pr28360.cpp Wed Jun 29 22:02:03 2016
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple i686-pc-win32 | FileCheck %s
+struct A {
+  void Foo();
+  void Foo(int);
+};
+
+using MpTy = void (A::*)();
+
+void Bar(const MpTy &);
+
+void Baz() { Bar(::Foo); }
+
+// CHECK-LABEL: define void @"\01?Baz@@YAXXZ"(
+// CHECK:  %[[ref_tmp:.*]] = alloca i8*, align 4
+// CHECK: store i8* bitcast (void (%struct.A*)* @"\01?Foo@A@@QAEXXZ" to i8*), 
i8** %[[ref_tmp]], align 4
+// CHECK: call void @"\01?Bar@@YAXABQ8A@@AEXXZ@Z"(i8** dereferenceable(4) 
%[[ref_tmp]])


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


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

2016-06-29 Thread Alexey Bataev via cfe-commits
ABataev added a comment.

General comment: remove '\brief' tags, they are not required anymore, just 
'\\\' is enough



Comment at: include/clang/Driver/Action.h:94
@@ -93,1 +93,3 @@
 
+  /// \brief Flag that is set to true if this action can be collapsed with
+  /// others actions that depend on it. This is true by default and set to 
false

'\brief' tag is not required, remove it.


Comment at: lib/Driver/Driver.cpp:2400
@@ +2399,3 @@
+  /// \brief Return true if an assemble action can be collapsed.
+  bool canCollapseAssembleAction() {
+return TC.useIntegratedAs() && !SaveTemps &&

bool canCollapseAssembleAction() -> bool canCollapseAssembleAction() const


Comment at: lib/Driver/Driver.cpp:2408
@@ +2407,3 @@
+  /// \brief Return true if a preprocessor action can be collapsed.
+  bool canCollapsePreprocessorAction() {
+return !C.getArgs().hasArg(options::OPT_no_integrated_cpp) &&

Also can be marked as const


Comment at: lib/Driver/Driver.cpp:2416
@@ +2415,3 @@
+  /// be collapsed with it.
+  struct JobActionInfoTy {
+// \brief The action this info refers to.

I think this can be marked 'final' and add 'nullptr' as a default initializer 
for 'JA' field


Comment at: lib/Driver/Driver.cpp:2424
@@ +2423,3 @@
+
+  /// \brief Append collapsed offload actions from the give nnumber of elements
+  /// in the action info array.

Remove '\brief'


Comment at: lib/Driver/Driver.cpp:2426
@@ +2425,3 @@
+  /// in the action info array.
+  void appendCollapsedOffloadAction(ActionList ,
+ArrayRef ,

I think this function can be marked as 'static', no?


Comment at: lib/Driver/Driver.cpp:2435
@@ +2434,3 @@
+
+  /// \brief Functions that attempt to perform the combining. They detect if
+  /// that is legal, and if so they update the inputs \a Inputs and the offload

remove '\brief'


http://reviews.llvm.org/D21840



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


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

2016-06-29 Thread Alexey Bataev via cfe-commits
ABataev added inline comments.


Comment at: lib/Driver/Driver.cpp:464-468
@@ +463,7 @@
+  RuntimeName = A->getValue();
+HasCompatibleOpenMP = llvm::StringSwitch(RuntimeName)
+  .Case("libomp", true)
+  .Case("libgomp", false)
+  .Case("libiomp5", true)
+  .Default(false);
+  }

I don't like the fact that we have similar string comparisons in different 
files. This must be handled in a single place.


http://reviews.llvm.org/D21843



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


Re: [PATCH] D21860: [ASTMatcher] Add a node matcher for EnumType.

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

LGTM!


http://reviews.llvm.org/D21860



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


Re: r274064 - AvailabilityAttr: we accept "macos" as the platform name.

2016-06-29 Thread Aaron Ballman via cfe-commits
On Wed, Jun 29, 2016 at 11:57 AM, Manman Ren  wrote:
> Good point! In r274133.

Thank you!

~Aaron

>
> Manman
>
> On Wed, Jun 29, 2016 at 7:30 AM, Aaron Ballman 
> wrote:
>>
>> On Tue, Jun 28, 2016 at 4:55 PM, Manman Ren via cfe-commits
>>  wrote:
>> > Author: mren
>> > Date: Tue Jun 28 15:55:30 2016
>> > New Revision: 274064
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=274064=rev
>> > Log:
>> > AvailabilityAttr: we accept "macos" as the platform name.
>> >
>> > We continue accepting "macosx" but canonicalize it to "macos", When
>> > emitting
>> > diagnostics, we use "macOS" instead of "OS X".
>> >
>> > The PlatformName in TargetInfo is changed from "macosx" to "macos" so we
>> > can
>> > directly compare the Platform in AvailabilityAttr with the PlatformName
>> > in TargetInfo.
>> >
>> > rdar://26795172
>> > rdar://26800775
>> >
>> > Modified:
>> > cfe/trunk/include/clang-c/Index.h
>> > cfe/trunk/include/clang/Basic/Attr.td
>> > cfe/trunk/include/clang/Basic/AttrDocs.td
>> > cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
>> > cfe/trunk/lib/AST/Decl.cpp
>> > cfe/trunk/lib/Basic/Targets.cpp
>> > cfe/trunk/lib/Parse/ParseDecl.cpp
>> > cfe/trunk/test/Index/annotate-comments-availability-attrs.cpp
>> > cfe/trunk/test/Index/availability.c
>> > cfe/trunk/test/Misc/ast-print-objectivec.m
>> > cfe/trunk/test/Sema/attr-availability-macosx.c
>> > cfe/trunk/test/Sema/attr-availability.c
>> > cfe/trunk/test/Sema/attr-print.c
>> > cfe/trunk/test/SemaCXX/attr-deprecated-replacement-fixit.cpp
>> > cfe/trunk/test/SemaObjC/attr-availability-1.m
>> > cfe/trunk/test/SemaObjC/attr-availability.m
>> > cfe/trunk/test/SemaObjC/attr-deprecated.m
>> > cfe/trunk/test/SemaObjC/property-noninherited-availability-attr.m
>> >
>> > Modified: cfe/trunk/include/clang-c/Index.h
>> > URL:
>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang-c/Index.h?rev=274064=274063=274064=diff
>> >
>> > ==
>> > --- cfe/trunk/include/clang-c/Index.h (original)
>> > +++ cfe/trunk/include/clang-c/Index.h Tue Jun 28 15:55:30 2016
>> > @@ -2570,7 +2570,7 @@ typedef struct CXPlatformAvailability {
>> > * \brief A string that describes the platform for which this
>> > structure
>> > * provides availability information.
>> > *
>> > -   * Possible values are "ios" or "macosx".
>> > +   * Possible values are "ios" or "macos".
>> > */
>> >CXString Platform;
>> >/**
>> >
>> > Modified: cfe/trunk/include/clang/Basic/Attr.td
>> > URL:
>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=274064=274063=274064=diff
>> >
>> > ==
>> > --- cfe/trunk/include/clang/Basic/Attr.td (original)
>> > +++ cfe/trunk/include/clang/Basic/Attr.td Tue Jun 28 15:55:30 2016
>> > @@ -477,11 +477,11 @@ def Availability : InheritableAttr {
>> >  return llvm::StringSwitch(Platform)
>> >   .Case("android", "Android")
>> >   .Case("ios", "iOS")
>> > - .Case("macosx", "OS X")
>> > + .Case("macos", "macOS")
>> >   .Case("tvos", "tvOS")
>> >   .Case("watchos", "watchOS")
>> >   .Case("ios_app_extension", "iOS (App Extension)")
>> > - .Case("macosx_app_extension", "OS X (App Extension)")
>> > + .Case("macos_app_extension", "macOS (App Extension)")
>> >   .Case("tvos_app_extension", "tvOS (App Extension)")
>> >   .Case("watchos_app_extension", "watchOS (App Extension)")
>> >   .Default(llvm::StringRef());
>> >
>> > Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
>> > URL:
>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=274064=274063=274064=diff
>> >
>> > ==
>> > --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
>> > +++ cfe/trunk/include/clang/Basic/AttrDocs.td Tue Jun 28 15:55:30 2016
>> > @@ -691,7 +691,7 @@ the function declaration for a hypotheti
>> >
>> >  .. code-block:: c++
>> >
>> > -  void f(void)
>> > __attribute__((availability(macosx,introduced=10.4,deprecated=10.6,obsoleted=10.7)));
>> > +  void f(void)
>> > __attribute__((availability(macos,introduced=10.4,deprecated=10.6,obsoleted=10.7)));
>> >
>> >  The availability attribute states that ``f`` was introduced in Mac OS X
>> > 10.4,
>> >  deprecated in Mac OS X 10.6, and obsoleted in Mac OS X 10.7.  This
>> > information
>> > @@ -743,7 +743,7 @@ are:
>> >the ``-mios-version-min=*version*`` or
>> > ``-miphoneos-version-min=*version*``
>> >command-line arguments.
>> >
>> > -``macosx``
>> > +``macos``
>>
>> Can you please continue to document that we support macosx, but that
>> it's 

Re: [PATCH] D21773: [clang] Update an optimization remark test for change D18777

2016-06-29 Thread Li Huang via cfe-commits
lihuang added a comment.

You are right. A regression test could be:

  void foo2(int *dw, int *uw, int *A, int *B, int *C, int *D, int N) {
for (int i = 0; i < N; i++) {
  dw[i] = A[i] + B[i - 1] + C[i - 2];
  uw[i] = A[i] + B[i + 2];
}
  }

need to fix the fundamental problem.


http://reviews.llvm.org/D21773



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


[PATCH] D21863: Fix typo in atomic macros

2016-06-29 Thread Zachary Mahler via cfe-commits
zmahler created this revision.
zmahler added a reviewer: hfinkel.
zmahler added a subscriber: cfe-commits.

Some of the macros should be defined without the extra "_T_".
Fix https://llvm.org/bugs/show_bug.cgi?id=27200

http://reviews.llvm.org/D21863

Files:
  lib/Headers/stdatomic.h

Index: lib/Headers/stdatomic.h
===
--- lib/Headers/stdatomic.h
+++ lib/Headers/stdatomic.h
@@ -45,11 +45,11 @@
 #define ATOMIC_CHAR16_T_LOCK_FREE   __GCC_ATOMIC_CHAR16_T_LOCK_FREE
 #define ATOMIC_CHAR32_T_LOCK_FREE   __GCC_ATOMIC_CHAR32_T_LOCK_FREE
 #define ATOMIC_WCHAR_T_LOCK_FREE__GCC_ATOMIC_WCHAR_T_LOCK_FREE
-#define ATOMIC_SHORT_T_LOCK_FREE__GCC_ATOMIC_SHORT_T_LOCK_FREE
-#define ATOMIC_INT_T_LOCK_FREE  __GCC_ATOMIC_INT_T_LOCK_FREE
-#define ATOMIC_LONG_T_LOCK_FREE __GCC_ATOMIC_LONG_T_LOCK_FREE
-#define ATOMIC_LLONG_T_LOCK_FREE__GCC_ATOMIC_LLONG_T_LOCK_FREE
-#define ATOMIC_POINTER_T_LOCK_FREE  __GCC_ATOMIC_POINTER_T_LOCK_FREE
+#define ATOMIC_SHORT_LOCK_FREE  __GCC_ATOMIC_SHORT_LOCK_FREE
+#define ATOMIC_INT_LOCK_FREE__GCC_ATOMIC_INT_LOCK_FREE
+#define ATOMIC_LONG_LOCK_FREE   __GCC_ATOMIC_LONG_LOCK_FREE
+#define ATOMIC_LLONG_LOCK_FREE  __GCC_ATOMIC_LLONG_LOCK_FREE
+#define ATOMIC_POINTER_LOCK_FREE__GCC_ATOMIC_POINTER_LOCK_FREE
 
 /* 7.17.2 Initialization */
 


Index: lib/Headers/stdatomic.h
===
--- lib/Headers/stdatomic.h
+++ lib/Headers/stdatomic.h
@@ -45,11 +45,11 @@
 #define ATOMIC_CHAR16_T_LOCK_FREE   __GCC_ATOMIC_CHAR16_T_LOCK_FREE
 #define ATOMIC_CHAR32_T_LOCK_FREE   __GCC_ATOMIC_CHAR32_T_LOCK_FREE
 #define ATOMIC_WCHAR_T_LOCK_FREE__GCC_ATOMIC_WCHAR_T_LOCK_FREE
-#define ATOMIC_SHORT_T_LOCK_FREE__GCC_ATOMIC_SHORT_T_LOCK_FREE
-#define ATOMIC_INT_T_LOCK_FREE  __GCC_ATOMIC_INT_T_LOCK_FREE
-#define ATOMIC_LONG_T_LOCK_FREE __GCC_ATOMIC_LONG_T_LOCK_FREE
-#define ATOMIC_LLONG_T_LOCK_FREE__GCC_ATOMIC_LLONG_T_LOCK_FREE
-#define ATOMIC_POINTER_T_LOCK_FREE  __GCC_ATOMIC_POINTER_T_LOCK_FREE
+#define ATOMIC_SHORT_LOCK_FREE  __GCC_ATOMIC_SHORT_LOCK_FREE
+#define ATOMIC_INT_LOCK_FREE__GCC_ATOMIC_INT_LOCK_FREE
+#define ATOMIC_LONG_LOCK_FREE   __GCC_ATOMIC_LONG_LOCK_FREE
+#define ATOMIC_LLONG_LOCK_FREE  __GCC_ATOMIC_LLONG_LOCK_FREE
+#define ATOMIC_POINTER_LOCK_FREE__GCC_ATOMIC_POINTER_LOCK_FREE
 
 /* 7.17.2 Initialization */
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


RE: RFC: Default language standard mode policy

2016-06-29 Thread Ristow, Warren via cfe-commits
Hi all,

>
> It may be feasible for us to use a "-std=gnu++latest" behavior and not have
> to have a PS4-specific default; CC'ing Warren and Paul.

As Sean pointed out, he did some tests and found we'd need to enable the GNU
keywords on PS4.  Having a PS4-specific patch for this wouldn't be a problem
for us, though.  So if the related issues mentioned in this thread for other
platforms (e.g., standard system headers needing GNU extensions enabled just
to parse them without error) are easily resolved, and so the default behavior
becomes to disable GNU keywords, it's easy enough for us to enable what we
need in this area for PS4.

>> Note that at this point I'd like to mainly focus on what our policy should
>> be; there are certainly technical challenges involved in actually applying
>> the policy (another one is that clang's test suite still has some failures
>> when the default is changed, but Charles Li has made tremendous headway on
>> this), and if we can't actually prepare for the transition in the C++
>> default in time for 3.9, then so be it.

Internally on PS4, we default to C++11.  FTR, the biggest issues we've had
on that point (by far) were clang's tests.  That's much less of a headache
today, due to Charles' work on this, but as you said, some failures remain.
I'd expect those could be dealt with in time for 3.9 without too much
difficulty if there was a strong desire to change the default that quickly.

That said, independent of what default is selected at 3.9, for PS4 we will
most likely prefer to stay with our current default (gnu++11) at 3.9.  We'll
revisit switching to 14 later, and consider future language dialect changes on
a case by case basis.

-Warren Ristow

From: Sean Silva [mailto:chisophu...@gmail.com]
Sent: Wednesday, June 29, 2016 1:35 PM
To: Richard Smith
Cc: cfe-commits; Clang Dev; Ristow, Warren; Robinson, Paul
Subject: Re: RFC: Default language standard mode policy



On Wed, Jun 29, 2016 at 1:34 PM, Sean Silva 
> wrote:


On Wed, Jun 29, 2016 at 12:51 PM, Richard Smith 
> wrote:
On Wed, Jun 29, 2016 at 12:30 PM, Sean Silva 
> wrote:


On Wed, Jun 29, 2016 at 12:09 PM, Richard Smith via cfe-commits 
> wrote:
Hi all!

I'd like to establish a policy for Clang's default language standard (if none 
is specified with -std), as follows:

  Clang defaults to the most recent published standard for the selected 
language that it fully implements.

The practical impact of this is that clang++ will default to C++14 for C++ 
compilations (for version 3.9 onwards) and will default to C++17 once our 
implementation support is complete and the standard is published (whichever 
happens later).

I'd suggest that we apply the same policy for clang-cl, but if it's important 
that we enable a not-yet-fully-implemented standard for cl compatibility, that 
seems reasonable.

The question of whether the default mode for the GCC-compatible driver should 
be -std=gnuXXX or -std=cXXX is separate, but also likely worth discussing. 
Enabling GNU keywords by default is a very odd choice, and if we believe we can 
change our defaults without breaking the world then this seems like a good time 
to do so.

Using cXXX instead of gnuXXX would break the world on PS4. So for sure with 
`-std=c++latest` we would end up proposing a patch to change this for the PS4 
target to gnu++latest (or gnu++11 if gnu++latest is not feasible).

OK. Out of interest, is it the GNU keywords that you need, or some other effect 
of the difference between modes?

A quick check of two titles I have at hand shows that at least `typeof` is in 
use.

(this check consisted of using -std=c++11 instead of -std=gnu++11 and seeing 
what breaks)

-- Sean Silva


-- Sean Silva


(As I'm sure you're aware, we have pending to upstream a patch that makes 
-std=gnu++11 the default C++ language mode on PS4 (just blocked on fixing tests 
to not assume the existing std)).

It may be feasible for us to use a "-std=gnu++latest" behavior and not have to 
have a PS4-specific default; CC'ing Warren and Paul.

-- Sean Silva


I also intend to make explicit in our documentation that our -std=XXX flag 
enables the selected standard, *plus all relevant issues in Defect Report 
status from the relevant language committee* (it doesn't make sense to support 
a language without its bugfixes).

Thoughts?

___
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: [PATCH] D21834: Implementing 'If statement with Initializer'

2016-06-29 Thread Anton Bikineev via cfe-commits
AntonBikineev updated this revision to Diff 62321.
AntonBikineev added a comment.

Test Parser/cxx1z-init-statement.cpp has been updated according to Sema changes


http://reviews.llvm.org/D21834

Files:
  include/clang/AST/Stmt.h
  include/clang/Sema/Sema.h
  lib/AST/ASTImporter.cpp
  lib/AST/Stmt.cpp
  lib/Analysis/BodyFarm.cpp
  lib/CodeGen/CGStmt.cpp
  lib/Sema/SemaStmt.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  test/Parser/cxx1z-init-statement.cpp

Index: test/Parser/cxx1z-init-statement.cpp
===
--- test/Parser/cxx1z-init-statement.cpp
+++ test/Parser/cxx1z-init-statement.cpp
@@ -4,17 +4,17 @@
 typedef int T;
 int f() {
   // init-statement declarations
-  if (T n = 0; n != 0) {} // expected-error {{not yet supported}}
-  if (T f(); f()) {} // expected-error {{not yet supported}}
-  if (T(f()); f()) {} // expected-error {{not yet supported}}
-  if (T(f()), g, h; f()) {} // expected-error {{not yet supported}}
-  if (T f(); f()) {} // expected-error {{not yet supported}}
-  if (T f(), g, h; f()) {} // expected-error {{not yet supported}}
+  if (T n = 0; n != 0) {}
+  if (T f(); f()) {}
+  if (T(f()); f()) {}
+  if (T(f()), g, h; f()) {}
+  if (T f(); f()) {}
+  if (T f(), g, h; f()) {}
 
   // init-statement expressions
-  if (T{f()}; f()) {} // expected-error {{not yet supported}}
-  if (T{f()}, g, h; f()) {} // expected-error {{not yet supported}} expected-warning 2{{unused}}
-  if (T(f()), g, h + 1; f()) {} // expected-error {{not yet supported}} expected-warning 2{{unused}}
+  if (T{f()}; f()) {}
+  if (T{f()}, g, h; f()) {} // expected-warning 2{{unused}}
+  if (T(f()), g, h + 1; f()) {} // expected-warning 2{{unused}}
 
   // condition declarations
   if (T(n){g}) {}
@@ -32,10 +32,10 @@
   //if (T(n)(g)) {} // expected-err-FIXME {{not a function}}
 
   // Likewise for 'switch'
-  switch (int n; n) {} // expected-error {{not yet supported}}
-  switch (g; int g = 5) {} // expected-error {{not yet supported}}
+  switch (int n; n) {}
+  switch (g; int g = 5) {}
 
-  if (int a, b; int c = a) { // expected-error {{not yet supported}} expected-note 6{{previous}}
+  if (int a, b; int c = a) { // expected-note 6{{previous}}
 int a; // expected-error {{redefinition}}
 int b; // expected-error {{redefinition}}
 int c; // expected-error {{redefinition}}
@@ -44,4 +44,6 @@
 int b; // expected-error {{redefinition}}
 int c; // expected-error {{redefinition}}
   }
+
+  return 0;
 }
Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -129,6 +129,7 @@
 void ASTStmtWriter::VisitIfStmt(IfStmt *S) {
   VisitStmt(S);
   Record.push_back(S->isConstexpr());
+  Record.AddStmt(S->getInit());
   Record.AddDeclRef(S->getConditionVariable());
   Record.AddStmt(S->getCond());
   Record.AddStmt(S->getThen());
@@ -140,6 +141,7 @@
 
 void ASTStmtWriter::VisitSwitchStmt(SwitchStmt *S) {
   VisitStmt(S);
+  Record.AddStmt(S->getInit());
   Record.AddDeclRef(S->getConditionVariable());
   Record.AddStmt(S->getCond());
   Record.AddStmt(S->getBody());
Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -185,6 +185,7 @@
 void ASTStmtReader::VisitIfStmt(IfStmt *S) {
   VisitStmt(S);
   S->setConstexpr(Record[Idx++]);
+  S->setInit(Reader.ReadSubStmt());
   S->setConditionVariable(Reader.getContext(),
   ReadDeclAs(Record, Idx));
   S->setCond(Reader.ReadSubExpr());
@@ -196,6 +197,7 @@
 
 void ASTStmtReader::VisitSwitchStmt(SwitchStmt *S) {
   VisitStmt(S);
+  S->setInit(Reader.ReadSubStmt());
   S->setConditionVariable(Reader.getContext(),
   ReadDeclAs(Record, Idx));
   S->setCond(Reader.ReadSubExpr());
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -1174,9 +1174,9 @@
   /// By default, performs semantic analysis to build the new statement.
   /// Subclasses may override this routine to provide different behavior.
   StmtResult RebuildIfStmt(SourceLocation IfLoc, bool IsConstexpr,
-   Sema::ConditionResult Cond, Stmt *Then,
+   Sema::ConditionResult Cond, Stmt *Init, Stmt *Then,
SourceLocation ElseLoc, Stmt *Else) {
-return getSema().ActOnIfStmt(IfLoc, IsConstexpr, nullptr, Cond, Then,
+return getSema().ActOnIfStmt(IfLoc, IsConstexpr, Init, Cond, Then,
  ElseLoc, Else);
   }
 
@@ -1185,8 +1185,9 @@
   /// By default, performs semantic analysis to build the new statement.
   /// Subclasses may override this routine to provide different 

Re: [PATCH] D21830: Remove -mrelax-all from Clang -O0

2016-06-29 Thread Dean Michael Berris via cfe-commits
dberris added a comment.

Changed the description to provide a justification.


http://reviews.llvm.org/D21830



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


Re: [PATCH] D21830: Remove -mrelax-all from Clang -O0

2016-06-29 Thread Rafael Espíndola via cfe-commits
On Wed, Jun 29, 2016, 17:43 Joerg Sonnenberger  wrote:

> On Wed, Jun 29, 2016 at 11:00:26AM -0400, Rafael Espíndola via cfe-commits
> wrote:
> > We need to benchmark this to see if it still makes a difference.
> >
> > My canonical test is the .s of a lto of clang.
>
> That won't exercise it? Assembler sources are exempt from this.
>
> Llvm-mc has the corresponding option.

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


r274190 - Use the same type for adjacent bit field members.

2016-06-29 Thread Akira Hatanaka via cfe-commits
Author: ahatanak
Date: Wed Jun 29 19:07:17 2016
New Revision: 274190

URL: http://llvm.org/viewvc/llvm-project?rev=274190=rev
Log:
Use the same type for adjacent bit field members.

MSVC doesn't pack the bit field members if different types are used.
This came up in a patch review.

http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160627/163107.html

Modified:
cfe/trunk/lib/AST/ExprConstant.cpp

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=274190=274189=274190=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Wed Jun 29 19:07:17 2016
@@ -158,13 +158,13 @@ namespace {
 /// True if the subobject was named in a manner not supported by C++11. 
Such
 /// lvalues can still be folded, but they are not core constant expressions
 /// and we cannot perform lvalue-to-rvalue conversions on them.
-bool Invalid : 1;
+unsigned Invalid : 1;
 
 /// Is this a pointer one past the end of an object?
-bool IsOnePastTheEnd : 1;
+unsigned IsOnePastTheEnd : 1;
 
 /// Indicator of whether the most-derived object is an array element.
-bool MostDerivedIsArrayElement : 1;
+unsigned MostDerivedIsArrayElement : 1;
 
 /// The length of the path to the most-derived object of which this is a
 /// subobject.
@@ -1058,7 +1058,7 @@ namespace {
   struct LValue {
 APValue::LValueBase Base;
 CharUnits Offset;
-bool InvalidBase : 1;
+unsigned InvalidBase : 1;
 unsigned CallIndex : 31;
 SubobjectDesignator Designator;
 


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


Re: [PATCH] D21834: Implementing 'If statement with Initializer'

2016-06-29 Thread Anton Bikineev via cfe-commits
AntonBikineev updated this revision to Diff 62317.

http://reviews.llvm.org/D21834

Files:
  include/clang/AST/Stmt.h
  include/clang/Sema/Sema.h
  lib/AST/ASTImporter.cpp
  lib/AST/Stmt.cpp
  lib/Analysis/BodyFarm.cpp
  lib/CodeGen/CGStmt.cpp
  lib/Sema/SemaStmt.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp

Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -129,6 +129,7 @@
 void ASTStmtWriter::VisitIfStmt(IfStmt *S) {
   VisitStmt(S);
   Record.push_back(S->isConstexpr());
+  Record.AddStmt(S->getInit());
   Record.AddDeclRef(S->getConditionVariable());
   Record.AddStmt(S->getCond());
   Record.AddStmt(S->getThen());
@@ -140,6 +141,7 @@
 
 void ASTStmtWriter::VisitSwitchStmt(SwitchStmt *S) {
   VisitStmt(S);
+  Record.AddStmt(S->getInit());
   Record.AddDeclRef(S->getConditionVariable());
   Record.AddStmt(S->getCond());
   Record.AddStmt(S->getBody());
Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -185,6 +185,7 @@
 void ASTStmtReader::VisitIfStmt(IfStmt *S) {
   VisitStmt(S);
   S->setConstexpr(Record[Idx++]);
+  S->setInit(Reader.ReadSubStmt());
   S->setConditionVariable(Reader.getContext(),
   ReadDeclAs(Record, Idx));
   S->setCond(Reader.ReadSubExpr());
@@ -196,6 +197,7 @@
 
 void ASTStmtReader::VisitSwitchStmt(SwitchStmt *S) {
   VisitStmt(S);
+  S->setInit(Reader.ReadSubStmt());
   S->setConditionVariable(Reader.getContext(),
   ReadDeclAs(Record, Idx));
   S->setCond(Reader.ReadSubExpr());
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -1174,9 +1174,9 @@
   /// By default, performs semantic analysis to build the new statement.
   /// Subclasses may override this routine to provide different behavior.
   StmtResult RebuildIfStmt(SourceLocation IfLoc, bool IsConstexpr,
-   Sema::ConditionResult Cond, Stmt *Then,
+   Sema::ConditionResult Cond, Stmt *Init, Stmt *Then,
SourceLocation ElseLoc, Stmt *Else) {
-return getSema().ActOnIfStmt(IfLoc, IsConstexpr, nullptr, Cond, Then,
+return getSema().ActOnIfStmt(IfLoc, IsConstexpr, Init, Cond, Then,
  ElseLoc, Else);
   }
 
@@ -1185,8 +1185,9 @@
   /// By default, performs semantic analysis to build the new statement.
   /// Subclasses may override this routine to provide different behavior.
   StmtResult RebuildSwitchStmtStart(SourceLocation SwitchLoc,
+Stmt *Init,
 Sema::ConditionResult Cond) {
-return getSema().ActOnStartOfSwitchStmt(SwitchLoc, nullptr, Cond);
+return getSema().ActOnStartOfSwitchStmt(SwitchLoc, Init, Cond);
   }
 
   /// \brief Attach the body to the switch statement.
@@ -6236,6 +6237,11 @@
 template
 StmtResult
 TreeTransform::TransformIfStmt(IfStmt *S) {
+  // Transform the initialization statement
+  StmtResult Init = getDerived().TransformStmt(S->getInit());
+  if (Init.isInvalid())
+return StmtError();
+
   // Transform the condition
   Sema::ConditionResult Cond = getDerived().TransformCondition(
   S->getIfLoc(), S->getConditionVariable(), S->getCond(),
@@ -6268,6 +6274,7 @@
   }
 
   if (!getDerived().AlwaysRebuild() &&
+  Init.get() == S->getInit() &&
   Cond.get() == std::make_pair(S->getConditionVariable(), S->getCond()) &&
   Then.get() == S->getThen() &&
   Else.get() == S->getElse())
@@ -6274,12 +6281,17 @@
 return S;
 
   return getDerived().RebuildIfStmt(S->getIfLoc(), S->isConstexpr(), Cond,
-Then.get(), S->getElseLoc(), Else.get());
+Init.get(), Then.get(), S->getElseLoc(), Else.get());
 }
 
 template
 StmtResult
 TreeTransform::TransformSwitchStmt(SwitchStmt *S) {
+  // Transform the initialization statement
+  StmtResult Init = getDerived().TransformStmt(S->getInit());
+  if (Init.isInvalid())
+return StmtError();
+
   // Transform the condition.
   Sema::ConditionResult Cond = getDerived().TransformCondition(
   S->getSwitchLoc(), S->getConditionVariable(), S->getCond(),
@@ -6289,7 +6301,8 @@
 
   // Rebuild the switch statement.
   StmtResult Switch
-= getDerived().RebuildSwitchStmtStart(S->getSwitchLoc(), Cond);
+= getDerived().RebuildSwitchStmtStart(S->getSwitchLoc(),
+  S->getInit(), Cond);
   if (Switch.isInvalid())
 return StmtError();
 
Index: lib/Sema/SemaStmt.cpp
===
--- 

Re: [PATCH] D21834: Implementing 'If statement with Initializer'

2016-06-29 Thread Anton Bikineev via cfe-commits
AntonBikineev added a comment.

@rsmith,

> This is not correct; TryParseSimpleDeclaration usually stops long before it 
> reaches the end of the simple-declaration, so this will give false negatives 
> in lots of cases.


Yes, I noticed that, that's why I changed use of TryParseSimpleDeclaration to 
something easier in last revision.

Thanks for reply, Richard. The revision you sent looks great, I should have 
updated my working copy before :)
Anyways, there are not too much of changes to Sema/AST stuff, I just applied 
them on top of yours, added the same for SwitchStmt. I'll update the test you 
put according to my changes tomorrow.


http://reviews.llvm.org/D21834



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


[PATCH] D21879: [libcxx] [test] Fix MSVC "warning C4100: 'argv': unreferenced formal parameter".

2016-06-29 Thread Stephan T. Lavavej via cfe-commits
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.

Fix MSVC "warning C4100: 'argv': unreferenced formal parameter".

http://reviews.llvm.org/D21879

Files:
  
test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp

Index: 
test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
===
--- 
test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
+++ 
test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
@@ -17,7 +17,7 @@
 #include 
 #include 
 
-int main(int, char const **argv) {
+int main() {
   std::ostrstream oss;
   std::string s;
 


Index: test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
===
--- test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
+++ test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
@@ -17,7 +17,7 @@
 #include 
 #include 
 
-int main(int, char const **argv) {
+int main() {
   std::ostrstream oss;
   std::string s;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D21878: [libcxx] [test] Make futures.overview/future_errc.pass.cpp and launch.pass.cpp more portable.

2016-06-29 Thread Stephan T. Lavavej via cfe-commits
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.

Make futures.overview/future_errc.pass.cpp and launch.pass.cpp more portable.

future_errc.pass.cpp was assuming specific values, which aren't guaranteed by 
the Standard, and MSVC uses different ones. Update the comment, and rewrite the 
tests to verify the Standard's guarantees of distinctness and nonzeroness.

launch.pass.cpp also contains non-Standard assumptions. They happen to be true 
for MSVC, with the exception of a static_assert about bitwise NOT. Apparently 
for libcxx, this operator modifies only 2 bits. For MSVC, it modifies all the 
bits in the representation. Mark this static_assert as libcxx-specific.

http://reviews.llvm.org/D21878

Files:
  test/std/thread/futures/futures.overview/future_errc.pass.cpp
  test/std/thread/futures/futures.overview/launch.pass.cpp

Index: test/std/thread/futures/futures.overview/launch.pass.cpp
===
--- test/std/thread/futures/futures.overview/launch.pass.cpp
+++ test/std/thread/futures/futures.overview/launch.pass.cpp
@@ -32,7 +32,7 @@
 LIBCPP_STATIC_ASSERT(std::launch::any == (std::launch::async | 
std::launch::deferred), "");
 static_assert(std::launch(0) == (std::launch::async & 
std::launch::deferred), "");
 LIBCPP_STATIC_ASSERT(std::launch::any == (std::launch::async ^ 
std::launch::deferred), "");
-static_assert(std::launch::deferred == ~std::launch::async, "");
+LIBCPP_STATIC_ASSERT(std::launch::deferred == ~std::launch::async, "");
 std::launch x = std::launch::async;
 x &= std::launch::deferred;
 assert(x == std::launch(0));
Index: test/std/thread/futures/futures.overview/future_errc.pass.cpp
===
--- test/std/thread/futures/futures.overview/future_errc.pass.cpp
+++ test/std/thread/futures/futures.overview/future_errc.pass.cpp
@@ -13,18 +13,25 @@
 
 // enum class future_errc
 // {
-// future_already_retrieved = 1,
-// promise_already_satisfied,
-// no_state
-// broken_promise,
+// broken_promise = implementation-defined,
+// future_already_retrieved = implementation-defined,
+// promise_already_satisfied = implementation-defined,
+// no_state = implementation-defined
 // };
 
 #include 
 
 int main()
 {
-static_assert(static_cast(std::future_errc::future_already_retrieved) 
== 1, "");
-
static_assert(static_cast(std::future_errc::promise_already_satisfied) == 
2, "");
-static_assert(static_cast(std::future_errc::no_state) == 3, "");
-static_assert(static_cast(std::future_errc::broken_promise) == 4, "");
+static_assert(std::future_errc::broken_promise != 
std::future_errc::future_already_retrieved, "");
+static_assert(std::future_errc::broken_promise != 
std::future_errc::promise_already_satisfied, "");
+static_assert(std::future_errc::broken_promise != 
std::future_errc::no_state, "");
+static_assert(std::future_errc::future_already_retrieved != 
std::future_errc::promise_already_satisfied, "");
+static_assert(std::future_errc::future_already_retrieved != 
std::future_errc::no_state, "");
+static_assert(std::future_errc::promise_already_satisfied != 
std::future_errc::no_state, "");
+
+static_assert(std::future_errc::broken_promise != 
static_cast(0), "");
+static_assert(std::future_errc::future_already_retrieved != 
static_cast(0), "");
+static_assert(std::future_errc::promise_already_satisfied != 
static_cast(0), "");
+static_assert(std::future_errc::no_state != 
static_cast(0), "");
 }


Index: test/std/thread/futures/futures.overview/launch.pass.cpp
===
--- test/std/thread/futures/futures.overview/launch.pass.cpp
+++ test/std/thread/futures/futures.overview/launch.pass.cpp
@@ -32,7 +32,7 @@
 LIBCPP_STATIC_ASSERT(std::launch::any == (std::launch::async | std::launch::deferred), "");
 static_assert(std::launch(0) == (std::launch::async & std::launch::deferred), "");
 LIBCPP_STATIC_ASSERT(std::launch::any == (std::launch::async ^ std::launch::deferred), "");
-static_assert(std::launch::deferred == ~std::launch::async, "");
+LIBCPP_STATIC_ASSERT(std::launch::deferred == ~std::launch::async, "");
 std::launch x = std::launch::async;
 x &= std::launch::deferred;
 assert(x == std::launch(0));
Index: test/std/thread/futures/futures.overview/future_errc.pass.cpp
===
--- test/std/thread/futures/futures.overview/future_errc.pass.cpp
+++ test/std/thread/futures/futures.overview/future_errc.pass.cpp
@@ -13,18 +13,25 @@
 
 // enum class future_errc
 // {
-// future_already_retrieved = 1,
-// promise_already_satisfied,
-// no_state
-// broken_promise,
+// broken_promise = implementation-defined,
+// 

[PATCH] D21877: [libcxx] [test] is_swappable_include_order.pass.cpp was using a terse static_assert.

2016-06-29 Thread Stephan T. Lavavej via cfe-commits
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.

is_swappable_include_order.pass.cpp was using a terse static_assert.

As before, this unnecessarily limits compatibility with MSVC and old versions 
of GCC.

http://reviews.llvm.org/D21877

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

Index: 
test/std/utilities/meta/meta.unary/meta.unary.prop/is_swappable_include_order.pass.cpp
===
--- 
test/std/utilities/meta/meta.unary/meta.unary.prop/is_swappable_include_order.pass.cpp
+++ 
test/std/utilities/meta/meta.unary/meta.unary.prop/is_swappable_include_order.pass.cpp
@@ -31,7 +31,7 @@
 {
 LIBCPP_STATIC_ASSERT(std::__is_swappable::value, "");
 #if TEST_STD_VER > 14
-static_assert(std::is_swappable_v);
+static_assert(std::is_swappable_v, "");
 #endif
 }
 {


Index: test/std/utilities/meta/meta.unary/meta.unary.prop/is_swappable_include_order.pass.cpp
===
--- test/std/utilities/meta/meta.unary/meta.unary.prop/is_swappable_include_order.pass.cpp
+++ test/std/utilities/meta/meta.unary/meta.unary.prop/is_swappable_include_order.pass.cpp
@@ -31,7 +31,7 @@
 {
 LIBCPP_STATIC_ASSERT(std::__is_swappable::value, "");
 #if TEST_STD_VER > 14
-static_assert(std::is_swappable_v);
+static_assert(std::is_swappable_v, "");
 #endif
 }
 {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D21876: [libcxx] [test] Make istreambuf.iterator/types.pass.cpp more portable.

2016-06-29 Thread Stephan T. Lavavej via cfe-commits
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.

Make istreambuf.iterator/types.pass.cpp more portable.

There are two issues here. First, istreambuf_iterator::pointer is unspecified 
(and MSVC uses a different type). Second, C++17 doesn't mandate std::iterator 
inheritance anymore (MSVC currently inherits, but we'll probably change this in 
the future).

These changes future-proof the test by inspecting the typedefs, and marking the 
pointer static_assert as libcxx-specific.

http://reviews.llvm.org/D21876

Files:
  test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp

Index: test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp
===
--- test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp
+++ test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp
@@ -33,12 +33,16 @@
 #include 
 #include 
 
+#include "test_macros.h"
+
 int main()
 {
 typedef std::istreambuf_iterator I1;
-static_assert((std::is_convertible >::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
@@ -49,9 +53,11 @@
 static_assert((std::is_trivially_destructible::value), "" );
 
 typedef std::istreambuf_iterator I2;
-static_assert((std::is_convertible >::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");


Index: test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp
===
--- test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp
+++ test/std/iterators/stream.iterators/istreambuf.iterator/types.pass.cpp
@@ -33,12 +33,16 @@
 #include 
 #include 
 
+#include "test_macros.h"
+
 int main()
 {
 typedef std::istreambuf_iterator I1;
-static_assert((std::is_convertible >::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
@@ -49,9 +53,11 @@
 static_assert((std::is_trivially_destructible::value), "" );
 
 typedef std::istreambuf_iterator I2;
-static_assert((std::is_convertible >::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 

[PATCH] D21875: [libcxx] [test] The Standard requires meow_insert_iterator::reference to be void.

2016-06-29 Thread Stephan T. Lavavej via cfe-commits
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.

The Standard requires meow_insert_iterator::reference to be void.

This is a libcxx product and test bug, since the type is observable. Mark these 
static_asserts as libcxx-specific, because MSVC follows the Standard strictly 
here.

http://reviews.llvm.org/D21875

Files:
  
test/std/iterators/predef.iterators/insert.iterators/back.insert.iterator/types.pass.cpp
  
test/std/iterators/predef.iterators/insert.iterators/front.insert.iterator/types.pass.cpp
  
test/std/iterators/predef.iterators/insert.iterators/insert.iterator/types.pass.cpp

Index: 
test/std/iterators/predef.iterators/insert.iterators/insert.iterator/types.pass.cpp
===
--- 
test/std/iterators/predef.iterators/insert.iterators/insert.iterator/types.pass.cpp
+++ 
test/std/iterators/predef.iterators/insert.iterators/insert.iterator/types.pass.cpp
@@ -30,6 +30,8 @@
 #include 
 #include 
 
+#include "test_macros.h"
+
 template 
 struct find_members
 : private std::insert_iterator
@@ -53,7 +55,7 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), 
"");
-static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 }
Index: 
test/std/iterators/predef.iterators/insert.iterators/front.insert.iterator/types.pass.cpp
===
--- 
test/std/iterators/predef.iterators/insert.iterators/front.insert.iterator/types.pass.cpp
+++ 
test/std/iterators/predef.iterators/insert.iterators/front.insert.iterator/types.pass.cpp
@@ -30,6 +30,8 @@
 #include 
 #include 
 
+#include "test_macros.h"
+
 template 
 struct find_container
 : private std::front_insert_iterator
@@ -49,7 +51,7 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), 
"");
-static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 }
Index: 
test/std/iterators/predef.iterators/insert.iterators/back.insert.iterator/types.pass.cpp
===
--- 
test/std/iterators/predef.iterators/insert.iterators/back.insert.iterator/types.pass.cpp
+++ 
test/std/iterators/predef.iterators/insert.iterators/back.insert.iterator/types.pass.cpp
@@ -29,6 +29,8 @@
 #include 
 #include 
 
+#include "test_macros.h"
+
 template 
 struct find_container
 : private std::back_insert_iterator
@@ -48,7 +50,7 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), 
"");
-static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 }


Index: test/std/iterators/predef.iterators/insert.iterators/insert.iterator/types.pass.cpp
===
--- test/std/iterators/predef.iterators/insert.iterators/insert.iterator/types.pass.cpp
+++ test/std/iterators/predef.iterators/insert.iterators/insert.iterator/types.pass.cpp
@@ -30,6 +30,8 @@
 #include 
 #include 
 
+#include "test_macros.h"
+
 template 
 struct find_members
 : private std::insert_iterator
@@ -53,7 +55,7 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 }
Index: test/std/iterators/predef.iterators/insert.iterators/front.insert.iterator/types.pass.cpp
===
--- test/std/iterators/predef.iterators/insert.iterators/front.insert.iterator/types.pass.cpp
+++ test/std/iterators/predef.iterators/insert.iterators/front.insert.iterator/types.pass.cpp
@@ -30,6 +30,8 @@
 #include 
 #include 
 
+#include "test_macros.h"
+
 template 
 struct find_container
 : private std::front_insert_iterator
@@ -49,7 +51,7 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 }
Index: 

[PATCH] D21874: [libcxx] [test] std::array's iterators aren't guaranteed to be pointers.

2016-06-29 Thread Stephan T. Lavavej via cfe-commits
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.

std::array's iterators aren't guaranteed to be pointers.

Include test_macros.h and mark these static_asserts as libcxx-specific.

http://reviews.llvm.org/D21874

Files:
  test/std/containers/sequences/array/types.pass.cpp

Index: test/std/containers/sequences/array/types.pass.cpp
===
--- test/std/containers/sequences/array/types.pass.cpp
+++ test/std/containers/sequences/array/types.pass.cpp
@@ -29,15 +29,17 @@
 #include 
 #include 
 
+#include "test_macros.h"
+
 int main()
 {
 {
 typedef double T;
 typedef std::array C;
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
@@ -57,8 +59,8 @@
 typedef std::array C;
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");


Index: test/std/containers/sequences/array/types.pass.cpp
===
--- test/std/containers/sequences/array/types.pass.cpp
+++ test/std/containers/sequences/array/types.pass.cpp
@@ -29,15 +29,17 @@
 #include 
 #include 
 
+#include "test_macros.h"
+
 int main()
 {
 {
 typedef double T;
 typedef std::array C;
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
@@ -57,8 +59,8 @@
 typedef std::array C;
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
-static_assert((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
+LIBCPP_STATIC_ASSERT((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D21872: [libcxx] [test] Fix unary_function inheritance assumption.

2016-06-29 Thread Stephan T. Lavavej via cfe-commits
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.

Fix unary_function inheritance assumption.

C++11 didn't require std::hash to derive from std::unary_function. The portable 
thing to do is to inspect the typedefs, as the other half of this test was 
already doing.

http://reviews.llvm.org/D21872

Files:
  test/std/containers/sequences/vector.bool/vector_bool.pass.cpp

Index: test/std/containers/sequences/vector.bool/vector_bool.pass.cpp
===
--- test/std/containers/sequences/vector.bool/vector_bool.pass.cpp
+++ test/std/containers/sequences/vector.bool/vector_bool.pass.cpp
@@ -41,8 +41,8 @@
 {
 typedef std::vector T;
 typedef std::hash H;
-static_assert((std::is_base_of,
-   H>::value), "");
+static_assert((std::is_same::value), "" );
+static_assert((std::is_same::value), "" );
 bool ba[] = {true, false, true, true, false};
 T vb(std::begin(ba), std::end(ba));
 H h;


Index: test/std/containers/sequences/vector.bool/vector_bool.pass.cpp
===
--- test/std/containers/sequences/vector.bool/vector_bool.pass.cpp
+++ test/std/containers/sequences/vector.bool/vector_bool.pass.cpp
@@ -41,8 +41,8 @@
 {
 typedef std::vector T;
 typedef std::hash H;
-static_assert((std::is_base_of,
-   H>::value), "");
+static_assert((std::is_same::value), "" );
+static_assert((std::is_same::value), "" );
 bool ba[] = {true, false, true, true, false};
 T vb(std::begin(ba), std::end(ba));
 H h;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D20602: Add .rgba syntax extension to ext_vector_type types

2016-06-29 Thread Pirama Arumuga Nainar via cfe-commits
pirama updated this revision to Diff 62305.
pirama added a comment.

Added GroupInfo to warning.


http://reviews.llvm.org/D20602

Files:
  include/clang/AST/Type.h
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/AST/Expr.cpp
  lib/Sema/SemaExprMember.cpp
  test/CodeGen/ext-vector.c
  test/Sema/ext_vector_components.c
  test/SemaOpenCL/ext_vectors.cl

Index: test/SemaOpenCL/ext_vectors.cl
===
--- /dev/null
+++ test/SemaOpenCL/ext_vectors.cl
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL1.1
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL2.0
+
+typedef float float4 __attribute__((ext_vector_type(4)));
+
+void test_ext_vector_accessors(float4 V) {
+  V = V.wzyx;
+  V = V.abgr; // expected-warning {{vector component name 'a' is an OpenCL version 2.2 feature}}
+  V = V.xyzr; // expected-warning {{vector component name 'r' is an OpenCL version 2.2 feature}} \
+  // expected-error {{illegal vector component name 'r'}}
+}
Index: test/Sema/ext_vector_components.c
===
--- test/Sema/ext_vector_components.c
+++ test/Sema/ext_vector_components.c
@@ -39,6 +39,33 @@
 vec4.x = vec16.sF;
   
 vec4p->yz = vec4p->xy;
+
+vec2.a; // expected-error {{vector component access exceeds type 'float2'}}
+vec2.rgba; // expected-error {{vector component access exceeds type 'float2'}}
+vec4.rgba; // expected-warning {{expression result unused}}
+vec4.rgbz; // expected-error {{illegal vector component name 'z'}}
+vec4.rgbc; // expected-error {{illegal vector component name 'c'}}
+vec4.xyzr; // expected-error {{illegal vector component name 'r'}}
+vec4.s01b; // expected-error {{vector component access exceeds type 'float4'}}
+
+vec3 = vec4.rgb; // legal, shorten
+f = vec2.r; // legal, shorten
+f = vec4.rg.r; // legal, shorten
+vec4_2.rgba = vec4.xyzw; // legal, no intermingling
+
+vec4_2.rgbr = vec4.rgba; // expected-error {{vector is not assignable (contains duplicate components)}}
+vec4_2.rgbb = vec4.rgba; // expected-error {{vector is not assignable (contains duplicate components)}}
+vec4_2.rgga = vec4.rgba; // expected-error {{vector is not assignable (contains duplicate components)}}
+vec2.x = f;
+vec2.rr = vec2_2.rg; // expected-error {{vector is not assignable (contains duplicate components)}}
+vec2.gr = vec2_2.rg;
+vec2.gr.g = vec2_2.r;
+vec4 = (float4){ 1,2,3,4 };
+vec4.rg.b; // expected-error {{vector component access exceeds type 'float2'}}
+vec4.r = vec16.sf;
+vec4.g = vec16.sF;
+
+vec4p->gb = vec4p->rg;
 }
 
 float2 lo(float3 x) { return x.lo; }
Index: test/CodeGen/ext-vector.c
===
--- test/CodeGen/ext-vector.c
+++ test/CodeGen/ext-vector.c
@@ -301,3 +301,40 @@
   char valC;
   char16 destVal = valC ? valA : valB;
 }
+
+typedef __attribute__(( ext_vector_type(16) )) float float16;
+
+float16 vec16, vec16_2;
+
+// CHECK: @test_rgba
+void test_rgba() {
+  // CHECK: fadd <4 x float>
+  vec4_2 = vec4.abgr + vec4;
+
+  // CHECK: shufflevector {{.*}} 
+  vec2 = vec4.rg;
+  // CHECK: shufflevector {{.*}} 
+  vec2_2 = vec4.ba;
+  // CHECK: extractelement {{.*}} 2
+  f = vec4.b;
+  // CHECK: shufflevector {{.*}} 
+  vec4_2 = vec4_2.;
+
+  // CHECK: insertelement {{.*}} 0
+  vec2.r = f;
+  // CHECK: shufflevector {{.*}} 
+  vec2.gr = vec2;
+
+  // CHECK: extractelement {{.*}} 0
+  f = vec4_2.rg.r;
+  // CHECK: shufflevector {{.*}} 
+  // CHECK: shufflevector {{.*}} 
+  // CHECK: shufflevector {{.*}} 
+  vec4.rgb = vec4.bgr;
+
+  // CHECK: extractelement {{.*}} 11
+  // CHECK: insertelement {{.*}} 2
+  vec4.b = vec16.sb;
+  // CHECK: shufflevector {{.*}} 
+  vec4_2 = vec16.sabcd;
+}
Index: lib/Sema/SemaExprMember.cpp
===
--- lib/Sema/SemaExprMember.cpp
+++ lib/Sema/SemaExprMember.cpp
@@ -268,6 +268,20 @@
   llvm_unreachable("unexpected instance member access kind");
 }
 
+/// Determine whether input char is from rgba component set.
+static bool
+IsRGBA(char c) {
+  switch (c) {
+  case 'r':
+  case 'g':
+  case 'b':
+  case 'a':
+return true;
+  default:
+return false;
+  }
+}
+
 /// Check an ext-vector component access expression.
 ///
 /// VK should be set in advance to the value kind of the base
@@ -307,11 +321,25 @@
 HalvingSwizzle = true;
   } else if (!HexSwizzle &&
  (Idx = vecType->getPointAccessorIdx(*compStr)) != -1) {
+bool HasRGBA = IsRGBA(*compStr);
 do {
+  // Ensure that xyzw and rgba components don't intermingle.
+  if (HasRGBA != IsRGBA(*compStr))
+break;
   if (HasIndex[Idx]) HasRepeated = true;
   HasIndex[Idx] = true;
   compStr++;
 } while (*compStr && (Idx = 

[PATCH] D21871: [libcxx] [test] Make vector.bool/construct_default.pass.cpp more portable.

2016-06-29 Thread Stephan T. Lavavej via cfe-commits
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.

Make vector.bool/construct_default.pass.cpp more portable.

vector's default ctor and allocator ctor aren't depicted as noexcept in 
the Working Paper. We're already directly including test_macros.h, so use 
LIBCPP_STATIC_ASSERT.

http://reviews.llvm.org/D21871

Files:
  test/std/containers/sequences/vector.bool/construct_default.pass.cpp

Index: test/std/containers/sequences/vector.bool/construct_default.pass.cpp
===
--- test/std/containers/sequences/vector.bool/construct_default.pass.cpp
+++ test/std/containers/sequences/vector.bool/construct_default.pass.cpp
@@ -24,7 +24,7 @@
 test0()
 {
 #if TEST_STD_VER > 14
-   static_assert((noexcept(C{})), "" );
+   LIBCPP_STATIC_ASSERT((noexcept(C{})), "" );
 #elif TEST_STD_VER >= 11
static_assert((noexcept(C()) == noexcept(typename 
C::allocator_type())), "" );
 #endif
@@ -45,7 +45,7 @@
 test1(const typename C::allocator_type& a)
 {
 #if TEST_STD_VER > 14
-   static_assert((noexcept(C{typename C::allocator_type{}})), "" );
+   LIBCPP_STATIC_ASSERT((noexcept(C{typename C::allocator_type{}})), "" );
 #elif TEST_STD_VER >= 11
static_assert((noexcept(C(typename C::allocator_type())) == 
std::is_nothrow_copy_constructible::value), "" );
 #endif


Index: test/std/containers/sequences/vector.bool/construct_default.pass.cpp
===
--- test/std/containers/sequences/vector.bool/construct_default.pass.cpp
+++ test/std/containers/sequences/vector.bool/construct_default.pass.cpp
@@ -24,7 +24,7 @@
 test0()
 {
 #if TEST_STD_VER > 14
-	static_assert((noexcept(C{})), "" );
+	LIBCPP_STATIC_ASSERT((noexcept(C{})), "" );
 #elif TEST_STD_VER >= 11
 	static_assert((noexcept(C()) == noexcept(typename C::allocator_type())), "" );
 #endif
@@ -45,7 +45,7 @@
 test1(const typename C::allocator_type& a)
 {
 #if TEST_STD_VER > 14
-	static_assert((noexcept(C{typename C::allocator_type{}})), "" );
+	LIBCPP_STATIC_ASSERT((noexcept(C{typename C::allocator_type{}})), "" );
 #elif TEST_STD_VER >= 11
 	static_assert((noexcept(C(typename C::allocator_type())) == std::is_nothrow_copy_constructible::value), "" );
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D21870: [libcxx] [test] Avoid applying unary minus to unsigned integers.

2016-06-29 Thread Stephan T. Lavavej via cfe-commits
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.

Avoid applying unary minus to unsigned integers.

This is confusing because first you have to remember what unsigned negation 
does, then you have to worry about the usual arithmetic conversions during the 
comparison. It's simpler to express the most negative values as "blah - 1" 
expressions, and then the only UAC involved is widening int to long long and 
that's easy.

Fixes MSVC warning/error C4146 "unary minus operator applied to unsigned type, 
result still unsigned".

http://reviews.llvm.org/D21870

Files:
  test/std/depr/depr.c.headers/stdint_h.pass.cpp
  test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp

Index: test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp
===
--- test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp
+++ test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp
@@ -172,8 +172,8 @@
 // INTN_MIN
 static_assert(INT8_MIN == -128, "INT8_MIN == -128");
 static_assert(INT16_MIN == -32768, "INT16_MIN == -32768");
-static_assert(INT32_MIN == -2147483648U, "INT32_MIN == -2147483648");
-static_assert(INT64_MIN == -9223372036854775808ULL, "INT64_MIN == 
-9223372036854775808LL");
+static_assert(INT32_MIN == -2147483647 - 1, "INT32_MIN == -2147483648");
+static_assert(INT64_MIN == -9223372036854775807LL - 1, "INT64_MIN == 
-9223372036854775808LL");
 
 // INTN_MAX
 static_assert(INT8_MAX == 127, "INT8_MAX == 127");
@@ -190,8 +190,8 @@
 // INT_FASTN_MIN
 static_assert(INT_FAST8_MIN <= -128, "INT_FAST8_MIN <= -128");
 static_assert(INT_FAST16_MIN <= -32768, "INT_FAST16_MIN <= -32768");
-static_assert(INT_FAST32_MIN <= -2147483648U, "INT_FAST32_MIN <= 
-2147483648");
-static_assert(INT_FAST64_MIN <= -9223372036854775808ULL, "INT_FAST64_MIN 
<= -9223372036854775808LL");
+static_assert(INT_FAST32_MIN <= -2147483647 - 1, "INT_FAST32_MIN <= 
-2147483648");
+static_assert(INT_FAST64_MIN <= -9223372036854775807LL - 1, 
"INT_FAST64_MIN <= -9223372036854775808LL");
 
 // INT_FASTN_MAX
 static_assert(INT_FAST8_MAX >= 127, "INT_FAST8_MAX >= 127");
Index: test/std/depr/depr.c.headers/stdint_h.pass.cpp
===
--- test/std/depr/depr.c.headers/stdint_h.pass.cpp
+++ test/std/depr/depr.c.headers/stdint_h.pass.cpp
@@ -171,8 +171,8 @@
 // INTN_MIN
 static_assert(INT8_MIN == -128, "INT8_MIN == -128");
 static_assert(INT16_MIN == -32768, "INT16_MIN == -32768");
-static_assert(INT32_MIN == -2147483648U, "INT32_MIN == -2147483648");
-static_assert(INT64_MIN == -9223372036854775808ULL, "INT64_MIN == 
-9223372036854775808LL");
+static_assert(INT32_MIN == -2147483647 - 1, "INT32_MIN == -2147483648");
+static_assert(INT64_MIN == -9223372036854775807LL - 1, "INT64_MIN == 
-9223372036854775808LL");
 
 // INTN_MAX
 static_assert(INT8_MAX == 127, "INT8_MAX == 127");
@@ -189,8 +189,8 @@
 // INT_FASTN_MIN
 static_assert(INT_FAST8_MIN <= -128, "INT_FAST8_MIN <= -128");
 static_assert(INT_FAST16_MIN <= -32768, "INT_FAST16_MIN <= -32768");
-static_assert(INT_FAST32_MIN <= -2147483648U, "INT_FAST32_MIN <= 
-2147483648");
-static_assert(INT_FAST64_MIN <= -9223372036854775808ULL, "INT_FAST64_MIN 
<= -9223372036854775808LL");
+static_assert(INT_FAST32_MIN <= -2147483647 - 1, "INT_FAST32_MIN <= 
-2147483648");
+static_assert(INT_FAST64_MIN <= -9223372036854775807LL - 1, 
"INT_FAST64_MIN <= -9223372036854775808LL");
 
 // INT_FASTN_MAX
 static_assert(INT_FAST8_MAX >= 127, "INT_FAST8_MAX >= 127");


Index: test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp
===
--- test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp
+++ test/std/language.support/cstdint/cstdint.syn/cstdint.pass.cpp
@@ -172,8 +172,8 @@
 // INTN_MIN
 static_assert(INT8_MIN == -128, "INT8_MIN == -128");
 static_assert(INT16_MIN == -32768, "INT16_MIN == -32768");
-static_assert(INT32_MIN == -2147483648U, "INT32_MIN == -2147483648");
-static_assert(INT64_MIN == -9223372036854775808ULL, "INT64_MIN == -9223372036854775808LL");
+static_assert(INT32_MIN == -2147483647 - 1, "INT32_MIN == -2147483648");
+static_assert(INT64_MIN == -9223372036854775807LL - 1, "INT64_MIN == -9223372036854775808LL");
 
 // INTN_MAX
 static_assert(INT8_MAX == 127, "INT8_MAX == 127");
@@ -190,8 +190,8 @@
 // INT_FASTN_MIN
 static_assert(INT_FAST8_MIN <= -128, "INT_FAST8_MIN <= -128");
 static_assert(INT_FAST16_MIN <= -32768, "INT_FAST16_MIN <= -32768");
-static_assert(INT_FAST32_MIN <= -2147483648U, "INT_FAST32_MIN <= -2147483648");
-static_assert(INT_FAST64_MIN <= -9223372036854775808ULL, "INT_FAST64_MIN <= -9223372036854775808LL");
+

Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread Dimitry Ivanov via cfe-commits
dimitry added a subscriber: dimitry.


Comment at: src/cxa_thread_atexit.cpp:46
@@ +45,3 @@
+  pthread_key_delete(key_);
+}
+

run_dtors() is called when/if libc++.so gets unloaded... but only for the 
thread calling dlclose()?


http://reviews.llvm.org/D21803



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


[PATCH] D21868: [CUDA] Rename member variables in CudaInstallationDetector.

2016-06-29 Thread Justin Lebar via cfe-commits
jlebar created this revision.
jlebar added a reviewer: tra.
jlebar added a subscriber: cfe-commits.

Remove the "Cuda" prefix from these variables -- it's clear that they
related to CUDA given their containing type.

http://reviews.llvm.org/D21868

Files:
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h

Index: lib/Driver/ToolChains.h
===
--- lib/Driver/ToolChains.h
+++ lib/Driver/ToolChains.h
@@ -158,39 +158,39 @@
   GCCInstallationDetector GCCInstallation;
 
   // \brief A class to find a viable CUDA installation
-
   class CudaInstallationDetector {
-bool IsValid;
+  private:
 const Driver 
-std::string CudaInstallPath;
-std::string CudaBinPath;
-std::string CudaLibPath;
-std::string CudaLibDevicePath;
-std::string CudaIncludePath;
-llvm::StringMap CudaLibDeviceMap;
+bool IsValid = false;
+std::string InstallPath;
+std::string BinPath;
+std::string LibPath;
+std::string LibDevicePath;
+std::string IncludePath;
+llvm::StringMap LibDeviceMap;
 
   public:
-CudaInstallationDetector(const Driver ) : IsValid(false), D(D) {}
+CudaInstallationDetector(const Driver ) : D(D) {}
 void init(const llvm::Triple , const llvm::opt::ArgList );
 
 /// \brief Check whether we detected a valid Cuda install.
 bool isValid() const { return IsValid; }
 /// \brief Print information about the detected CUDA installation.
 void print(raw_ostream ) const;
 
 /// \brief Get the detected Cuda installation path.
-StringRef getInstallPath() const { return CudaInstallPath; }
+StringRef getInstallPath() const { return InstallPath; }
 /// \brief Get the detected path to Cuda's bin directory.
-StringRef getBinPath() const { return CudaBinPath; }
+StringRef getBinPath() const { return BinPath; }
 /// \brief Get the detected Cuda Include path.
-StringRef getIncludePath() const { return CudaIncludePath; }
+StringRef getIncludePath() const { return IncludePath; }
 /// \brief Get the detected Cuda library path.
-StringRef getLibPath() const { return CudaLibPath; }
+StringRef getLibPath() const { return LibPath; }
 /// \brief Get the detected Cuda device library path.
-StringRef getLibDevicePath() const { return CudaLibDevicePath; }
+StringRef getLibDevicePath() const { return LibDevicePath; }
 /// \brief Get libdevice file for given architecture
 std::string getLibDeviceFile(StringRef Gpu) const {
-  return CudaLibDeviceMap.lookup(Gpu);
+  return LibDeviceMap.lookup(Gpu);
 }
   };
 
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -1721,20 +1721,19 @@
 if (CudaPath.empty() || !D.getVFS().exists(CudaPath))
   continue;
 
-CudaInstallPath = CudaPath;
-CudaBinPath = CudaPath + "/bin";
-CudaIncludePath = CudaInstallPath + "/include";
-CudaLibDevicePath = CudaInstallPath + "/nvvm/libdevice";
-CudaLibPath =
-CudaInstallPath + (TargetTriple.isArch64Bit() ? "/lib64" : "/lib");
+InstallPath = CudaPath;
+BinPath = CudaPath + "/bin";
+IncludePath = InstallPath + "/include";
+LibDevicePath = InstallPath + "/nvvm/libdevice";
+LibPath = InstallPath + (TargetTriple.isArch64Bit() ? "/lib64" : "/lib");
 
-if (!(D.getVFS().exists(CudaIncludePath) &&
-  D.getVFS().exists(CudaBinPath) && D.getVFS().exists(CudaLibPath) &&
-  D.getVFS().exists(CudaLibDevicePath)))
+auto  = D.getVFS();
+if (!(FS.exists(IncludePath) && FS.exists(BinPath) && FS.exists(LibPath) &&
+  FS.exists(LibDevicePath)))
   continue;
 
 std::error_code EC;
-for (llvm::sys::fs::directory_iterator LI(CudaLibDevicePath, EC), LE;
+for (llvm::sys::fs::directory_iterator LI(LibDevicePath, EC), LE;
  !EC && LI != LE; LI = LI.increment(EC)) {
   StringRef FilePath = LI->path();
   StringRef FileName = llvm::sys::path::filename(FilePath);
@@ -1744,24 +1743,24 @@
 continue;
   StringRef GpuArch = FileName.slice(
   LibDeviceName.size(), FileName.find('.', LibDeviceName.size()));
-  CudaLibDeviceMap[GpuArch] = FilePath.str();
+  LibDeviceMap[GpuArch] = FilePath.str();
   // Insert map entries for specifc devices with this compute capability.
   if (GpuArch == "compute_20") {
-CudaLibDeviceMap["sm_20"] = FilePath;
-CudaLibDeviceMap["sm_21"] = FilePath;
+LibDeviceMap["sm_20"] = FilePath;
+LibDeviceMap["sm_21"] = FilePath;
   } else if (GpuArch == "compute_30") {
-CudaLibDeviceMap["sm_30"] = FilePath;
-CudaLibDeviceMap["sm_32"] = FilePath;
+LibDeviceMap["sm_30"] = FilePath;
+LibDeviceMap["sm_32"] = FilePath;
   } else if (GpuArch == "compute_35") {
-CudaLibDeviceMap["sm_35"] = FilePath;
-CudaLibDeviceMap["sm_37"] = 

[PATCH] D21869: [CUDA] Check that our CUDA install supports the requested architectures.

2016-06-29 Thread Justin Lebar via cfe-commits
jlebar created this revision.
jlebar added a reviewer: tra.
jlebar added a subscriber: cfe-commits.

Raise an error if you're using a CUDA installation that's too old for
the requested architectures.  In practice, this means that you need a
CUDA 8 install to compile for sm_6*.

http://reviews.llvm.org/D21869

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/Driver/Options.td
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  test/Driver/Inputs/CUDA_80/usr/local/cuda/bin/.keep
  test/Driver/Inputs/CUDA_80/usr/local/cuda/include/.keep
  test/Driver/Inputs/CUDA_80/usr/local/cuda/lib/.keep
  test/Driver/Inputs/CUDA_80/usr/local/cuda/lib64/.keep
  
test/Driver/Inputs/CUDA_80/usr/local/cuda/nvvm/libdevice/libdevice.compute_20.10.bc
  
test/Driver/Inputs/CUDA_80/usr/local/cuda/nvvm/libdevice/libdevice.compute_35.10.bc
  test/Driver/Inputs/CUDA_80/usr/local/cuda/version.txt
  test/Driver/cuda-version-check.cu

Index: test/Driver/cuda-version-check.cu
===
--- /dev/null
+++ test/Driver/cuda-version-check.cu
@@ -0,0 +1,51 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: %clang -v -### --cuda-gpu-arch=sm_20 --sysroot=%S/Inputs/CUDA 2>&1 %s | \
+// RUN:FileCheck %s --check-prefix=OK
+// RUN: %clang -v -### --cuda-gpu-arch=sm_20 --sysroot=%S/Inputs/CUDA_80 2>&1 %s | \
+// RUN:FileCheck %s --check-prefix=OK
+// RUN: %clang -v -### --cuda-gpu-arch=sm_60 --sysroot=%S/Inputs/CUDA_80 2>&1 %s | \
+// RUN:FileCheck %s --check-prefix=OK
+
+// The installation at Inputs/CUDA is CUDA 7.0, which doesn't support sm_60.
+// RUN: %clang -v -### --cuda-gpu-arch=sm_60 --sysroot=%S/Inputs/CUDA 2>&1 %s | \
+// RUN:FileCheck %s --check-prefix=ERR_SM60
+
+// This should only complain about sm_60, not sm_35.
+// RUN: %clang -v -### --cuda-gpu-arch=sm_60 --cuda-gpu-arch=sm_35 \
+// RUN:--sysroot=%S/Inputs/CUDA 2>&1 %s | \
+// RUN:FileCheck %s --check-prefix=ERR_SM60 --check-prefix=OK_SM35
+
+// We should get two errors here, one for sm_60 and one for sm_61.
+// RUN: %clang -v -### --cuda-gpu-arch=sm_60 --cuda-gpu-arch=sm_61 \
+// RUN:--sysroot=%S/Inputs/CUDA 2>&1 %s | \
+// RUN:FileCheck %s --check-prefix=ERR_SM60 --check-prefix=ERR_SM61
+
+// We should still get an error if we pass -nocudainc, because this compilation
+// would invoke ptxas, and we do a version check on that, too.
+// RUN: %clang -v -### --cuda-gpu-arch=sm_60 -nocudainc --sysroot=%S/Inputs/CUDA 2>&1 %s | \
+// RUN:FileCheck %s --check-prefix=ERR_SM60
+
+// If with -nocudainc and -E, we don't touch the CUDA install, so we
+// shouldn't get an error.
+// RUN: %clang -v -### -E --cuda-device-only --cuda-gpu-arch=sm_60 -nocudainc \
+// RUN:--sysroot=%S/Inputs/CUDA 2>&1 %s | \
+// RUN:FileCheck %s --check-prefix=OK
+
+// -nocuda-version-check should suppress all of these errors.
+// RUN: %clang -v -### --cuda-gpu-arch=sm_60 --sysroot=%S/Inputs/CUDA 2>&1 \
+// RUN:-nocuda-version-check %s | \
+// RUN:FileCheck %s --check-prefix=OK
+
+// OK-NOT: error: GPU arch
+
+// OK_SM35-NOT: error: GPU arch sm_35
+
+// We should only get one error per architecture.
+// ERR_SM60: error: GPU arch sm_60 {{.*}}
+// ERR_SM60-NOT: error: GPU arch sm_60
+
+// ERR_SM61: error: GPU arch sm_61 {{.*}}
+// ERR_SM61-NOT: error: GPU arch sm_61
Index: test/Driver/Inputs/CUDA_80/usr/local/cuda/version.txt
===
--- /dev/null
+++ test/Driver/Inputs/CUDA_80/usr/local/cuda/version.txt
@@ -0,0 +1 @@
+CUDA Version 8.0.42
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -11078,6 +11078,12 @@
   assert(gpu_archs.size() == 1 && "Exactly one GPU Arch required for ptxas.");
   const std::string& gpu_arch = gpu_archs[0];
 
+  // Check that our installation's ptxas supports gpu_arch.
+  if (!Args.hasArg(options::OPT_nocuda_version_check)) {
+TC.cudaInstallation().CheckCudaVersionSupportsArch(
+StringToCudaArch(gpu_arch));
+  }
+
   ArgStringList CmdArgs;
   CmdArgs.push_back(TC.getTriple().isArch64Bit() ? "-m64" : "-m32");
   if (Args.hasFlag(options::OPT_cuda_noopt_device_debug,
Index: lib/Driver/ToolChains.h
===
--- lib/Driver/ToolChains.h
+++ lib/Driver/ToolChains.h
@@ -11,12 +11,14 @@
 #define LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_H
 
 #include "Tools.h"
+#include "clang/Basic/Cuda.h"
 #include "clang/Basic/VersionTuple.h"
 #include "clang/Driver/Action.h"
 #include "clang/Driver/Multilib.h"
 #include "clang/Driver/ToolChain.h"
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/Optional.h"
+#include "llvm/ADT/SmallSet.h"
 #include "llvm/Support/Compiler.h"
 #include 
 #include 
@@ -162,22 +164,35 @@
   private:
 const Driver 
 bool IsValid = false;
+  

[PATCH] D21867: [CUDA] Add utility functions for dealing with CUDA versions / architectures.

2016-06-29 Thread Justin Lebar via cfe-commits
jlebar created this revision.
jlebar added a reviewer: tra.
jlebar added a subscriber: cfe-commits.

Currently our handling of CUDA architectures is scattered all around
clang.  This patch centralizes it.

A key advantage of this centralization is that you can now write a C++
switch on e.g. CudaArch and get a compile error if you don't handle one
of the enum values.

http://reviews.llvm.org/D21867

Files:
  include/clang/Basic/Cuda.h
  include/clang/Driver/Action.h
  lib/Basic/CMakeLists.txt
  lib/Basic/Cuda.cpp
  lib/Basic/Targets.cpp
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -11154,9 +11154,10 @@
 auto* A = cast(II.getAction());
 // We need to pass an Arch of the form "sm_XX" for cubin files and
 // "compute_XX" for ptx.
-const char *Arch = (II.getType() == types::TY_PP_Asm)
-   ? A->getComputeArchName()
-   : A->getGpuArchName();
+const char *Arch =
+(II.getType() == types::TY_PP_Asm)
+? CudaVirtualArchToString(VirtualArchForCudaArch(A->getGpuArch()))
+: CudaArchToString(A->getGpuArch());
 CmdArgs.push_back(Args.MakeArgString(llvm::Twine("--image=profile=") +
  Arch + ",file=" + II.getFilename()));
   }
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -23,6 +23,7 @@
 #include "clang/Driver/ToolChain.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/SmallSet.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSet.h"
 #include "llvm/ADT/StringSwitch.h"
@@ -1022,8 +1023,9 @@
 os << '"' << BIA->getArchName() << '"' << ", {"
<< PrintActions1(C, *BIA->input_begin(), Ids) << "}";
   } else if (CudaDeviceAction *CDA = dyn_cast(A)) {
-os << '"'
-   << (CDA->getGpuArchName() ? CDA->getGpuArchName() : "(multiple archs)")
+os << '"' << (CDA->getGpuArch() != CudaArch::UNKNOWN
+  ? CudaArchToString(CDA->getGpuArch())
+  : "(multiple archs)")
<< '"' << ", {" << PrintActions1(C, *CDA->input_begin(), Ids) << "}";
   } else {
 const ActionList *AL;
@@ -1380,24 +1382,25 @@
 return C.MakeAction(HostAction, ActionList());
 
   // Collect all cuda_gpu_arch parameters, removing duplicates.
-  SmallVector GpuArchList;
-  llvm::StringSet<> GpuArchNames;
+  SmallVector GpuArchList;
+  llvm::SmallSet GpuArchs;
   for (Arg *A : Args) {
 if (!A->getOption().matches(options::OPT_cuda_gpu_arch_EQ))
   continue;
 A->claim();
 
-const auto& Arch = A->getValue();
-if (!CudaDeviceAction::IsValidGpuArchName(Arch))
-  C.getDriver().Diag(clang::diag::err_drv_cuda_bad_gpu_arch) << Arch;
-else if (GpuArchNames.insert(Arch).second)
+const auto  = A->getValue();
+CudaArch Arch = StringToCudaArch(ArchStr);
+if (Arch == CudaArch::UNKNOWN)
+  C.getDriver().Diag(clang::diag::err_drv_cuda_bad_gpu_arch) << ArchStr;
+else if (GpuArchs.insert(Arch).second)
   GpuArchList.push_back(Arch);
   }
 
   // Default to sm_20 which is the lowest common denominator for supported GPUs.
   // sm_20 code should work correctly, if suboptimally, on all newer GPUs.
   if (GpuArchList.empty())
-GpuArchList.push_back("sm_20");
+GpuArchList.push_back(CudaArch::SM_20);
 
   // Replicate inputs for each GPU architecture.
   Driver::InputList CudaDeviceInputs;
@@ -1463,7 +1466,7 @@
   }
   auto FatbinAction = C.MakeAction(
   C.MakeAction(DeviceActions, types::TY_CUDA_FATBIN),
-  /* GpuArchName = */ nullptr,
+  CudaArch::UNKNOWN,
   /* AtTopLevel = */ false);
   // Return a new host action that incorporates original host action and all
   // device actions.
@@ -2047,8 +2050,8 @@
 // Call BuildJobsForAction() again, now with correct device parameters.
 InputInfo II = BuildJobsForAction(
 C, *CDA->input_begin(), C.getSingleOffloadToolChain(),
-CDA->getGpuArchName(), CDA->isAtTopLevel(), /*MultipleArchs=*/true,
-LinkingOutput, CachedResults);
+CudaArchToString(CDA->getGpuArch()), CDA->isAtTopLevel(),
+/*MultipleArchs=*/true, LinkingOutput, CachedResults);
 // Currently II's Action is *CDA->input_begin().  Set it to CDA instead, so
 // that one can retrieve II's GPU arch.
 II.setAction(A);
Index: lib/Driver/Action.cpp
===
--- lib/Driver/Action.cpp
+++ lib/Driver/Action.cpp
@@ -51,43 +51,11 @@
 BindArchAction::BindArchAction(Action *Input, const char *_ArchName)
 : Action(BindArchClass, Input), ArchName(_ArchName) {}
 
-// Converts CUDA GPU architecture, e.g. "sm_21", to its corresponding virtual
-// 

Re: [PATCH] D21666: [Tooling] Add optional argument to getFullyQualifiedName to prepend "::".

2016-06-29 Thread Siva Chandra via cfe-commits
sivachandra added a comment.

Thanks for the review; Committed.


http://reviews.llvm.org/D21666



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


Re: [cfe-dev] RFC: Default language standard mode policy

2016-06-29 Thread Richard Smith via cfe-commits
On Wed, Jun 29, 2016 at 2:48 PM, Joerg Sonnenberger via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Wed, Jun 29, 2016 at 12:09:37PM -0700, Richard Smith via cfe-dev wrote:
> > Hi all!
> >
> > I'd like to establish a policy for Clang's default language standard (if
> > none is specified with -std), as follows:
> >
> >   Clang defaults to the most recent published standard for the selected
> > language that it fully implements.
> >
> > The practical impact of this is that clang++ will default to C++14 for
> C++
> > compilations (for version 3.9 onwards) and will default to C++17 once our
> > implementation support is complete and the standard is published
> (whichever
> > happens later).
>
> I don't have a problem with the C11 default, because the language impact
> is minimal. That's quite different from C++ though and I am very
> reluctant to update the default language even to C++11. There is a lot
> of code in the wild that doesn't compile anymore due to stupid changes
> like user-defined string literals or the narrowing (warning) changes.
> Even worse are the nothrow changes for destructors, which silently break
> valid C++03 code.


Yes, those are real problems, but it's not reasonable for us to keep the
default at C++98/03 forever. GCC has already taken the plunge here, so a
lot of open-source code that doesn't work in C++11 onwards already
explicitly specifies an appropriate -std= flag.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r274176 - [cmake] Instead of just copying ClangConfig.cmake, configure it using ClangConfig.cmake.in.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 16:59:14 2016
New Revision: 274176

URL: http://llvm.org/viewvc/llvm-project?rev=274176=rev
Log:
[cmake] Instead of just copying ClangConfig.cmake, configure it using 
ClangConfig.cmake.in.

This will allow for cmake to expand variables in ClangConfig.cmake for
downstream users.

Added:
cfe/trunk/cmake/modules/ClangConfig.cmake.in
  - copied, changed from r274169, cfe/trunk/cmake/modules/ClangConfig.cmake
Removed:
cfe/trunk/cmake/modules/ClangConfig.cmake
Modified:
cfe/trunk/cmake/modules/CMakeLists.txt

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274176=274175=274176=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 16:59:14 2016
@@ -3,20 +3,24 @@
 # the usual CMake convention seems to be ${Project}Targets.cmake.
 set(CLANG_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
 set(clang_cmake_builddir "${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}")
+
 get_property(CLANG_EXPORTS GLOBAL PROPERTY CLANG_EXPORTS)
 export(TARGETS ${CLANG_EXPORTS} FILE 
${clang_cmake_builddir}/ClangTargets.cmake)
 
-# Install a /lib/cmake/clang/ClangConfig.cmake file so that
-# find_package(Clang) works. Install the target list with it.
+# Generate ClangConfig.cmake for the build tree.
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
+  ${clang_cmake_builddir}/ClangConfig.cmake
+  @ONLY)
+
+# Generate ClangConfig.cmake for the install tree.
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
+  ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
+  @ONLY)
+
 install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
 
 install(FILES
-  ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
+  ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
   DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
-
-# Also copy ClangConfig.cmake to the build directory so that dependent projects
-# can build against a build directory of Clang more easily.
-configure_file(
-  ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
-  ${clang_cmake_builddir}/ClangConfig.cmake
-  COPYONLY)

Removed: cfe/trunk/cmake/modules/ClangConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/ClangConfig.cmake?rev=274175=auto
==
--- cfe/trunk/cmake/modules/ClangConfig.cmake (original)
+++ cfe/trunk/cmake/modules/ClangConfig.cmake (removed)
@@ -1,10 +0,0 @@
-# This file allows users to call find_package(Clang) and pick up our targets.
-
-# Clang doesn't have any CMake configuration settings yet because it mostly
-# uses LLVM's. When it does, we should move this file to ClangConfig.cmake.in
-# and call configure_file() on it.
-
-find_package(LLVM REQUIRED CONFIG)
-
-# Provide all our library targets to users.
-include("${CMAKE_CURRENT_LIST_DIR}/ClangTargets.cmake")

Copied: cfe/trunk/cmake/modules/ClangConfig.cmake.in (from r274169, 
cfe/trunk/cmake/modules/ClangConfig.cmake)
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/ClangConfig.cmake.in?p2=cfe/trunk/cmake/modules/ClangConfig.cmake.in=cfe/trunk/cmake/modules/ClangConfig.cmake=274169=274176=274176=diff
==
(empty)


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


Re: [cfe-dev] RFC: Default language standard mode policy

2016-06-29 Thread Hal Finkel via cfe-commits
- Original Message -

> From: "Hal Finkel via cfe-dev" 
> To: "Richard Smith" 
> Cc: "Clang Dev" , "cfe-commits"
> 
> Sent: Wednesday, June 29, 2016 4:17:18 PM
> Subject: Re: [cfe-dev] RFC: Default language standard mode policy

> - Original Message -

> > From: "Richard Smith" 
> 
> > To: "Hal Finkel" 
> 
> > Cc: "Clang Dev" , "cfe-commits"
> > 
> 
> > Sent: Wednesday, June 29, 2016 3:01:46 PM
> 
> > Subject: Re: [cfe-dev] RFC: Default language standard mode policy
> 

> > On Wed, Jun 29, 2016 at 12:55 PM, Hal Finkel via cfe-dev <
> > cfe-...@lists.llvm.org > wrote:
> 

> > > > From: "Richard Smith via cfe-commits" <
> > > > cfe-commits@lists.llvm.org
> > > > >
> > > 
> > 
> 
> > > > To: "cfe-commits" < cfe-commits@lists.llvm.org >, "Clang Dev" <
> > > > cfe-...@lists.llvm.org >
> > > 
> > 
> 
> > > > Sent: Wednesday, June 29, 2016 2:09:37 PM
> > > 
> > 
> 
> > > > Subject: RFC: Default language standard mode policy
> > > 
> > 
> 

> > > > Hi all!
> > > 
> > 
> 

> > > > I'd like to establish a policy for Clang's default language
> > > > standard
> > > > (if none is specified with -std), as follows:
> > > 
> > 
> 

> > > > Clang defaults to the most recent published standard for the
> > > > selected
> > > > language that it fully implements.
> > > 
> > 
> 

> > > > The practical impact of this is that clang++ will default to
> > > > C++14
> > > > for C++ compilations (for version 3.9 onwards) and will default
> > > > to
> > > > C++17 once our implementation support is complete and the
> > > > standard
> > > > is published (whichever happens later).
> > > 
> > 
> 
> > > I think that we need to include libc++ in this criteria as well.
> > > I
> > > think we'll also need some CMake flags to adjust the default for
> > > builds for systems on which this won't work.
> > 
> 
> > Right, it doesn't make sense to change our default in a way that
> > breaks use of the same version of libc++, or a supported version of
> > libstdc++ (and we should establish how old a version of libstdc++
> > we
> > support here).
> 

> > However, I don't immediately see that we need to wait for libc++ to
> > be feature-complete before we enable the new standard in Clang. If
> > that's what you're suggesting, can you expand on why? We already
> > have the SD-6 feature test macros to test for implementation of
> > specific features.
> 
> I think it is completely reasonable for an application to test
> __cplusplus for both language and library features. There are plenty
> of reasons why this won't always work on all systems, but I think we
> should endeavor to make this possible. I think that the SD-6 macros
> are useful is many circumstances, but I think it is unreasonable to
> expect users to detect all of the features they're using separately
> using SD-6 macros.

> We can't control what libstdc++ and others do, but if we can't even
> provide a complete implementation (including the library), I don't
> think we should switch the default.

> > > > I'd suggest that we apply the same policy for clang-cl, but if
> > > > it's
> > > > important that we enable a not-yet-fully-implemented standard
> > > > for
> > > > cl
> > > > compatibility, that seems reasonable.
> > > 
> > 
> 

> > > > The question of whether the default mode for the GCC-compatible
> > > > driver should be -std=gnuXXX or -std=cXXX is separate, but also
> > > > likely worth discussing. Enabling GNU keywords by default is a
> > > > very
> > > > odd choice, and if we believe we can change our defaults
> > > > without
> > > > breaking the world then this seems like a good time to do so.
> > > 
> > 
> 
> > > Unfortunately, on many systems, some standard system headers
> > > won't
> > > even parse without GNU extensions enabled. I think we'll need to
> > > leave the GNU extensions on by default (at least for parsing
> > > system
> > > headers).
> > 
> 
> > Can you give an example? -std=c++11 works fine on a broad range of
> > systems. Note that this is not about GNU *extensions*, which are
> > enabled in both modes; it's about GNU *keywords* (and a small
> > number
> > of non-conforming extensions) -- in particular, the 'typeof' GNU
> > keyword, and support for the asm keyword in C and the inline
> > keyword
> > in C89 (without __decoration__).
> 

> I recall having problems with this with fenv.h on various systems.
> They might just be older systems, however. We should check the
> current state of the world.

A quick data point: 

$ rpm -q --whatprovides /usr/include/aio.h 
glibc-headers-2.12-1.166.el6_7.7.ppc64 
$ clang -fsyntax-only -std=c11 -w /usr/include/aio.h 
/usr/include/aio.h:42:19: error: field has incomplete type 'struct sigevent' 
struct sigevent aio_sigevent; /* Signal number and value. */ 
^ 
/usr/include/aio.h:42:10: note: forward declaration of 'struct 

r274178 - [ClangConfig] Instead of hard coding the ClangTargets location to /ClangTargets.cmake, follow LLVM's example and use a pre-computed cmake variable @CLANG_CONFIG_EXPORTS_FILE@.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 16:59:19 2016
New Revision: 274178

URL: http://llvm.org/viewvc/llvm-project?rev=274178=rev
Log:
[ClangConfig] Instead of hard coding the ClangTargets location to 
/ClangTargets.cmake, follow LLVM's example and use a pre-computed cmake 
variable @CLANG_CONFIG_EXPORTS_FILE@.

This just makes ClangConfig more consistent with LLVMConfig.

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt
cfe/trunk/cmake/modules/ClangConfig.cmake.in

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274178=274177=274178=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 16:59:19 2016
@@ -8,12 +8,26 @@ get_property(CLANG_EXPORTS GLOBAL PROPER
 export(TARGETS ${CLANG_EXPORTS} FILE 
${clang_cmake_builddir}/ClangTargets.cmake)
 
 # Generate ClangConfig.cmake for the build tree.
+set(CLANG_CONFIG_CMAKE_DIR "${clang_cmake_builddir}")
+set(CLANG_CONFIG_EXPORTS_FILE "${clang_cmake_builddir}/ClangTargets.cmake")
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
   ${clang_cmake_builddir}/ClangConfig.cmake
   @ONLY)
 
 # Generate ClangConfig.cmake for the install tree.
+set(CLANG_CONFIG_CODE "
+# Compute the installation prefix from this LLVMConfig.cmake file location.
+get_filename_component(CLANG_INSTALL_PREFIX \"\${CMAKE_CURRENT_LIST_FILE}\" 
PATH)")
+# Construct the proper number of get_filename_component(... PATH)
+# calls to compute the installation prefix.
+string(REGEX REPLACE "/" ";" _count "${CLANG_INSTALL_PACKAGE_DIR}")
+foreach(p ${_count})
+  set(CLANG_CONFIG_CODE "${CLANG_CONFIG_CODE}
+get_filename_component(CLANG_INSTALL_PREFIX \"\${CLANG_INSTALL_PREFIX}\" 
PATH)")
+endforeach(p)
+set(CLANG_CONFIG_CMAKE_DIR 
"\${CLANG_INSTALL_PREFIX}/\${CLANG_INSTALL_PACKAGE_DIR}")
+set(CLANG_CONFIG_EXPORTS_FILE "\${CLANG_CMAKE_DIR}/ClangTargets.cmake")
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
   ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake

Modified: cfe/trunk/cmake/modules/ClangConfig.cmake.in
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/ClangConfig.cmake.in?rev=274178=274177=274178=diff
==
--- cfe/trunk/cmake/modules/ClangConfig.cmake.in (original)
+++ cfe/trunk/cmake/modules/ClangConfig.cmake.in Wed Jun 29 16:59:19 2016
@@ -6,5 +6,9 @@
 
 find_package(LLVM REQUIRED CONFIG)
 
+@CLANG_CONFIG_CODE@
+
+set(CLANG_CMAKE_DIR "@CLANG_CONFIG_CMAKE_DIR@")
+
 # Provide all our library targets to users.
-include("${CMAKE_CURRENT_LIST_DIR}/ClangTargets.cmake")
+include("@CLANG_CONFIG_EXPORTS_FILE@")


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


r274179 - [ClangConfig] Unset some variables after we are done using them to configure ClangConfig.cmake.in files.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 16:59:20 2016
New Revision: 274179

URL: http://llvm.org/viewvc/llvm-project?rev=274179=rev
Log:
[ClangConfig] Unset some variables after we are done using them to configure 
ClangConfig.cmake.in files.

This ensures that the values do not bleed over in between computations. It may
make sense in the future to just refactor this code into functions to provide
"true scoping".

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274179=274178=274179=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 16:59:20 2016
@@ -14,6 +14,8 @@ configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
   ${clang_cmake_builddir}/ClangConfig.cmake
   @ONLY)
+set(CLANG_CONFIG_CMAKE_DIR)
+set(CLANG_CONFIG_EXPORTS_FILE)
 
 # Generate ClangConfig.cmake for the install tree.
 set(CLANG_CONFIG_CODE "
@@ -32,6 +34,9 @@ configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
   ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
   @ONLY)
+set(CLANG_CONFIG_CODE)
+set(CLANG_CONFIG_CMAKE_DIR)
+set(CLANG_CONFIG_EXPORTS_FILE)
 
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
   install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})


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


r274180 - [ClangConfig] Store all of the targets exported in the variable CLANG_EXPORTED_TARGETS.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 16:59:23 2016
New Revision: 274180

URL: http://llvm.org/viewvc/llvm-project?rev=274180=rev
Log:
[ClangConfig] Store all of the targets exported in the variable 
CLANG_EXPORTED_TARGETS.

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt
cfe/trunk/cmake/modules/ClangConfig.cmake.in

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274180=274179=274180=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 16:59:23 2016
@@ -28,7 +28,7 @@ foreach(p ${_count})
   set(CLANG_CONFIG_CODE "${CLANG_CONFIG_CODE}
 get_filename_component(CLANG_INSTALL_PREFIX \"\${CLANG_INSTALL_PREFIX}\" 
PATH)")
 endforeach(p)
-set(CLANG_CONFIG_CMAKE_DIR 
"\${CLANG_INSTALL_PREFIX}/\${CLANG_INSTALL_PACKAGE_DIR}")
+set(CLANG_CONFIG_CMAKE_DIR 
"\${CLANG_INSTALL_PREFIX}/${CLANG_INSTALL_PACKAGE_DIR}")
 set(CLANG_CONFIG_EXPORTS_FILE "\${CLANG_CMAKE_DIR}/ClangTargets.cmake")
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in

Modified: cfe/trunk/cmake/modules/ClangConfig.cmake.in
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/ClangConfig.cmake.in?rev=274180=274179=274180=diff
==
--- cfe/trunk/cmake/modules/ClangConfig.cmake.in (original)
+++ cfe/trunk/cmake/modules/ClangConfig.cmake.in Wed Jun 29 16:59:23 2016
@@ -8,6 +8,7 @@ find_package(LLVM REQUIRED CONFIG)
 
 @CLANG_CONFIG_CODE@
 
+set(CLANG_EXPORTED_TARGETS "@CLANG_EXPORTS@")
 set(CLANG_CMAKE_DIR "@CLANG_CONFIG_CMAKE_DIR@")
 
 # Provide all our library targets to users.


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


Re: [cfe-dev] RFC: Default language standard mode policy

2016-06-29 Thread Joerg Sonnenberger via cfe-commits
On Wed, Jun 29, 2016 at 12:09:37PM -0700, Richard Smith via cfe-dev wrote:
> Hi all!
> 
> I'd like to establish a policy for Clang's default language standard (if
> none is specified with -std), as follows:
> 
>   Clang defaults to the most recent published standard for the selected
> language that it fully implements.
> 
> The practical impact of this is that clang++ will default to C++14 for C++
> compilations (for version 3.9 onwards) and will default to C++17 once our
> implementation support is complete and the standard is published (whichever
> happens later).

I don't have a problem with the C11 default, because the language impact
is minimal. That's quite different from C++ though and I am very
reluctant to update the default language even to C++11. There is a lot
of code in the wild that doesn't compile anymore due to stupid changes
like user-defined string literals or the narrowing (warning) changes.
Even worse are the nothrow changes for destructors, which silently break
valid C++03 code.

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


Re: [PATCH] D21830: Remove -mrelax-all from Clang -O0

2016-06-29 Thread Joerg Sonnenberger via cfe-commits
On Wed, Jun 29, 2016 at 11:00:26AM -0400, Rafael Espíndola via cfe-commits 
wrote:
> We need to benchmark this to see if it still makes a difference.
> 
> My canonical test is the .s of a lto of clang.

That won't exercise it? Assembler sources are exempt from this.

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


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread Joerg Sonnenberger via cfe-commits
joerg added a subscriber: joerg.
joerg added a comment.

On the topic of __cxa_thread_atexit, was it ever specified how it interacts 
with things like thread cancellation?


http://reviews.llvm.org/D21803



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


Re: [PATCH] D21834: Implementing 'If statement with Initializer'

2016-06-29 Thread Richard Smith via cfe-commits
rsmith requested changes to this revision.
rsmith added a comment.
This revision now requires changes to proceed.

The proposal has changed since the pre-meeting mailing, and now covers `switch` 
as well as `if`. You also need to handle the //expression-statement// form of 
//init-statement//.

As it happens, I've also been working on this proposal, and the bit that you're 
getting wrong here (the parsing side) is the part that I've finished. I've 
committed that as r274169; if you rebase your Sema changes on top of that (and 
add support for `switch`), we can get this change committed to finish off the 
implementation.

We'll also need some tests before this can be committed.

Thank you!



Comment at: lib/Parse/ParseStmt.cpp:1062-1075
@@ -1060,1 +1061,16 @@
 
+  if (CK == Sema::ConditionKind::IfWithInit &&
+  isForInitDeclarationWithSemi()) {  // if (int X = 4;
+// Parse declaration, which eats the ';'.
+ParsedAttributesWithRange attrs(AttrFactory);
+MaybeParseCXX11Attributes(attrs);
+
+SourceLocation DeclStart = Tok.getLocation(), DeclEnd;
+DeclGroupPtrTy DG = ParseSimpleDeclaration(
+  Declarator::ForContext, DeclEnd, attrs, false, nullptr);
+StmtResult InitStmt = Actions.ActOnDeclStmt(DG, DeclStart, 
Tok.getLocation());
+if (Init) *Init = InitStmt.get();
+
+ConsumeToken(); // Consume semi
+  }
+

We should try to only walk over the tokens once to identify whether this is a 
//condition// declaration, a //simple-declaration// of an //init-statement//, 
or an //expression//.


Comment at: lib/Parse/ParseTentative.cpp:77-79
@@ +76,5 @@
+  TentativeParsingAction PA(*this);
+  TPResult TPR = TryParseSimpleDeclaration(false);
+  if (Tok.isNot(tok::semi))
+TPR = TPResult::False;
+  PA.Revert();

This is not correct; `TryParseSimpleDeclaration` usually stops long before it 
reaches the end of the //simple-declaration//, so this will give false 
negatives in lots of cases.


http://reviews.llvm.org/D21834



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


r274169 - P0305R1: Parsing support for init-statements in 'if' and 'switch' statements.

2016-06-29 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Wed Jun 29 16:17:59 2016
New Revision: 274169

URL: http://llvm.org/viewvc/llvm-project?rev=274169=rev
Log:
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements.
No semantic analysis yet.

This is a pain to disambiguate correctly, because the parsing rules for the
declaration form of a condition and of an init-statement are quite different --
for a token sequence that looks like a declaration, we frequently need to
disambiguate all the way to the ')' or ';'.

We could do better here in some cases by stopping disambiguation once we've
decided whether we've got an expression or not (rather than keeping going until
we know whether it's an init-statement declaration or a condition declaration),
by unifying our parsing code for the two types of declaration and moving the
syntactic checks into Sema; if this has a measurable impact on parsing
performance, I'll look into that.

Added:
cfe/trunk/test/Parser/cxx1z-init-statement.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/include/clang/Sema/DeclSpec.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Parse/ParseExprCXX.cpp
cfe/trunk/lib/Parse/ParseStmt.cpp
cfe/trunk/lib/Parse/ParseTentative.cpp
cfe/trunk/lib/Sema/SemaStmt.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/test/Parser/extra-semi.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=274169=274168=274169=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Jun 29 16:17:59 
2016
@@ -7499,6 +7499,9 @@ def warn_empty_switch_body : Warning<
 def note_empty_body_on_separate_line : Note<
   "put the semicolon on a separate line to silence this warning">;
 
+def err_init_stmt_not_supported : Error<
+  "C++1z init-statement not yet supported">;
+
 def err_va_start_used_in_non_variadic_function : Error<
   "'va_start' used in function with fixed args">;
 def err_va_start_used_in_wrong_abi_function : Error<

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=274169=274168=274169=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Wed Jun 29 16:17:59 2016
@@ -1598,7 +1598,8 @@ private:
 
   
//======//
   // C++ if/switch/while condition expression.
-  Sema::ConditionResult ParseCXXCondition(SourceLocation Loc,
+  Sema::ConditionResult ParseCXXCondition(StmtResult *InitStmt,
+  SourceLocation Loc,
   Sema::ConditionKind CK);
 
   
//======//
@@ -1690,7 +1691,8 @@ private:
 unsigned ScopeFlags);
   void ParseCompoundStatementLeadingPragmas();
   StmtResult ParseCompoundStatementBody(bool isStmtExpr = false);
-  bool ParseParenExprOrCondition(Sema::ConditionResult ,
+  bool ParseParenExprOrCondition(StmtResult *InitStmt,
+ Sema::ConditionResult ,
  SourceLocation Loc,
  Sema::ConditionKind CK);
   StmtResult ParseIfStatement(SourceLocation *TrailingElseLoc);
@@ -1984,11 +1986,18 @@ private:
   /// the function returns true to let the declaration parsing code handle it.
   bool isCXXFunctionDeclarator(bool *IsAmbiguous = nullptr);
 
-  /// isCXXConditionDeclaration - Disambiguates between a declaration or an
-  /// expression for a condition of a if/switch/while/for statement.
-  /// If during the disambiguation process a parsing error is encountered,
-  /// the function returns true to let the declaration parsing code handle it.
-  bool isCXXConditionDeclaration();
+  struct ConditionDeclarationOrInitStatementState;
+  enum class ConditionOrInitStatement {
+Expression,///< Disambiguated as an expression (either kind).
+ConditionDecl, ///< Disambiguated as the declaration form of condition.
+InitStmtDecl,  ///< Disambiguated as a simple-declaration init-statement.
+Error  ///< Can't be any of the above!
+  };
+  /// \brief Disambiguates between the different kinds of things that can 
happen
+  /// after 'if (' or 'switch ('. This could be one of two different kinds of
+  /// declaration (depending on whether there is a ';' later) or an expression.
+  ConditionOrInitStatement
+  isCXXConditionDeclarationOrInitStatement(bool CanBeInitStmt);
 
  

r274167 - Convert another case over to RevertingTentativeParsingAction.

2016-06-29 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Wed Jun 29 16:12:37 2016
New Revision: 274167

URL: http://llvm.org/viewvc/llvm-project?rev=274167=rev
Log:
Convert another case over to RevertingTentativeParsingAction.

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

Modified: cfe/trunk/lib/Parse/ParseTentative.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseTentative.cpp?rev=274167=274166=274167=diff
==
--- cfe/trunk/lib/Parse/ParseTentative.cpp (original)
+++ cfe/trunk/lib/Parse/ParseTentative.cpp Wed Jun 29 16:12:37 2016
@@ -1310,7 +1310,7 @@ Parser::isCXXDeclarationSpecifier(Parser
  Tok.getAnnotationRange(),
  SS);
 if (SS.getScopeRep() && SS.getScopeRep()->isDependent()) {
-  TentativeParsingAction PA(*this);
+  RevertingTentativeParsingAction PA(*this);
   ConsumeToken();
   ConsumeToken();
   bool isIdentifier = Tok.is(tok::identifier);
@@ -1318,7 +1318,6 @@ Parser::isCXXDeclarationSpecifier(Parser
   if (!isIdentifier)
 TPR = isCXXDeclarationSpecifier(BracedCastResult,
 HasMissingTypename);
-  PA.Revert();
 
   if (isIdentifier ||
   TPR == TPResult::True || TPR == TPResult::Error)
@@ -1330,8 +1329,6 @@ Parser::isCXXDeclarationSpecifier(Parser
 *HasMissingTypename = true;
 return TPResult::Ambiguous;
   }
-
-  // FIXME: Fails to either revert or commit the tentative parse!
 } else {
   // Try to resolve the name. If it doesn't exist, assume it was
   // intended to name a type and keep disambiguating.


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


r274168 - [ClangConfig] Copy ClangConfig.cmake to ${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR} instead of to ${CLANG_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 16:12:38 2016
New Revision: 274168

URL: http://llvm.org/viewvc/llvm-project?rev=274168=rev
Log:
[ClangConfig] Copy ClangConfig.cmake to 
${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR} instead of to 
${CLANG_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}.

This is an obvious bug since ClangConfig.cmake looks for ClangTargets.cmake in
${CMAKE_CURRENT_LIST_DIR}. But ClangTargets.cmake is in
${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}, so it will always fail with an
in tree build.

In the case where clang is built out of tree, this is still correct since
CMAKE_BINARY_DIR and CLANG_BINARY_DIR will be the same.

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274168=274167=274168=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 16:12:38 2016
@@ -18,5 +18,5 @@ install(FILES
 # can build against a build directory of Clang more easily.
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
-  ${CLANG_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}/ClangConfig.cmake
+  ${clang_cmake_builddir}/ClangConfig.cmake
   COPYONLY)


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


Re: [cfe-dev] RFC: Default language standard mode policy

2016-06-29 Thread Hal Finkel via cfe-commits
- Original Message -

> From: "Richard Smith" 
> To: "Hal Finkel" 
> Cc: "Clang Dev" , "cfe-commits"
> 
> Sent: Wednesday, June 29, 2016 3:01:46 PM
> Subject: Re: [cfe-dev] RFC: Default language standard mode policy

> On Wed, Jun 29, 2016 at 12:55 PM, Hal Finkel via cfe-dev <
> cfe-...@lists.llvm.org > wrote:

> > > From: "Richard Smith via cfe-commits" <
> > > cfe-commits@lists.llvm.org
> > > >
> > 
> 
> > > To: "cfe-commits" < cfe-commits@lists.llvm.org >, "Clang Dev" <
> > > cfe-...@lists.llvm.org >
> > 
> 
> > > Sent: Wednesday, June 29, 2016 2:09:37 PM
> > 
> 
> > > Subject: RFC: Default language standard mode policy
> > 
> 

> > > Hi all!
> > 
> 

> > > I'd like to establish a policy for Clang's default language
> > > standard
> > > (if none is specified with -std), as follows:
> > 
> 

> > > Clang defaults to the most recent published standard for the
> > > selected
> > > language that it fully implements.
> > 
> 

> > > The practical impact of this is that clang++ will default to
> > > C++14
> > > for C++ compilations (for version 3.9 onwards) and will default
> > > to
> > > C++17 once our implementation support is complete and the
> > > standard
> > > is published (whichever happens later).
> > 
> 
> > I think that we need to include libc++ in this criteria as well. I
> > think we'll also need some CMake flags to adjust the default for
> > builds for systems on which this won't work.
> 
> Right, it doesn't make sense to change our default in a way that
> breaks use of the same version of libc++, or a supported version of
> libstdc++ (and we should establish how old a version of libstdc++ we
> support here).

> However, I don't immediately see that we need to wait for libc++ to
> be feature-complete before we enable the new standard in Clang. If
> that's what you're suggesting, can you expand on why? We already
> have the SD-6 feature test macros to test for implementation of
> specific features.
I think it is completely reasonable for an application to test __cplusplus for 
both language and library features. There are plenty of reasons why this won't 
always work on all systems, but I think we should endeavor to make this 
possible. I think that the SD-6 macros are useful is many circumstances, but I 
think it is unreasonable to expect users to detect all of the features they're 
using separately using SD-6 macros. 

We can't control what libstdc++ and others do, but if we can't even provide a 
complete implementation (including the library), I don't think we should switch 
the default. 

> > > I'd suggest that we apply the same policy for clang-cl, but if
> > > it's
> > > important that we enable a not-yet-fully-implemented standard for
> > > cl
> > > compatibility, that seems reasonable.
> > 
> 

> > > The question of whether the default mode for the GCC-compatible
> > > driver should be -std=gnuXXX or -std=cXXX is separate, but also
> > > likely worth discussing. Enabling GNU keywords by default is a
> > > very
> > > odd choice, and if we believe we can change our defaults without
> > > breaking the world then this seems like a good time to do so.
> > 
> 
> > Unfortunately, on many systems, some standard system headers won't
> > even parse without GNU extensions enabled. I think we'll need to
> > leave the GNU extensions on by default (at least for parsing system
> > headers).
> 
> Can you give an example? -std=c++11 works fine on a broad range of
> systems. Note that this is not about GNU *extensions*, which are
> enabled in both modes; it's about GNU *keywords* (and a small number
> of non-conforming extensions) -- in particular, the 'typeof' GNU
> keyword, and support for the asm keyword in C and the inline keyword
> in C89 (without __decoration__).

I recall having problems with this with fenv.h on various systems. They might 
just be older systems, however. We should check the current state of the world. 

Thanks again, 
Hal 

> > > I also intend to make explicit in our documentation that our
> > > -std=XXX
> > > flag enables the selected standard, *plus all relevant issues in
> > > Defect Report status from the relevant language committee* (it
> > > doesn't make sense to support a language without its bugfixes).
> > 
> 
> > +1
> 

> > -Hal
> 

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

> > --
> 

> > Hal Finkel
> 
> > Assistant Computational Scientist
> 
> > Leadership Computing Facility
> 
> > Argonne National Laboratory
> 

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

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne 

r274165 - Switch to an RAII object to revert tentative parsing automatically.

2016-06-29 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Wed Jun 29 16:06:51 2016
New Revision: 274165

URL: http://llvm.org/viewvc/llvm-project?rev=274165=rev
Log:
Switch to an RAII object to revert tentative parsing automatically.

Modified:
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/lib/Parse/ParseTentative.cpp

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=274165=274164=274165=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Wed Jun 29 16:06:51 2016
@@ -715,6 +715,16 @@ private:
   assert(!isActive && "Forgot to call Commit or Revert!");
 }
   };
+  /// A TentativeParsingAction that automatically reverts in its destructor.
+  /// Useful for disambiguation parses that will always be reverted.
+  class RevertingTentativeParsingAction
+  : private Parser::TentativeParsingAction {
+  public:
+RevertingTentativeParsingAction(Parser )
+: Parser::TentativeParsingAction(P) {}
+~RevertingTentativeParsingAction() { Revert(); }
+  };
+
   class UnannotatedTentativeParsingAction;
 
   /// ObjCDeclContextSwitch - An object used to switch context from

Modified: cfe/trunk/lib/Parse/ParseTentative.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseTentative.cpp?rev=274165=274164=274165=diff
==
--- cfe/trunk/lib/Parse/ParseTentative.cpp (original)
+++ cfe/trunk/lib/Parse/ParseTentative.cpp Wed Jun 29 16:06:51 2016
@@ -125,10 +125,11 @@ bool Parser::isCXXSimpleDeclaration(bool
   // Ok, we have a simple-type-specifier/typename-specifier followed by a '(',
   // or an identifier which doesn't resolve as anything. We need tentative
   // parsing...
-
-  TentativeParsingAction PA(*this);
-  TPR = TryParseSimpleDeclaration(AllowForRangeDecl);
-  PA.Revert();
+ 
+  {
+RevertingTentativeParsingAction PA(*this);
+TPR = TryParseSimpleDeclaration(AllowForRangeDecl);
+  }
 
   // In case of an error, let the declaration parsing code handle it.
   if (TPR == TPResult::Error)
@@ -354,7 +355,7 @@ bool Parser::isCXXConditionDeclaration()
   // Ok, we have a simple-type-specifier/typename-specifier followed by a '('.
   // We need tentative parsing...
 
-  TentativeParsingAction PA(*this);
+  RevertingTentativeParsingAction PA(*this);
 
   // type-specifier-seq
   TryConsumeDeclarationSpecifier();
@@ -378,8 +379,6 @@ bool Parser::isCXXConditionDeclaration()
   TPR = TPResult::False;
   }
 
-  PA.Revert();
-
   assert(TPR == TPResult::True || TPR == TPResult::False);
   return TPR == TPResult::True;
 }
@@ -423,7 +422,7 @@ bool Parser::isCXXTypeId(TentativeCXXTyp
   // Ok, we have a simple-type-specifier/typename-specifier followed by a '('.
   // We need tentative parsing...
 
-  TentativeParsingAction PA(*this);
+  RevertingTentativeParsingAction PA(*this);
 
   // type-specifier-seq
   TryConsumeDeclarationSpecifier();
@@ -456,8 +455,6 @@ bool Parser::isCXXTypeId(TentativeCXXTyp
   TPR = TPResult::False;
   }
 
-  PA.Revert();
-
   assert(TPR == TPResult::True || TPR == TPResult::False);
   return TPR == TPResult::True;
 }
@@ -508,7 +505,7 @@ Parser::isCXX11AttributeSpecifier(bool D
   if (!Disambiguate && !getLangOpts().ObjC1)
 return CAK_AttributeSpecifier;
 
-  TentativeParsingAction PA(*this);
+  RevertingTentativeParsingAction PA(*this);
 
   // Opening brackets were checked for above.
   ConsumeBracket();
@@ -520,8 +517,6 @@ Parser::isCXX11AttributeSpecifier(bool D
 bool IsAttribute = SkipUntil(tok::r_square);
 IsAttribute &= Tok.is(tok::r_square);
 
-PA.Revert();
-
 return IsAttribute ? CAK_AttributeSpecifier : 
CAK_InvalidAttributeSpecifier;
   }
 
@@ -542,8 +537,6 @@ Parser::isCXX11AttributeSpecifier(bool D
 // A lambda cannot end with ']]', and an attribute must.
 bool IsAttribute = Tok.is(tok::r_square);
 
-PA.Revert();
-
 if (IsAttribute)
   // Case 1: C++11 attribute.
   return CAK_AttributeSpecifier;
@@ -564,7 +557,6 @@ Parser::isCXX11AttributeSpecifier(bool D
   while (Tok.isNot(tok::r_square)) {
 if (Tok.is(tok::comma)) {
   // Case 1: Stray commas can only occur in attributes.
-  PA.Revert();
   return CAK_AttributeSpecifier;
 }
 
@@ -611,8 +603,6 @@ Parser::isCXX11AttributeSpecifier(bool D
 }
   }
 
-  PA.Revert();
-
   if (IsAttribute)
 // Case 1: C++11 statement attribute.
 return CAK_AttributeSpecifier;
@@ -1340,6 +1330,8 @@ Parser::isCXXDeclarationSpecifier(Parser
 *HasMissingTypename = true;
 return TPResult::Ambiguous;
   }
+
+  // FIXME: Fails to either revert or commit the tentative parse!
 } else {
   // Try to resolve the name. If it doesn't exist, assume it was
   // intended to name a type and keep disambiguating.
@@ -1391,15 

Re: [PATCH] D21705: Include debug info for nested structs and classes

2016-06-29 Thread Adrian McCarthy via cfe-commits
amccarth updated this revision to Diff 62283.
amccarth added a comment.

Applied suggestion from the comments, which eliminates the need to alter the 
ObjectiveC test.


http://reviews.llvm.org/D21705

Files:
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CGDebugInfo.h
  test/CodeGenCXX/debug-info-dup-fwd-decl.cpp
  test/CodeGenCXX/debug-info-indirect-field-decl.cpp
  test/CodeGenCXX/debug-info-ms-abi.cpp

Index: test/CodeGenCXX/debug-info-ms-abi.cpp
===
--- test/CodeGenCXX/debug-info-ms-abi.cpp
+++ test/CodeGenCXX/debug-info-ms-abi.cpp
@@ -14,6 +14,9 @@
 // CHECK: ![[Foo:[^ ]*]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Foo",
 // CHECK-SAME: identifier: ".?AUFoo@@"
 
+// CHECK: distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Nested",
+// CHECK-SAME: identifier: ".?AUNested@Foo@@"
+
 // CHECK: !DISubprogram(name: "f",
 // CHECK-SAME: containingType: ![[Foo]], virtuality: DW_VIRTUALITY_virtual, virtualIndex: 0,
 // CHECK-SAME: flags: DIFlagPrototyped | DIFlagIntroducedVirtual,
@@ -25,6 +28,3 @@
 // CHECK: !DISubprogram(name: "h",
 // CHECK-SAME: containingType: ![[Foo]], virtuality: DW_VIRTUALITY_virtual, virtualIndex: 2,
 // CHECK-SAME: flags: DIFlagPrototyped | DIFlagIntroducedVirtual,
-
-// CHECK: distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Nested",
-// CHECK-SAME: identifier: ".?AUNested@Foo@@"
Index: test/CodeGenCXX/debug-info-indirect-field-decl.cpp
===
--- test/CodeGenCXX/debug-info-indirect-field-decl.cpp
+++ test/CodeGenCXX/debug-info-indirect-field-decl.cpp
@@ -8,18 +8,18 @@
 struct Bar {
   int i1;
   // CHECK: ![[INT:[0-9]+]] = !DIBasicType(name: "int"
-  // CHECK: !DIDerivedType(tag: DW_TAG_member, scope:
-  // CHECK-SAME:   line: [[@LINE+4]]
-  // CHECK-SAME:   baseType: ![[UNION:[0-9]+]]
-  // CHECK-SAME:   size: 32, align: 32, offset: 32
-  // CHECK: ![[UNION]] = distinct !DICompositeType(tag: DW_TAG_union_type,{{.*}} identifier: "_ZTSN3BarUt_E")
+  // CHECK: ![[UNION:[0-9]+]] = distinct !DICompositeType(tag: DW_TAG_union_type,{{.*}} identifier: "_ZTSN3BarUt_E")
   union {
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "i2",
-// CHECK-SAME:   line: [[@LINE+5]]
+// CHECK-SAME:   line: [[@LINE+9]]
 // CHECK-SAME:   baseType: ![[INT]]
 // CHECK-SAME:   size: 32, align: 32
 // CHECK-NOT:offset:
 // CHECK-SAME:   ){{$}}
+// CHECK: !DIDerivedType(tag: DW_TAG_member, scope:
+// CHECK-SAME:   line: [[@LINE-8]]
+// CHECK-SAME:   baseType: ![[UNION]]
+// CHECK-SAME:   size: 32, align: 32, offset: 32
 int i2;
   };
 };
Index: test/CodeGenCXX/debug-info-dup-fwd-decl.cpp
===
--- test/CodeGenCXX/debug-info-dup-fwd-decl.cpp
+++ test/CodeGenCXX/debug-info-dup-fwd-decl.cpp
@@ -19,6 +19,6 @@
 
 Test t;
 
-// CHECK: !DIDerivedType(tag: DW_TAG_pointer_type
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "data"
+// CHECK: !DIDerivedType(tag: DW_TAG_pointer_type
 // CHECK-NOT: !DICompositeType(tag: DW_TAG_structure_type, name: "data"
Index: lib/CodeGen/CGDebugInfo.h
===
--- lib/CodeGen/CGDebugInfo.h
+++ lib/CodeGen/CGDebugInfo.h
@@ -249,6 +249,8 @@
 llvm::DIFile *F,
 SmallVectorImpl ,
 llvm::DIType *RecordTy, const RecordDecl *RD);
+  void CollectRecordNestedRecord(const RecordDecl *RD,
+ SmallVectorImpl );
   void CollectRecordFields(const RecordDecl *Decl, llvm::DIFile *F,
SmallVectorImpl ,
llvm::DICompositeType *RecordTy);
Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -1028,6 +1028,13 @@
   elements.push_back(fieldType);
 }
 
+void CGDebugInfo::CollectRecordNestedRecord(
+const RecordDecl *RD, SmallVectorImpl ) {
+  QualType Ty = CGM.getContext().getTypeDeclType(RD);
+  llvm::DIType *nestedType = getOrCreateType(Ty, getOrCreateMainFile());
+  elements.push_back(nestedType);
+}
+
 void CGDebugInfo::CollectRecordFields(
 const RecordDecl *record, llvm::DIFile *tunit,
 SmallVectorImpl ,
@@ -1064,6 +1071,9 @@
 
 // Bump field number for next field.
 ++fieldNo;
+  } else if (const auto *nestedRec = dyn_cast(I)) {
+if (!nestedRec->isImplicit() && nestedRec->getDeclContext() == record)
+  CollectRecordNestedRecord(nestedRec, elements);
   }
   }
 }
@@ -3562,8 +3572,8 @@
   if (CGM.getCodeGenOpts().getDebugInfo() < codegenoptions::LimitedDebugInfo)
 return;
   const NamespaceDecl *NSDecl = 

Re: [PATCH] D21705: Include debug info for nested structs and classes

2016-06-29 Thread Adrian McCarthy via cfe-commits
amccarth marked 2 inline comments as done.
amccarth added a comment.

http://reviews.llvm.org/D21705



___
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-06-29 Thread Jake VanAdrighem via cfe-commits
jakev updated this revision to Diff 62282.
jakev marked 5 inline comments as done.
jakev added a comment.

Address comments.


Repository:
  rL LLVM

http://reviews.llvm.org/D21823

Files:
  include/clang/Driver/Options.td
  lib/Driver/ToolChain.cpp
  lib/Driver/Tools.cpp
  test/Driver/clang_f_opts.c

Index: test/Driver/clang_f_opts.c
===
--- test/Driver/clang_f_opts.c
+++ test/Driver/clang_f_opts.c
@@ -97,10 +97,20 @@
 // RUN: %clang -### -S -fcoverage-mapping %s 2>&1 | FileCheck -check-prefix=CHECK-COVERAGE-AND-GEN %s
 // RUN: %clang -### -S -fcoverage-mapping -fno-coverage-mapping %s 2>&1 | FileCheck -check-prefix=CHECK-DISABLE-COVERAGE %s
 // RUN: %clang -### -S -fprofile-instr-generate -fcoverage-mapping -fno-coverage-mapping %s 2>&1 | FileCheck -check-prefix=CHECK-DISABLE-COVERAGE %s
+// RUN: %clang -### -S -fpgo-train=source-cfg %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-GENERATE %s
+// RUN: %clang -### -S -fpgo-train=optimizer-cfg %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-GENERATE-LLVM %s
+// RUN: %clang -### -S -fpgo-train=source-cfg -fcoverage-mapping %s 2>&1 | FileCheck -check-prefix=CHECK-COVERAGE-AND-GEN %s
+// RUN: %clang -### -S -fpgo-train=optimizer-cfg -fcoverage-mapping %s 2>&1 | FileCheck -check-prefix=CHECK-COVERAGE-AND-GEN %s
+// RUN: %clang -### -S -fpgo-train=source-cfg -fprofile-instr-generate %s 2>&1 | FileCheck -check-prefix=CHECK-NO-MIX-TRAIN-GEN %s
+// RUN: %clang -### -S -fpgo-train=optimizer-cfg -fprofile-instr-generate %s 2>&1 | FileCheck -check-prefix=CHECK-NO-MIX-TRAIN-GEN %s
+// RUN: %clang -### -S -fpgo-train=source-cfg -fpgo-apply=file %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-GENERATE %s
+// RUN: %clang -### -S -fpgo-train=optimizer-cfg -fpgo-apply=file %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-GENERATE-LLVM %s
 // CHECK-PROFILE-GENERATE: "-fprofile-instrument=clang"
+// CHECK-PROFILE-GENERATE-LLVM: "-fprofile-instrument=llvm"
 // CHECK-PROFILE-GENERATE-DIR: "-fprofile-instrument-path=/some/dir{{/|}}default.profraw"
 // CHECK-PROFILE-GENERATE-FILE: "-fprofile-instrument-path=/tmp/somefile.profraw"
 // CHECK-NO-MIX-GEN-USE: '{{[a-z=-]*}}' not allowed with '{{[a-z=-]*}}'
+// CHECK-NO-MIX-TRAIN-GEN: '{{[a-z=-]*}}' not allowed with '{{[a-z=-]*}}'
 // CHECK-DISABLE-GEN-NOT: "-fprofile-instrument=clang"
 // CHECK-DISABLE-USE-NOT: "-fprofile-instr-use"
 // CHECK-COVERAGE-AND-GEN: '-fcoverage-mapping' only allowed with '-fprofile-instr-generate'
@@ -111,9 +121,14 @@
 // RUN: mkdir -p %t.d/some/dir
 // RUN: %clang -### -S -fprofile-use=%t.d/some/dir %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-USE-DIR %s
 // RUN: %clang -### -S -fprofile-instr-use=/tmp/somefile.prof %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-USE-FILE %s
+// RUN: %clang -### -S -fpgo-apply=/tmp/somefile.prof %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-USE-FILE %s
+// RUN: %clang -### -S -fpgo-train=source-cfg -fpgo-apply=/tmp/somefile.prof %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-USE-FILE %s
+// RUN: %clang -### -S -fpgo-train=optimizer-cfg  -fpgo-apply=/tmp/somefile.prof %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-USE-FILE %s
+// RUN: %clang -### -S -fprofile-instr-use=/tmp/somefile.prof -fpgo-apply=/tmp/somefile.prof %s 2>&1 | FileCheck -check-prefix=CHECK-NO-MIX-APPLY-USE %s
 // CHECK-PROFILE-USE: "-fprofile-instrument-use-path=default.profdata"
 // CHECK-PROFILE-USE-DIR: "-fprofile-instrument-use-path={{.*}}.d/some/dir{{/|}}default.profdata"
 // CHECK-PROFILE-USE-FILE: "-fprofile-instrument-use-path=/tmp/somefile.prof"
+// CHECK-NO-MIX-APPLY-USE: '{{[a-z=-]*}}' not allowed with '{{[a-z=-]*}}'
 
 // RUN: %clang -### -S -fvectorize %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
 // RUN: %clang -### -S -fno-vectorize -fvectorize %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -3468,6 +3468,14 @@
 static void addPGOAndCoverageFlags(Compilation , const Driver ,
const InputInfo , const ArgList ,
ArgStringList ) {
+
+  auto *PGOTrainArg =
+  Args.getLastArg(options::OPT_fpgo_train_EQ,
+  options::OPT_fno_pgo_train);
+  if (PGOTrainArg &&
+  PGOTrainArg->getOption().matches(options::OPT_fno_pgo_train))
+PGOTrainArg = nullptr;
+
   auto *ProfileGenerateArg = Args.getLastArg(
   options::OPT_fprofile_instr_generate,
   options::OPT_fprofile_instr_generate_EQ, options::OPT_fprofile_generate,
@@ -3478,14 +3486,29 @@
   options::OPT_fno_profile_instr_generate))
 ProfileGenerateArg = nullptr;
 
+  else if (PGOTrainArg && ProfileGenerateArg)
+D.Diag(diag::err_drv_argument_not_allowed_with)
+<< PGOTrainArg->getSpelling()
+<< ProfileGenerateArg->getSpelling();
+
+  auto *PGOApplyArg =
+  

Re: [PATCH] D18035: [GCC] PR23529 Mangler part of attrbute abi_tag support

2016-06-29 Thread Richard Smith via cfe-commits
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

LGTM, thank you so much for your patience and hard work on this change!


http://reviews.llvm.org/D18035



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


Re: RFC: Default language standard mode policy

2016-06-29 Thread Sean Silva via cfe-commits
On Wed, Jun 29, 2016 at 1:34 PM, Sean Silva  wrote:

>
>
> On Wed, Jun 29, 2016 at 12:51 PM, Richard Smith 
> wrote:
>
>> On Wed, Jun 29, 2016 at 12:30 PM, Sean Silva 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jun 29, 2016 at 12:09 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Hi all!

 I'd like to establish a policy for Clang's default language standard
 (if none is specified with -std), as follows:

   Clang defaults to the most recent published standard for the selected
 language that it fully implements.

 The practical impact of this is that clang++ will default to C++14 for
 C++ compilations (for version 3.9 onwards) and will default to C++17 once
 our implementation support is complete and the standard is published
 (whichever happens later).

 I'd suggest that we apply the same policy for clang-cl, but if it's
 important that we enable a not-yet-fully-implemented standard for cl
 compatibility, that seems reasonable.

 The question of whether the default mode for the GCC-compatible driver
 should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
 discussing. Enabling GNU keywords by default is a very odd choice, and if
 we believe we can change our defaults without breaking the world then this
 seems like a good time to do so.

>>>
>>> Using cXXX instead of gnuXXX would break the world on PS4. So for sure
>>> with `-std=c++latest` we would end up proposing a patch to change this for
>>> the PS4 target to gnu++latest (or gnu++11 if gnu++latest is not feasible).
>>>
>>
>> OK. Out of interest, is it the GNU keywords that you need, or some other
>> effect of the difference between modes?
>>
>
> A quick check of two titles I have at hand shows that at least `typeof` is
> in use.
>

(this check consisted of using -std=c++11 instead of -std=gnu++11 and
seeing what breaks)

-- Sean Silva


>
> -- Sean Silva
>
>
>>
>>
>>> (As I'm sure you're aware, we have pending to upstream a patch that
>>> makes -std=gnu++11 the default C++ language mode on PS4 (just blocked on
>>> fixing tests to not assume the existing std)).
>>>
>>> It may be feasible for us to use a "-std=gnu++latest" behavior and not
>>> have to have a PS4-specific default; CC'ing Warren and Paul.
>>>
>>> -- Sean Silva
>>>
>>>

 I also intend to make explicit in our documentation that our -std=XXX
 flag enables the selected standard, *plus all relevant issues in Defect
 Report status from the relevant language committee* (it doesn't make sense
 to support a language without its bugfixes).

 Thoughts?

 ___
 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: RFC: Default language standard mode policy

2016-06-29 Thread Sean Silva via cfe-commits
On Wed, Jun 29, 2016 at 12:51 PM, Richard Smith 
wrote:

> On Wed, Jun 29, 2016 at 12:30 PM, Sean Silva 
> wrote:
>
>>
>>
>> On Wed, Jun 29, 2016 at 12:09 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi all!
>>>
>>> I'd like to establish a policy for Clang's default language standard (if
>>> none is specified with -std), as follows:
>>>
>>>   Clang defaults to the most recent published standard for the selected
>>> language that it fully implements.
>>>
>>> The practical impact of this is that clang++ will default to C++14 for
>>> C++ compilations (for version 3.9 onwards) and will default to C++17 once
>>> our implementation support is complete and the standard is published
>>> (whichever happens later).
>>>
>>> I'd suggest that we apply the same policy for clang-cl, but if it's
>>> important that we enable a not-yet-fully-implemented standard for cl
>>> compatibility, that seems reasonable.
>>>
>>> The question of whether the default mode for the GCC-compatible driver
>>> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
>>> discussing. Enabling GNU keywords by default is a very odd choice, and if
>>> we believe we can change our defaults without breaking the world then this
>>> seems like a good time to do so.
>>>
>>
>> Using cXXX instead of gnuXXX would break the world on PS4. So for sure
>> with `-std=c++latest` we would end up proposing a patch to change this for
>> the PS4 target to gnu++latest (or gnu++11 if gnu++latest is not feasible).
>>
>
> OK. Out of interest, is it the GNU keywords that you need, or some other
> effect of the difference between modes?
>

A quick check of two titles I have at hand shows that at least `typeof` is
in use.

-- Sean Silva


>
>
>> (As I'm sure you're aware, we have pending to upstream a patch that makes
>> -std=gnu++11 the default C++ language mode on PS4 (just blocked on fixing
>> tests to not assume the existing std)).
>>
>> It may be feasible for us to use a "-std=gnu++latest" behavior and not
>> have to have a PS4-specific default; CC'ing Warren and Paul.
>>
>> -- Sean Silva
>>
>>
>>>
>>> I also intend to make explicit in our documentation that our -std=XXX
>>> flag enables the selected standard, *plus all relevant issues in Defect
>>> Report status from the relevant language committee* (it doesn't make sense
>>> to support a language without its bugfixes).
>>>
>>> Thoughts?
>>>
>>> ___
>>> 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


r274158 - [ClangConfig] Replace paths with the same value as CLANG_INSTALL_PACKAGE_DIR with a deref of the variable.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 15:22:46 2016
New Revision: 274158

URL: http://llvm.org/viewvc/llvm-project?rev=274158=rev
Log:
[ClangConfig] Replace paths with the same value as CLANG_INSTALL_PACKAGE_DIR 
with a deref of the variable.

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274158=274157=274158=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 15:22:46 2016
@@ -12,11 +12,11 @@ install(EXPORT ClangTargets DESTINATION
 
 install(FILES
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
-  DESTINATION lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
+  DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
 
 # Also copy ClangConfig.cmake to the build directory so that dependent projects
 # can build against a build directory of Clang more easily.
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
-  ${CLANG_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/clang/ClangConfig.cmake
+  ${CLANG_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}/ClangConfig.cmake
   COPYONLY)


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


Re: [PATCH] D21833: [clang-tidy] Fix more enum declaration cases in misc-unused-using-decls check.

2016-06-29 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 62278.
hokein added a comment.

Address review comments.


http://reviews.llvm.org/D21833

Files:
  clang-tidy/misc/UnusedUsingDeclsCheck.cpp
  test/clang-tidy/misc-unused-using-decls.cpp

Index: test/clang-tidy/misc-unused-using-decls.cpp
===
--- test/clang-tidy/misc-unused-using-decls.cpp
+++ test/clang-tidy/misc-unused-using-decls.cpp
@@ -44,11 +44,13 @@
 extern ostream cout;
 ostream (ostream );
 
-enum Color {
-  Green,
-  Red,
-  Yellow
-};
+enum Color1 { Green };
+
+enum Color2 { Red };
+
+enum Color3 { Yellow };
+
+enum Color4 { Blue };
 
 }  // namespace n
 
@@ -126,11 +128,13 @@
 using n::H;
 }
 
-using n::Color;
-// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color' is unused
+using n::Color1;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color1' is unused
 using n::Green;
 // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Green' is unused
-using n::Red;
+using n::Color2;
+using n::Color3;
+using n::Blue;
 
 // - Usages -
 void f(B b);
@@ -144,5 +148,7 @@
   UsedFunc();
   UsedTemplateFunc();
   cout << endl;
-  int t = Red;
+  Color2 color2;
+  int t1 = Color3::Yellow;
+  int t2 = Blue;
 }
Index: clang-tidy/misc/UnusedUsingDeclsCheck.cpp
===
--- clang-tidy/misc/UnusedUsingDeclsCheck.cpp
+++ clang-tidy/misc/UnusedUsingDeclsCheck.cpp
@@ -18,6 +18,11 @@
 namespace tidy {
 namespace misc {
 
+namespace {
+// FIXME: Move this node matcher to ASTMatcher.
+const internal::VariadicDynCastAllOfMatcher enumType;
+} // namespace
+
 // A function that helps to tell whether a TargetDecl in a UsingDecl will be
 // checked. Only variable, function, function template, class template, class,
 // enum declaration and enum constant declaration are considered.
@@ -31,6 +36,7 @@
 void UnusedUsingDeclsCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(usingDecl(isExpansionInMainFile()).bind("using"), this);
   auto DeclMatcher = hasDeclaration(namedDecl().bind("used"));
+  Finder->addMatcher(loc(enumType(DeclMatcher)), this);
   Finder->addMatcher(loc(recordType(DeclMatcher)), this);
   Finder->addMatcher(loc(templateSpecializationType(DeclMatcher)), this);
   Finder->addMatcher(declRefExpr().bind("used"), this);
@@ -94,6 +100,8 @@
   removeFromFoundDecls(VD);
 } else if (const auto *ECD = dyn_cast(DRE->getDecl())) {
   removeFromFoundDecls(ECD);
+  if (const auto *ET = ECD->getType()->getAs())
+removeFromFoundDecls(ET->getDecl());
 }
   }
   // Check the uninstantiated template function usage.


Index: test/clang-tidy/misc-unused-using-decls.cpp
===
--- test/clang-tidy/misc-unused-using-decls.cpp
+++ test/clang-tidy/misc-unused-using-decls.cpp
@@ -44,11 +44,13 @@
 extern ostream cout;
 ostream (ostream );
 
-enum Color {
-  Green,
-  Red,
-  Yellow
-};
+enum Color1 { Green };
+
+enum Color2 { Red };
+
+enum Color3 { Yellow };
+
+enum Color4 { Blue };
 
 }  // namespace n
 
@@ -126,11 +128,13 @@
 using n::H;
 }
 
-using n::Color;
-// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color' is unused
+using n::Color1;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color1' is unused
 using n::Green;
 // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Green' is unused
-using n::Red;
+using n::Color2;
+using n::Color3;
+using n::Blue;
 
 // - Usages -
 void f(B b);
@@ -144,5 +148,7 @@
   UsedFunc();
   UsedTemplateFunc();
   cout << endl;
-  int t = Red;
+  Color2 color2;
+  int t1 = Color3::Yellow;
+  int t2 = Blue;
 }
Index: clang-tidy/misc/UnusedUsingDeclsCheck.cpp
===
--- clang-tidy/misc/UnusedUsingDeclsCheck.cpp
+++ clang-tidy/misc/UnusedUsingDeclsCheck.cpp
@@ -18,6 +18,11 @@
 namespace tidy {
 namespace misc {
 
+namespace {
+// FIXME: Move this node matcher to ASTMatcher.
+const internal::VariadicDynCastAllOfMatcher enumType;
+} // namespace
+
 // A function that helps to tell whether a TargetDecl in a UsingDecl will be
 // checked. Only variable, function, function template, class template, class,
 // enum declaration and enum constant declaration are considered.
@@ -31,6 +36,7 @@
 void UnusedUsingDeclsCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(usingDecl(isExpansionInMainFile()).bind("using"), this);
   auto DeclMatcher = hasDeclaration(namedDecl().bind("used"));
+  Finder->addMatcher(loc(enumType(DeclMatcher)), this);
   Finder->addMatcher(loc(recordType(DeclMatcher)), this);
   Finder->addMatcher(loc(templateSpecializationType(DeclMatcher)), this);
   Finder->addMatcher(declRefExpr().bind("used"), this);
@@ -94,6 +100,8 @@
   removeFromFoundDecls(VD);
 } else if (const auto *ECD = dyn_cast(DRE->getDecl())) {
   removeFromFoundDecls(ECD);
+ 

Re: [PATCH] D21833: [clang-tidy] Fix more enum declaration cases in misc-unused-using-decls check.

2016-06-29 Thread Haojian Wu via cfe-commits
hokein marked an inline comment as done.


Comment at: clang-tidy/misc/UnusedUsingDeclsCheck.cpp:22
@@ +21,3 @@
+namespace {
+// FIXME: Move this node matcher to ASTMatcher.
+const internal::VariadicDynCastAllOfMatcher enumType;

Done in D21860.


http://reviews.llvm.org/D21833



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


[PATCH] D21860: [ASTMatcher] Add a node matcher for EnumType.

2016-06-29 Thread Haojian Wu via cfe-commits
hokein created this revision.
hokein added a reviewer: aaron.ballman.
hokein added a subscriber: cfe-commits.
Herald added a subscriber: klimek.

http://reviews.llvm.org/D21860

Files:
  docs/LibASTMatchersReference.html
  include/clang/ASTMatchers/ASTMatchers.h
  lib/ASTMatchers/Dynamic/Registry.cpp
  unittests/ASTMatchers/ASTMatchersNodeTest.cpp

Index: unittests/ASTMatchers/ASTMatchersNodeTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersNodeTest.cpp
+++ unittests/ASTMatchers/ASTMatchersNodeTest.cpp
@@ -1299,6 +1299,13 @@
 hasType(rValueReferenceType();
 }
 
+TEST(TypeMatching, MatchesEnumTypes) {
+  EXPECT_TRUE(matches("enum Color { Green }; Color color;",
+  loc(enumType(;
+  EXPECT_TRUE(matches("enum class Color { Green }; Color color;",
+  loc(enumType(;
+}
+
 TEST(TypeMatching, MatchesPointersToConstTypes) {
   EXPECT_TRUE(matches("int b; int * const a = ",
   loc(pointerType(;
Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -171,6 +171,7 @@
   REGISTER_MATCHER(elaboratedType);
   REGISTER_MATCHER(enumConstantDecl);
   REGISTER_MATCHER(enumDecl);
+  REGISTER_MATCHER(enumType);
   REGISTER_MATCHER(equalsBoundNode);
   REGISTER_MATCHER(equalsIntegralValue);
   REGISTER_MATCHER(explicitCastExpr);
Index: include/clang/ASTMatchers/ASTMatchers.h
===
--- include/clang/ASTMatchers/ASTMatchers.h
+++ include/clang/ASTMatchers/ASTMatchers.h
@@ -4654,6 +4654,21 @@
 ///   matches "typedef int X"
 AST_TYPE_MATCHER(TypedefType, typedefType);
 
+/// \brief Matches enum types.
+///
+/// Given
+/// \code
+///   enum C { Green };
+///   enum class S { Red };
+///
+///   C c;
+///   S s;
+/// \endcode
+//
+/// \c enumType() matches the type of the variable declarations of both \c c 
and
+/// \c s.
+AST_TYPE_MATCHER(EnumType, enumType);
+
 /// \brief Matches template specialization types.
 ///
 /// Given
Index: docs/LibASTMatchersReference.html
===
--- docs/LibASTMatchersReference.html
+++ docs/LibASTMatchersReference.html
@@ -1448,6 +1448,21 @@
 
 
 
+Matcherhttp://clang.llvm.org/doxygen/classclang_1_1Type.html;>TypeenumTypeMatcherhttp://clang.llvm.org/doxygen/classclang_1_1EnumType.html;>EnumType...
+Matches enum types.
+
+Given
+  enum C { Green };
+  enum S { Red };
+
+  C c;
+  S s;
+
+enumType() matches the type of the variable declarations of both c and
+s.
+
+
+
 Matcherhttp://clang.llvm.org/doxygen/classclang_1_1Type.html;>TypefunctionProtoTypeMatcherhttp://clang.llvm.org/doxygen/classclang_1_1FunctionProtoType.html;>FunctionProtoType...
 Matches 
FunctionProtoType nodes.
 


Index: unittests/ASTMatchers/ASTMatchersNodeTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersNodeTest.cpp
+++ unittests/ASTMatchers/ASTMatchersNodeTest.cpp
@@ -1299,6 +1299,13 @@
 hasType(rValueReferenceType();
 }
 
+TEST(TypeMatching, MatchesEnumTypes) {
+  EXPECT_TRUE(matches("enum Color { Green }; Color color;",
+  loc(enumType(;
+  EXPECT_TRUE(matches("enum class Color { Green }; Color color;",
+  loc(enumType(;
+}
+
 TEST(TypeMatching, MatchesPointersToConstTypes) {
   EXPECT_TRUE(matches("int b; int * const a = ",
   loc(pointerType(;
Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -171,6 +171,7 @@
   REGISTER_MATCHER(elaboratedType);
   REGISTER_MATCHER(enumConstantDecl);
   REGISTER_MATCHER(enumDecl);
+  REGISTER_MATCHER(enumType);
   REGISTER_MATCHER(equalsBoundNode);
   REGISTER_MATCHER(equalsIntegralValue);
   REGISTER_MATCHER(explicitCastExpr);
Index: include/clang/ASTMatchers/ASTMatchers.h
===
--- include/clang/ASTMatchers/ASTMatchers.h
+++ include/clang/ASTMatchers/ASTMatchers.h
@@ -4654,6 +4654,21 @@
 ///   matches "typedef int X"
 AST_TYPE_MATCHER(TypedefType, typedefType);
 
+/// \brief Matches enum types.
+///
+/// Given
+/// \code
+///   enum C { Green };
+///   enum class S { Red };
+///
+///   C c;
+///   S s;
+/// \endcode
+//
+/// \c enumType() matches the type of the variable declarations of both \c c and
+/// \c s.
+AST_TYPE_MATCHER(EnumType, enumType);
+
 /// \brief Matches template specialization types.
 ///
 /// Given
Index: docs/LibASTMatchersReference.html
===
--- docs/LibASTMatchersReference.html
+++ 

Re: [PATCH] D20602: Add .rgba syntax extension to ext_vector_type types

2016-06-29 Thread Richard Smith via cfe-commits
rsmith added inline comments.


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:7907
@@ -7904,1 +7906,3 @@
+def ext_opencl_ext_vector_type_rgba_selector: ExtWarn<
+  "vector component name '%0' is an OpenCL version 2.2 feature">;
 } // end of sema category

As mentioned, normal Clang policy is to issue an `ExtWarn` in such cases unless 
there is some actual problem with accepting the feature as an extension. This 
*does* cause us to produce a diagnostic, which, as you say, is important.

The C and C++ standards are both clear that producing a diagnostic is a 
sufficient response to code that is ill-formed, and that we are still allowed 
to accept the program after producing the diagnostic; if the OpenCL 
specification says something else, it is simply broken and we should get it 
fixed.


Comment at: test/Misc/warning-flags.c:15-19
@@ -14,7 +14,7 @@
 
 If you add a new warning without a flag, this test will fail.  To fix
 this test, simply add a warning group to that warning.
 
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 

Please follow these instructions.


http://reviews.llvm.org/D20602



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


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread Ben Craig via cfe-commits
bcraig added a comment.

> Hmm, maybe?  If other global destructors run after ~DtorListHolder(), and 
> they cause a thread_local to be initialized for the first time, 
> __cxa_thread_atexit() might be called again.  I was thinking that dtors would 
> get re-initialized in that case but it appears it does not.  So yeah, I think 
> I'll need to leak the pthread_key_t.

> 

> I'm not sure how to avoid leaking the actual thread_local objects that get 
> created in that situation.  There's nothing left to trigger run_dtors() a 
> second time.


I'm not concerned about the loss of memory or pthread_key resources in this 
leak, as it is a very short-lived leak (the process is going away after all).  
We do need to have an idea of what happens with the destructor invocations for 
the other kinds of resources though.

I think the C++14 spec says what should happen.

> 3.6.3 Termination

> 

> 1. [...] The completions of the destructors for all initialized objects with 
> thread storage duration within that thread are sequenced before the 
> initiation of the destructors of any object with static storage duration. If 
> the completion of the constructor or dynamic initialization of an object with 
> thread storage duration is sequenced before that of another, the completion 
> of the destructor of the second is sequenced before the initiation of the 
> destructor of the first. If the completion of the constructor or dynamic 
> initialization of an object with static storage duration is sequenced before 
> that of another, the completion of the destructor of the second is sequenced 
> before the initiation of the destructor of the first.


What that means for this implementation is that I think that 
__cxa_thread_atexit is allowed to be called during run_dtors.  If running the 
dtor for a thread local variable 'cat', we encounter a previously unseen 
thread_local 'dog', the compiler will call the ctor, then register the dtor 
with __cxa_thread_atexit.  Since it is the most recently constructed thread 
local object, I would expect the 'dog' dtor to be the next dtor to be run.  You 
may be able to support this just by moving "elem = elem->next" below the dtor 
invocation.


http://reviews.llvm.org/D21803



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


Re: [cfe-dev] RFC: Default language standard mode policy

2016-06-29 Thread Richard Smith via cfe-commits
On Wed, Jun 29, 2016 at 12:55 PM, Hal Finkel via cfe-dev <
cfe-...@lists.llvm.org> wrote:

>
> --
>
> *From: *"Richard Smith via cfe-commits" 
> *To: *"cfe-commits" , "Clang Dev" <
> cfe-...@lists.llvm.org>
> *Sent: *Wednesday, June 29, 2016 2:09:37 PM
> *Subject: *RFC: Default language standard mode policy
>
> Hi all!
>
> I'd like to establish a policy for Clang's default language standard (if
> none is specified with -std), as follows:
>
>   Clang defaults to the most recent published standard for the selected
> language that it fully implements.
>
> The practical impact of this is that clang++ will default to C++14 for C++
> compilations (for version 3.9 onwards) and will default to C++17 once our
> implementation support is complete and the standard is published (whichever
> happens later).
>
> I think that we need to include libc++ in this criteria as well. I think
> we'll also need some CMake flags to adjust the default for builds for
> systems on which this won't work.
>

Right, it doesn't make sense to change our default in a way that breaks use
of the same version of libc++, or a supported version of libstdc++ (and we
should establish how old a version of libstdc++ we support here).

However, I don't immediately see that we need to wait for libc++ to be
feature-complete before we enable the new standard in Clang. If that's what
you're suggesting, can you expand on why? We already have the SD-6 feature
test macros to test for implementation of specific features.

> I'd suggest that we apply the same policy for clang-cl, but if it's
> important that we enable a not-yet-fully-implemented standard for cl
> compatibility, that seems reasonable.
>
> The question of whether the default mode for the GCC-compatible driver
> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
> discussing. Enabling GNU keywords by default is a very odd choice, and if
> we believe we can change our defaults without breaking the world then this
> seems like a good time to do so.
>
> Unfortunately, on many systems, some standard system headers won't even
> parse without GNU extensions enabled. I think we'll need to leave the GNU
> extensions on by default (at least for parsing system headers).
>

Can you give an example? -std=c++11 works fine on a broad range of systems.
Note that this is not about GNU *extensions*, which are enabled in both
modes; it's about GNU *keywords* (and a small number of non-conforming
extensions) -- in particular, the 'typeof' GNU keyword, and support for the
asm keyword in C and the inline keyword in C89 (without __decoration__).

> I also intend to make explicit in our documentation that our -std=XXX flag
> enables the selected standard, *plus all relevant issues in Defect Report
> status from the relevant language committee* (it doesn't make sense to
> support a language without its bugfixes).
>
> +1
>
>  -Hal
>
>
> Thoughts?
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: RFC: Default language standard mode policy

2016-06-29 Thread Hal Finkel via cfe-commits
- Original Message -

> From: "Richard Smith via cfe-commits" 
> To: "cfe-commits" , "Clang Dev"
> 
> Sent: Wednesday, June 29, 2016 2:09:37 PM
> Subject: RFC: Default language standard mode policy

> Hi all!

> I'd like to establish a policy for Clang's default language standard
> (if none is specified with -std), as follows:

> Clang defaults to the most recent published standard for the selected
> language that it fully implements.

> The practical impact of this is that clang++ will default to C++14
> for C++ compilations (for version 3.9 onwards) and will default to
> C++17 once our implementation support is complete and the standard
> is published (whichever happens later).
I think that we need to include libc++ in this criteria as well. I think we'll 
also need some CMake flags to adjust the default for builds for systems on 
which this won't work. 

> I'd suggest that we apply the same policy for clang-cl, but if it's
> important that we enable a not-yet-fully-implemented standard for cl
> compatibility, that seems reasonable.

> The question of whether the default mode for the GCC-compatible
> driver should be -std=gnuXXX or -std=cXXX is separate, but also
> likely worth discussing. Enabling GNU keywords by default is a very
> odd choice, and if we believe we can change our defaults without
> breaking the world then this seems like a good time to do so.
Unfortunately, on many systems, some standard system headers won't even parse 
without GNU extensions enabled. I think we'll need to leave the GNU extensions 
on by default (at least for parsing system headers). 

> I also intend to make explicit in our documentation that our -std=XXX
> flag enables the selected standard, *plus all relevant issues in
> Defect Report status from the relevant language committee* (it
> doesn't make sense to support a language without its bugfixes).
+1 

-Hal 

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

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: RFC: Default language standard mode policy

2016-06-29 Thread Chandler Carruth via cfe-commits
On Wed, Jun 29, 2016 at 12:47 PM Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Wed, Jun 29, 2016 at 3:25 PM, Richard Smith 
> wrote:
>
>> Note that at this point I'd like to mainly focus on what our policy
>> should be;
>>
>
> Fair enough. I don't have a strong opinion on that; your proposal makes
> sense to me. (Except for clang-cl, which I think needs to mirror what cl
> does.)
>

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


Re: RFC: Default language standard mode policy

2016-06-29 Thread Richard Smith via cfe-commits
On Wed, Jun 29, 2016 at 12:30 PM, Sean Silva  wrote:

>
>
> On Wed, Jun 29, 2016 at 12:09 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi all!
>>
>> I'd like to establish a policy for Clang's default language standard (if
>> none is specified with -std), as follows:
>>
>>   Clang defaults to the most recent published standard for the selected
>> language that it fully implements.
>>
>> The practical impact of this is that clang++ will default to C++14 for
>> C++ compilations (for version 3.9 onwards) and will default to C++17 once
>> our implementation support is complete and the standard is published
>> (whichever happens later).
>>
>> I'd suggest that we apply the same policy for clang-cl, but if it's
>> important that we enable a not-yet-fully-implemented standard for cl
>> compatibility, that seems reasonable.
>>
>> The question of whether the default mode for the GCC-compatible driver
>> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
>> discussing. Enabling GNU keywords by default is a very odd choice, and if
>> we believe we can change our defaults without breaking the world then this
>> seems like a good time to do so.
>>
>
> Using cXXX instead of gnuXXX would break the world on PS4. So for sure
> with `-std=c++latest` we would end up proposing a patch to change this for
> the PS4 target to gnu++latest (or gnu++11 if gnu++latest is not feasible).
>

OK. Out of interest, is it the GNU keywords that you need, or some other
effect of the difference between modes?


> (As I'm sure you're aware, we have pending to upstream a patch that makes
> -std=gnu++11 the default C++ language mode on PS4 (just blocked on fixing
> tests to not assume the existing std)).
>
> It may be feasible for us to use a "-std=gnu++latest" behavior and not
> have to have a PS4-specific default; CC'ing Warren and Paul.
>
> -- Sean Silva
>
>
>>
>> I also intend to make explicit in our documentation that our -std=XXX
>> flag enables the selected standard, *plus all relevant issues in Defect
>> Report status from the relevant language committee* (it doesn't make sense
>> to support a language without its bugfixes).
>>
>> Thoughts?
>>
>> ___
>> 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: [PATCH] D21705: Include debug info for nested structs and classes

2016-06-29 Thread Reid Kleckner via cfe-commits
rnk added inline comments.


Comment at: lib/CodeGen/CGDebugInfo.cpp:1075
@@ +1074,3 @@
+  } else if (const auto *nestedRec = dyn_cast(I)) {
+if (!nestedRec->isImplicit())
+  CollectRecordNestedRecord(nestedRec, elements);

I would add `&& nestedRec->getDeclContext() == record` to this condition to 
deal with the `struct B { B(struct A*); };` test case.


Comment at: test/CodeGenObjCXX/debug-info-cyclic.mm:11
@@ -10,3 +10,3 @@
 // CHECK-SAME: identifier:
-// CHECK: ![[BMEMBERS]] = !{![[BB:[0-9]+]]}
+// CHECK: ![[BMEMBERS]] = !{![[A:[0-9]+]], ![[BB:[0-9]+]]}
   B(struct A *);

This is interesting, this test case shouldn't change. The lexical context for 
'struct A' is B, but the semantic context is the surrounding TU. We should only 
list class members that use the parent class as their DeclContext.

Also, why is this an Obj-C++ test in the first place, it only uses C++...


http://reviews.llvm.org/D21705



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


Re: RFC: Default language standard mode policy

2016-06-29 Thread Nico Weber via cfe-commits
On Wed, Jun 29, 2016 at 3:25 PM, Richard Smith 
wrote:

> On Wed, Jun 29, 2016 at 12:14 PM, Nico Weber  wrote:
>
>> For clang-cl, we should follow cl's model of selecting a standard. Before
>> C++17, this was "use newest language the compiler knows about" (keyed off
>> -fmsc-version; clang-cl detects the system msvc version by default if
>> that's not passed in). After C++17, there's an explicit language flag, and
>> we use the same default as cl.
>>
>
> Is that default something other than "the newest one"?
>

It looks like the next MSVC (which adds that flag) defaults to C++14. (See
majnemer's r273841 which implemented this in clang-cl, and
https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/
)


> Last I checked (which was a while ago), libstdc++ didn't parse with
>> -std=c++14, at least at some version. I don't remember which version of
>> libstdc++ I tried (maybe 4.9?). Should that factor into the decision? Not
>> parsing standard library headers by default on Linux seems like a somewhat
>> suboptimal user experience.
>>
>
> Last time I looked into this, I saw only one problem with version 4.9:
> libc doesn't provide ::gets to C++14, and earlier versions of libstdc++
> assume it's there and do "namespace std { using ::gets; }". We can add a
> compatibility hack to clang to work around this.
>
> Note that at this point I'd like to mainly focus on what our policy should
> be;
>

Fair enough. I don't have a strong opinion on that; your proposal makes
sense to me. (Except for clang-cl, which I think needs to mirror what cl
does.)


> there are certainly technical challenges involved in actually applying the
> policy (another one is that clang's test suite still has some failures when
> the default is changed, but Charles Li has made tremendous headway on
> this), and if we can't actually prepare for the transition in the C++
> default in time for 3.9, then so be it.
>
>
>> On Wed, Jun 29, 2016 at 3:09 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi all!
>>>
>>> I'd like to establish a policy for Clang's default language standard (if
>>> none is specified with -std), as follows:
>>>
>>>   Clang defaults to the most recent published standard for the selected
>>> language that it fully implements.
>>>
>>> The practical impact of this is that clang++ will default to C++14 for
>>> C++ compilations (for version 3.9 onwards) and will default to C++17 once
>>> our implementation support is complete and the standard is published
>>> (whichever happens later).
>>>
>>> I'd suggest that we apply the same policy for clang-cl, but if it's
>>> important that we enable a not-yet-fully-implemented standard for cl
>>> compatibility, that seems reasonable.
>>>
>>> The question of whether the default mode for the GCC-compatible driver
>>> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
>>> discussing. Enabling GNU keywords by default is a very odd choice, and if
>>> we believe we can change our defaults without breaking the world then this
>>> seems like a good time to do so.
>>>
>>> I also intend to make explicit in our documentation that our -std=XXX
>>> flag enables the selected standard, *plus all relevant issues in Defect
>>> Report status from the relevant language committee* (it doesn't make sense
>>> to support a language without its bugfixes).
>>>
>>> Thoughts?
>>>
>>> ___
>>> 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


r274150 - [OpenCL] Allow -cl-std and other standard -cl- options in driver

2016-06-29 Thread Yaxun Liu via cfe-commits
Author: yaxunl
Date: Wed Jun 29 14:39:32 2016
New Revision: 274150

URL: http://llvm.org/viewvc/llvm-project?rev=274150=rev
Log:
[OpenCL] Allow -cl-std and other standard -cl- options in driver

Allow -cl-std and other standard -cl- options from cc1 to driver.

Added a test for the options moved.

Patch by Aaron En Ye Shi.

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/opencl.cl

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=274150=274149=274150=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Wed Jun 29 
14:39:32 2016
@@ -214,4 +214,7 @@ def err_missing_vfs_overlay_file : Error
   "virtual filesystem overlay file '%0' not found">, DefaultFatal;
 def err_invalid_vfs_overlay : Error<
   "invalid virtual filesystem overlay file '%0'">, DefaultFatal;
-}
+
+def warn_option_invalid_ocl_version : Warning<
+  "OpenCL version %0 does not support the option '%1'">, InGroup;
+}
\ No newline at end of file

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=274150=274149=274150=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Wed Jun 29 14:39:32 2016
@@ -664,31 +664,6 @@ def detailed_preprocessing_record : Flag
   HelpText<"include a detailed record of preprocessing actions">;
 
 
//===--===//
-// OpenCL Options
-//===--===//
-
-def cl_opt_disable : Flag<["-"], "cl-opt-disable">,
-  HelpText<"OpenCL only. This option disables all optimizations. The default 
is optimizations are enabled.">;
-def cl_strict_aliasing : Flag<["-"], "cl-strict-aliasing">,
-  HelpText<"OpenCL only. This option does nothing and is for compatibility 
with OpenCL 1.0">;
-def cl_single_precision_constant : Flag<["-"], "cl-single-precision-constant">,
-  HelpText<"OpenCL only. Treat double precision floating-point constant as 
single precision constant.">;
-def cl_finite_math_only : Flag<["-"], "cl-finite-math-only">,
-  HelpText<"OpenCL only. Allow floating-point optimizations that assume 
arguments and results are not NaNs or +-Inf.">;
-def cl_kernel_arg_info : Flag<["-"], "cl-kernel-arg-info">,
-  HelpText<"OpenCL only. Generate kernel argument metadata.">;
-def cl_unsafe_math_optimizations : Flag<["-"], "cl-unsafe-math-optimizations">,
-  HelpText<"OpenCL only. Allow unsafe floating-point optimizations.  Also 
implies -cl-no-signed-zeros and -cl-mad-enable">;
-def cl_fast_relaxed_math : Flag<["-"], "cl-fast-relaxed-math">,
-  HelpText<"OpenCL only. Sets -cl-finite-math-only and 
-cl-unsafe-math-optimizations, and defines __FAST_RELAXED_MATH__">;
-def cl_mad_enable : Flag<["-"], "cl-mad-enable">,
-  HelpText<"OpenCL only. Enable less precise MAD instructions to be 
generated.">;
-def cl_std_EQ : Joined<["-"], "cl-std=">,
-  HelpText<"OpenCL language standard to compile for">;
-def cl_denorms_are_zero : Flag<["-"], "cl-denorms-are-zero">,
-  HelpText<"OpenCL only. Allow denormals to be flushed to zero">;
-
-//===--===//
 // CUDA Options
 
//===--===//
 

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=274150=274149=274150=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Wed Jun 29 14:39:32 2016
@@ -78,6 +78,7 @@ def g_flags_Group : OptionGroup<
 def i_Group   : OptionGroup<"">, Group;
 def clang_i_Group : OptionGroup<"">, Group;
 def m_Group   : OptionGroup<"">, Group;
+def opencl_Group  : OptionGroup<"">, 
Group;
 
 // Feature groups - these take command line options that correspond directly to
 // target specific features and can be translated directly from command line
@@ -366,6 +367,26 @@ def bind__at__load : Flag<["-"], "bind_a
 def bundle__loader : Separate<["-"], "bundle_loader">;
 def bundle : Flag<["-"], "bundle">;
 def b : JoinedOrSeparate<["-"], "b">, Flags<[Unsupported]>;
+def 

Re: [PATCH] D21031: [OpenCL] Allow -cl-std and other standard -cl- options in driver

2016-06-29 Thread Yaxun Liu via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274150: [OpenCL] Allow -cl-std and other standard -cl- 
options in driver (authored by yaxunl).

Changed prior to commit:
  http://reviews.llvm.org/D21031?vs=61574=62267#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21031

Files:
  cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
  cfe/trunk/include/clang/Driver/CC1Options.td
  cfe/trunk/include/clang/Driver/Options.td
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/Driver/opencl.cl

Index: cfe/trunk/test/Driver/opencl.cl
===
--- cfe/trunk/test/Driver/opencl.cl
+++ cfe/trunk/test/Driver/opencl.cl
@@ -1,15 +1,39 @@
-// RUN: %clang -fsyntax-only %s
-// RUN: %clang -fsyntax-only -std=cl %s
-// RUN: %clang -fsyntax-only -std=cl1.1 %s
-// RUN: %clang -fsyntax-only -std=cl1.2 %s
-// RUN: %clang -fsyntax-only -std=cl2.0 %s
-// RUN: %clang -fsyntax-only -std=CL %s
-// RUN: %clang -fsyntax-only -std=CL1.1 %s
-// RUN: %clang -fsyntax-only -std=CL1.2 %s
-// RUN: %clang -fsyntax-only -std=CL2.0 %s
-// RUN: not %clang_cc1 -std=c99 -DOPENCL %s 2>&1 | FileCheck --check-prefix=CHECK-C99 %s
-// RUN: not %clang_cc1 -std=invalid -DOPENCL %s 2>&1 | FileCheck --check-prefix=CHECK-INVALID %s
-// CHECK-C99: error: invalid argument '-std=c99' not allowed with 'OpenCL'
-// CHECK-INVALID: error: invalid value 'invalid' in '-std=invalid'
+// 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
+// RUN: %clang -S -### -cl-mad-enable %s | FileCheck --check-prefix=CHECK-MAD-ENABLE %s
+// RUN: %clang -S -### -cl-denorms-are-zero %s | FileCheck --check-prefix=CHECK-DENORMS-ARE-ZERO %s
+// RUN: not %clang_cc1 -cl-std=c99 -DOPENCL %s 2>&1 | FileCheck --check-prefix=CHECK-C99 %s
+// RUN: not %clang_cc1 -cl-std=invalid -DOPENCL %s 2>&1 | FileCheck --check-prefix=CHECK-INVALID %s
+
+// CHECK-CL: .*clang.* "-cc1" .* "-cl-std=CL"
+// CHECK-CL11: .*clang.* "-cc1" .* "-cl-std=CL1.1"
+// CHECK-CL12: .*clang.* "-cc1" .* "-cl-std=CL1.2"
+// CHECK-CL20: .*clang.* "-cc1" .* "-cl-std=CL2.0"
+// CHECK-OPT-DISABLE: .*clang.* "-cc1" .* "-cl-opt-disable"
+// CHECK-STRICT-ALIASING: .*clang.* "-cc1" .* "-cl-strict-aliasing"
+// CHECK-INVALID-OPENCL-VERSION11: OpenCL version 1.1 does not support the option 'cl-strict-aliasing'
+// CHECK-INVALID-OPENCL-VERSION12: OpenCL version 1.2 does not support the option 'cl-strict-aliasing'
+// CHECK-INVALID-OPENCL-VERSION20: OpenCL version 2.0 does not support the option 'cl-strict-aliasing'
+// CHECK-SINGLE-PRECISION-CONST: .*clang.* "-cc1" .* "-cl-single-precision-constant"
+// CHECK-FINITE-MATH-ONLY: .*clang.* "-cc1" .* "-cl-finite-math-only"
+// CHECK-KERNEL-ARG-INFO: .*clang.* "-cc1" .* "-cl-kernel-arg-info"
+// CHECK-UNSAFE-MATH-OPT: .*clang.* "-cc1" .* "-cl-unsafe-math-optimizations"
+// CHECK-FAST-RELAXED-MATH: .*clang.* "-cc1" .* "-cl-fast-relaxed-math"
+// CHECK-MAD-ENABLE: .*clang.* "-cc1" .* "-cl-mad-enable"
+// CHECK-DENORMS-ARE-ZERO: .*clang.* "-cc1" .* "-cl-denorms-are-zero"
+// CHECK-C99: error: invalid argument '-cl-std=c99' not allowed with 'OpenCL'
+// CHECK-INVALID: error: invalid value 'invalid' in '-cl-std=invalid'
 
 kernel void func(void);
Index: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
===
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp
@@ -41,6 +41,7 @@
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Process.h"
 #include "llvm/Target/TargetOptions.h"
+#include 

Re: RFC: Default language standard mode policy

2016-06-29 Thread Sean Silva via cfe-commits
On Wed, Jun 29, 2016 at 12:09 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi all!
>
> I'd like to establish a policy for Clang's default language standard (if
> none is specified with -std), as follows:
>
>   Clang defaults to the most recent published standard for the selected
> language that it fully implements.
>
> The practical impact of this is that clang++ will default to C++14 for C++
> compilations (for version 3.9 onwards) and will default to C++17 once our
> implementation support is complete and the standard is published (whichever
> happens later).
>
> I'd suggest that we apply the same policy for clang-cl, but if it's
> important that we enable a not-yet-fully-implemented standard for cl
> compatibility, that seems reasonable.
>
> The question of whether the default mode for the GCC-compatible driver
> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
> discussing. Enabling GNU keywords by default is a very odd choice, and if
> we believe we can change our defaults without breaking the world then this
> seems like a good time to do so.
>

Using cXXX instead of gnuXXX would break the world on PS4. So for sure with
`-std=c++latest` we would end up proposing a patch to change this for the
PS4 target to gnu++latest (or gnu++11 if gnu++latest is not feasible).
(As I'm sure you're aware, we have pending to upstream a patch that makes
-std=gnu++11 the default C++ language mode on PS4 (just blocked on fixing
tests to not assume the existing std)).

It may be feasible for us to use a "-std=gnu++latest" behavior and not have
to have a PS4-specific default; CC'ing Warren and Paul.

-- Sean Silva


>
> I also intend to make explicit in our documentation that our -std=XXX flag
> enables the selected standard, *plus all relevant issues in Defect Report
> status from the relevant language committee* (it doesn't make sense to
> support a language without its bugfixes).
>
> Thoughts?
>
> ___
> 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: RFC: Default language standard mode policy

2016-06-29 Thread Richard Smith via cfe-commits
On Wed, Jun 29, 2016 at 12:14 PM, Nico Weber  wrote:

> For clang-cl, we should follow cl's model of selecting a standard. Before
> C++17, this was "use newest language the compiler knows about" (keyed off
> -fmsc-version; clang-cl detects the system msvc version by default if
> that's not passed in). After C++17, there's an explicit language flag, and
> we use the same default as cl.
>

Is that default something other than "the newest one"?

Last I checked (which was a while ago), libstdc++ didn't parse with
> -std=c++14, at least at some version. I don't remember which version of
> libstdc++ I tried (maybe 4.9?). Should that factor into the decision? Not
> parsing standard library headers by default on Linux seems like a somewhat
> suboptimal user experience.
>

Last time I looked into this, I saw only one problem with version 4.9: libc
doesn't provide ::gets to C++14, and earlier versions of libstdc++ assume
it's there and do "namespace std { using ::gets; }". We can add a
compatibility hack to clang to work around this.

Note that at this point I'd like to mainly focus on what our policy should
be; there are certainly technical challenges involved in actually applying
the policy (another one is that clang's test suite still has some failures
when the default is changed, but Charles Li has made tremendous headway on
this), and if we can't actually prepare for the transition in the C++
default in time for 3.9, then so be it.


> On Wed, Jun 29, 2016 at 3:09 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi all!
>>
>> I'd like to establish a policy for Clang's default language standard (if
>> none is specified with -std), as follows:
>>
>>   Clang defaults to the most recent published standard for the selected
>> language that it fully implements.
>>
>> The practical impact of this is that clang++ will default to C++14 for
>> C++ compilations (for version 3.9 onwards) and will default to C++17 once
>> our implementation support is complete and the standard is published
>> (whichever happens later).
>>
>> I'd suggest that we apply the same policy for clang-cl, but if it's
>> important that we enable a not-yet-fully-implemented standard for cl
>> compatibility, that seems reasonable.
>>
>> The question of whether the default mode for the GCC-compatible driver
>> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
>> discussing. Enabling GNU keywords by default is a very odd choice, and if
>> we believe we can change our defaults without breaking the world then this
>> seems like a good time to do so.
>>
>> I also intend to make explicit in our documentation that our -std=XXX
>> flag enables the selected standard, *plus all relevant issues in Defect
>> Report status from the relevant language committee* (it doesn't make sense
>> to support a language without its bugfixes).
>>
>> Thoughts?
>>
>> ___
>> 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: RFC: Default language standard mode policy

2016-06-29 Thread Nico Weber via cfe-commits
For clang-cl, we should follow cl's model of selecting a standard. Before
C++17, this was "use newest language the compiler knows about" (keyed off
-fmsc-version; clang-cl detects the system msvc version by default if
that's not passed in). After C++17, there's an explicit language flag, and
we use the same default as cl.

Last I checked (which was a while ago), libstdc++ didn't parse with
-std=c++14, at least at some version. I don't remember which version of
libstdc++ I tried (maybe 4.9?). Should that factor into the decision? Not
parsing standard library headers by default on Linux seems like a somewhat
suboptimal user experience.

On Wed, Jun 29, 2016 at 3:09 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi all!
>
> I'd like to establish a policy for Clang's default language standard (if
> none is specified with -std), as follows:
>
>   Clang defaults to the most recent published standard for the selected
> language that it fully implements.
>
> The practical impact of this is that clang++ will default to C++14 for C++
> compilations (for version 3.9 onwards) and will default to C++17 once our
> implementation support is complete and the standard is published (whichever
> happens later).
>
> I'd suggest that we apply the same policy for clang-cl, but if it's
> important that we enable a not-yet-fully-implemented standard for cl
> compatibility, that seems reasonable.
>
> The question of whether the default mode for the GCC-compatible driver
> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
> discussing. Enabling GNU keywords by default is a very odd choice, and if
> we believe we can change our defaults without breaking the world then this
> seems like a good time to do so.
>
> I also intend to make explicit in our documentation that our -std=XXX flag
> enables the selected standard, *plus all relevant issues in Defect Report
> status from the relevant language committee* (it doesn't make sense to
> support a language without its bugfixes).
>
> Thoughts?
>
> ___
> 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


RFC: Default language standard mode policy

2016-06-29 Thread Richard Smith via cfe-commits
Hi all!

I'd like to establish a policy for Clang's default language standard (if
none is specified with -std), as follows:

  Clang defaults to the most recent published standard for the selected
language that it fully implements.

The practical impact of this is that clang++ will default to C++14 for C++
compilations (for version 3.9 onwards) and will default to C++17 once our
implementation support is complete and the standard is published (whichever
happens later).

I'd suggest that we apply the same policy for clang-cl, but if it's
important that we enable a not-yet-fully-implemented standard for cl
compatibility, that seems reasonable.

The question of whether the default mode for the GCC-compatible driver
should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
discussing. Enabling GNU keywords by default is a very odd choice, and if
we believe we can change our defaults without breaking the world then this
seems like a good time to do so.

I also intend to make explicit in our documentation that our -std=XXX flag
enables the selected standard, *plus all relevant issues in Defect Report
status from the relevant language committee* (it doesn't make sense to
support a language without its bugfixes).

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


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

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, 
andreybokhanko, Hahnfeld, cfe-commits.
Herald added a subscriber: mehdi_amini.

This patch adds the support to create jobs for the `OffloadBundlingAction` 
which will invoke the `clang-offload-bundler` tool to unbundle input files.

Unlike other actions, unbundling actions have multiple outputs. Therefore, this 
patch adds the required changes to have a variant of `Tool::ConstructJob` with 
multiple outputs. 

The way the naming of the results is implemented is also slightly modified so 
that the same action can use a different offloading prefix for each use by the 
different offloading actions. 

http://reviews.llvm.org/D21857

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

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -176,7 +176,7 @@
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-llvm-bc" {{.*}}"-pic-level" "2" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1BC:.+\.bc]]" "-x" "cpp-output" "[[T1PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1ASM:.+\.s]]" "-x" "ir" "[[T1BC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le-ibm-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "[[T1ASM]]"
-// CHK-COMMANDS-ST: ld" {{.*}}"-shared" "-o" "[[T1BIN:.+\.out-device-openmp-powerpc64le-ibm-linux-gnu]]" {{.*}}[[T1OBJ]]
+// CHK-COMMANDS-ST: ld" {{.*}}"-shared" "-o" "[[T1BIN:.+\.out-openmp-powerpc64le-ibm-linux-gnu]]" {{.*}}[[T1OBJ]]
 
 //
 // Compile for the x86 device.
@@ -187,7 +187,7 @@
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-llvm-bc" {{.*}}"-pic-level" "2" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2BC:.+\.bc]]" "-x" "cpp-output" "[[T2PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2ASM:.+\.s]]" "-x" "ir" "[[T2BC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1as" "-triple" "x86_64-pc-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T2OBJ:.+\.o]]" "[[T2ASM]]"
-// CHK-COMMANDS-ST: ld" {{.*}}"-shared" "-o" "[[T2BIN:.+\.out-device-openmp-x86_64-pc-linux-gnu]]" {{.*}}[[T2OBJ]]
+// CHK-COMMANDS-ST: ld" {{.*}}"-shared" "-o" "[[T2BIN:.+\.out-openmp-x86_64-pc-linux-gnu]]" {{.*}}[[T2OBJ]]
 
 //
 // Generate host object from the BC file and link using the linker script.
@@ -202,20 +202,20 @@
 // Check the linker script contains what we expect.
 //
 // CHK-LKS: TARGET(binary)
-// CHK-LKS: INPUT({{.+}}.out-device-openmp-powerpc64le-ibm-linux-gnu)
-// CHK-LKS: INPUT({{.+}}.out-device-openmp-x86_64-pc-linux-gnu)
+// CHK-LKS: INPUT({{.+}}.out-openmp-powerpc64le-ibm-linux-gnu)
+// CHK-LKS: INPUT({{.+}}.out-openmp-x86_64-pc-linux-gnu)
 // CHK-LKS: SECTIONS
 // CHK-LKS: {
 // CHK-LKS:   .omp_offloading :
 // CHK-LKS:   ALIGN(0x10)
 // CHK-LKS:   {
 // CHK-LKS: . = ALIGN(0x10);
 // CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_start.powerpc64le-ibm-linux-gnu = .);
-// CHK-LKS: {{.+}}.out-device-openmp-powerpc64le-ibm-linux-gnu
+// CHK-LKS: {{.+}}.out-openmp-powerpc64le-ibm-linux-gnu
 // CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_end.powerpc64le-ibm-linux-gnu = .);
 // CHK-LKS: . = ALIGN(0x10);
 // CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_start.x86_64-pc-linux-gnu = .);
-// CHK-LKS: {{.+}}.out-device-openmp-x86_64-pc-linux-gnu
+// CHK-LKS: {{.+}}.out-openmp-x86_64-pc-linux-gnu
 // CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_end.x86_64-pc-linux-gnu = .);
 // CHK-LKS:   }
 // CHK-LKS:   .omp_offloading.entries :
@@ -343,3 +343,92 @@
 // CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTASM:.+\.s]]" "-x" "ir" "[[HOSTBC]]"
 // CHK-BUJOBS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le--linux" "-filetype" "obj" {{.*}}"-o" "[[HOSTOBJ:.+\.o]]" "[[HOSTASM]]"
 // CHK-BUJOBS-ST: clang-offload-bundler" "-type=o" "-targets=openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu,host-powerpc64le--linux" "-outputs=[[RES:.+\.o]]" "-inputs=[[T1OBJ]],[[T2OBJ]],[[HOSTOBJ]]"
+
+/// ###
+
+/// Check separate compilation with offloading - unbundling jobs construct
+// RUN:   touch %t.i
+// RUN:   %clang -###  -fopenmp -o %t.out -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %t.i 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-UBJOBS %s
+// RUN:   

r274149 - Add CapturedDecl::parameters() ArrayRef accessors following r273647.

2016-06-29 Thread Yaron Keren via cfe-commits
Author: yrnkrn
Date: Wed Jun 29 13:55:53 2016
New Revision: 274149

URL: http://llvm.org/viewvc/llvm-project?rev=274149=rev
Log:
Add CapturedDecl::parameters() ArrayRef accessors following r273647.


Modified:
cfe/trunk/include/clang/AST/Decl.h

Modified: cfe/trunk/include/clang/AST/Decl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=274149=274148=274149=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Wed Jun 29 13:55:53 2016
@@ -3661,6 +3661,14 @@ public:
 getParams()[i] = P;
   }
 
+  // ArrayRef interface to parameters.
+  ArrayRef parameters() const {
+return {getParams(), getNumParams()};
+  }
+  MutableArrayRef parameters() {
+return {getParams(), getNumParams()};
+  }
+
   /// \brief Retrieve the parameter containing captured variables.
   ImplicitParamDecl *getContextParam() const {
 assert(ContextParam < NumParams);


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


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

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, 
andreybokhanko, Hahnfeld, cfe-commits.
Herald added a subscriber: mehdi_amini.

This patch adds the support to create a job for the `OffloadBundlingAction` 
which will invoke the `clang-offload-bundler` tool.

http://reviews.llvm.org/D21856

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

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

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

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, 
andreybokhanko, Hahnfeld, cfe-commits.
Herald added a subscriber: mehdi_amini.

In order to save the user from dealing with multiple output files (for host and 
device) while using separate compilation, a new action `OffloadBundlingAction` 
is used when the last phase is not linking. This action will then result in a 
job that uses the proposed bundling tool to create a single 
preprocessed/IR/ASM/Object file from multiple ones.

The job creation for the new action will be proposed in a separate patch.

http://reviews.llvm.org/D21852

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

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -228,3 +228,31 @@
 // CHK-LKS:   }
 // CHK-LKS: }
 // CHK-LKS: INSERT BEFORE .data
+
+
+/// ###
+
+/// Check separate compilation with offloading - bundling actions
+// RUN:   %clang -### -ccc-print-phases -fopenmp -c -o %t.o -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BUACTIONS %s
+
+// CHK-BUACTIONS: 0: input, "[[INPUT:.+\.c]]", c, (host-openmp)
+// CHK-BUACTIONS: 1: preprocessor, {0}, cpp-output, (host-openmp)
+// CHK-BUACTIONS: 2: compiler, {1}, ir, (host-openmp)
+// CHK-BUACTIONS: 3: input, "[[INPUT]]", c, (device-openmp)
+// CHK-BUACTIONS: 4: preprocessor, {3}, cpp-output, (device-openmp)
+// CHK-BUACTIONS: 5: compiler, {4}, ir, (device-openmp)
+// CHK-BUACTIONS: 6: offload, "host-openmp (powerpc64le--linux)" {2}, "device-openmp (powerpc64le-ibm-linux-gnu)" {5}, ir
+// CHK-BUACTIONS: 7: backend, {6}, assembler, (device-openmp)
+// CHK-BUACTIONS: 8: assembler, {7}, object, (device-openmp)
+// CHK-BUACTIONS: 9: offload, "device-openmp (powerpc64le-ibm-linux-gnu)" {8}, object
+// CHK-BUACTIONS: 10: input, "[[INPUT]]", c, (device-openmp)
+// CHK-BUACTIONS: 11: preprocessor, {10}, cpp-output, (device-openmp)
+// CHK-BUACTIONS: 12: compiler, {11}, ir, (device-openmp)
+// CHK-BUACTIONS: 13: offload, "host-openmp (powerpc64le--linux)" {2}, "device-openmp (x86_64-pc-linux-gnu)" {12}, ir
+// CHK-BUACTIONS: 14: backend, {13}, assembler, (device-openmp)
+// CHK-BUACTIONS: 15: assembler, {14}, object, (device-openmp)
+// CHK-BUACTIONS: 16: offload, "device-openmp (x86_64-pc-linux-gnu)" {15}, object
+// CHK-BUACTIONS: 17: backend, {2}, assembler, (host-openmp)
+// CHK-BUACTIONS: 18: assembler, {17}, object, (host-openmp)
+// CHK-BUACTIONS: 19: clang-offload-bundler, {9, 16, 18}, object, (host-openmp)
\ No newline at end of file
Index: lib/Driver/ToolChain.cpp
===
--- lib/Driver/ToolChain.cpp
+++ lib/Driver/ToolChain.cpp
@@ -262,6 +262,10 @@
   case Action::VerifyPCHJobClass:
   case Action::BackendJobClass:
 return getClang();
+
+  case Action::OffloadBundlingJobClass:
+// FIXME: Add a tool for the bundling actions.
+return nullptr;
   }
 
   llvm_unreachable("Invalid tool kind.");
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -1530,6 +1530,9 @@
 // are found.
 virtual bool initialize() { return false; }
 
+// \brief Return true if the builder can use bundling/unbundling.
+virtual bool canUseBundlerUnbundler() const { return false; }
+
 // \brief Return true if this builder is valid. We have a valid builder if
 // we have associated device tool chains.
 bool isValid() { return !ToolChains.empty(); }
@@ -1853,6 +1856,26 @@
   return ABRT_Success;
 }
 
+void appendTopLevelActions(ActionList ) override {
+  if (OpenMPDeviceActions.empty())
+return;
+
+  // We should always have an action for each input.
+  assert(OpenMPDeviceActions.size() == ToolChains.size() &&
+ "Number of OpenMP actions and toolchains do not match.");
+
+  // Append all device actions followed by the proper offload action.
+  auto TI = ToolChains.begin();
+  for (auto *A : OpenMPDeviceActions) {
+OffloadAction::DeviceDependences Dep;
+Dep.add(*A, **TI, /*BoundArch=*/nullptr, Action::OFK_OpenMP);
+AL.push_back(C.MakeAction(Dep, A->getType()));
+++TI;
+  }
+  // We no longer need the action stored in this builder.
+  OpenMPDeviceActions.clear();
+}
+
 void appendLinkDependences(OffloadAction::DeviceDependences ) override {
   assert(ToolChains.size() == DeviceLinkerInputs.size() &&
  "Toolchains and linker inputs sizes do not match.");
@@ 

r274147 - Re-land "[MS] Don't expect vftables to be provided for extern template instantiations"

2016-06-29 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Wed Jun 29 13:29:21 2016
New Revision: 274147

URL: http://llvm.org/viewvc/llvm-project?rev=274147=rev
Log:
Re-land "[MS] Don't expect vftables to be provided for extern template 
instantiations"

Reverts r273305 and re-instates r273296.

We needed to fix a bug in Sema::MarkVTableUsed to ensure that operator
delete lookup occurs when the vtable is referenced. We already had a
special case to look up operator delete when dllimport was used, but I
think should really mark virtual destructors referenced any time the
vtable is used.

Added:
cfe/trunk/test/CodeGenCXX/microsoft-abi-extern-template.cpp
Modified:
cfe/trunk/lib/AST/VTableBuilder.cpp
cfe/trunk/lib/CodeGen/CGVTables.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-vbtables.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-vftables.cpp

Modified: cfe/trunk/lib/AST/VTableBuilder.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/VTableBuilder.cpp?rev=274147=274146=274147=diff
==
--- cfe/trunk/lib/AST/VTableBuilder.cpp (original)
+++ cfe/trunk/lib/AST/VTableBuilder.cpp Wed Jun 29 13:29:21 2016
@@ -2545,14 +2545,13 @@ public:
 MostDerivedClassLayout(Context.getASTRecordLayout(MostDerivedClass)),
 WhichVFPtr(*Which),
 Overriders(MostDerivedClass, CharUnits(), MostDerivedClass) {
-// Only include the RTTI component if we know that we will provide a
-// definition of the vftable.  We always provide the definition of
-// dllimported classes.
+// Provide the RTTI component if RTTIData is enabled. If the vftable would
+// be available externally, we should not provide the RTTI componenent. It
+// is currently impossible to get available externally vftables with either
+// dllimport or extern template instantiations, but eventually we may add a
+// flag to support additional devirtualization that needs this.
 if (Context.getLangOpts().RTTIData)
-  if (MostDerivedClass->hasAttr() ||
-  MostDerivedClass->getTemplateSpecializationKind() !=
-  TSK_ExplicitInstantiationDeclaration)
-HasRTTIComponent = true;
+  HasRTTIComponent = true;
 
 LayoutVFTable();
 

Modified: cfe/trunk/lib/CodeGen/CGVTables.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGVTables.cpp?rev=274147=274146=274147=diff
==
--- cfe/trunk/lib/CodeGen/CGVTables.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGVTables.cpp Wed Jun 29 13:29:21 2016
@@ -794,6 +794,10 @@ CodeGenModule::getVTableLinkage(const CX
   return DiscardableODRLinkage;
 
 case TSK_ExplicitInstantiationDeclaration:
+  // Explicit instantiations in MSVC do not provide vtables, so we must 
emit
+  // our own.
+  if (getTarget().getCXXABI().isMicrosoft())
+return DiscardableODRLinkage;
   return shouldEmitAvailableExternallyVTable(*this, RD)
  ? llvm::GlobalVariable::AvailableExternallyLinkage
  : llvm::GlobalVariable::ExternalLinkage;
@@ -839,9 +843,9 @@ CodeGenVTables::GenerateClassData(const
 bool CodeGenVTables::isVTableExternal(const CXXRecordDecl *RD) {
   assert(RD->isDynamicClass() && "Non-dynamic classes have no VTable.");
 
-  // We always synthesize vtables on the import side regardless of whether or
-  // not it is an explicit instantiation declaration.
-  if (CGM.getTarget().getCXXABI().isMicrosoft() && 
RD->hasAttr())
+  // We always synthesize vtables if they are needed in the MS ABI. MSVC 
doesn't
+  // emit them even if there is an explicit template instantiation.
+  if (CGM.getTarget().getCXXABI().isMicrosoft())
 return false;
 
   // If we have an explicit instantiation declaration (and not a

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=274147=274146=274147=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Wed Jun 29 13:29:21 2016
@@ -13425,20 +13425,18 @@ void Sema::MarkVTableUsed(SourceLocation
 // checks (i.e. operator delete() lookup) when the vtable is marked used, 
as
 // the deleting destructor is emitted with the vtable, not with the
 // destructor definition as in the Itanium ABI.
-// If it has a definition, we do the check at that point instead.
 if (Context.getTargetInfo().getCXXABI().isMicrosoft()) {
-  if (Class->hasUserDeclaredDestructor() &&
-  !Class->getDestructor()->isDefined() &&
-  !Class->getDestructor()->isDeleted()) {
-CXXDestructorDecl *DD = Class->getDestructor();
-ContextRAII SavedContext(*this, DD);
-CheckDestructor(DD);
-  } else if (Class->hasAttr()) {
-// We always synthesize vtables on the import side. 

[PATCH] D21851: [Driver][OpenMP][CUDA] Add capability to bundle object files in sections of the host binary format.

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, Hahnfeld, 
andreybokhanko, cfe-commits.
Herald added a subscriber: mehdi_amini.

This patch adds the capability to bundle object files in sections of the host 
binary using a designated naming convention for these sections. This patch uses 
the functionality of the object reader already in the LLVM library to read 
bundled files, and invokes clang with the incremental linking options to create 
bundle files. 

Bundling files involves creating an IR file with the contents of the bundle 
assigned as initializers of globals binded to the designated sections. This way 
the bundling implementation is agnostic of the host object format.

The features added by this patch were requested in the RFC discussion in  
http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html.

http://reviews.llvm.org/D21851

Files:
  test/Driver/clang-offload-bundler.c
  tools/clang-offload-bundler/ClangOffloadBundler.cpp

Index: tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -75,14 +75,23 @@
 /// \brief Magic string that marks the existence of offloading data.
 #define OFFLOAD_BUNDLER_MAGIC_STR "__CLANG_OFFLOAD_BUNDLE__"
 
+/// \brief Path to the current binary.
+static std::string BundlerExecutable;
+
 /// \brief Obtain the offload kind and real machine triple out of the target
 /// information specified by the user.
 static void getOffloadKindAndTriple(StringRef Target, StringRef ,
 StringRef ) {
   auto KindTriplePair = Target.split('-');
   OffloadKind = KindTriplePair.first;
   Triple = KindTriplePair.second;
 }
+static StringRef getTriple(StringRef Target) {
+  StringRef OffloadKind;
+  StringRef Triple;
+  getOffloadKindAndTriple(Target, OffloadKind, Triple);
+  return Triple;
+}
 static bool hasHostKind(StringRef Target) {
   StringRef OffloadKind;
   StringRef Triple;
@@ -312,6 +321,211 @@
   ~BinaryFileHandler() {}
 };
 
+// Handler for object files. The bundles are organized by sections with a
+// designated name.
+//
+// In order to bundle we create an IR file with the content of each section and
+// use incremental linking to produce the resulting object. We also add section
+// with a single byte to state the name of the component the main object file
+// (the one we are bundling into) refers to.
+//
+// To unbundle, we use just copy the contents of the designated section. If the
+// requested bundle refer to the main object file, we just copy it with no
+// changes.
+class ObjectFileHandler : public FileHandler {
+
+  /// \brief The object file we are currently dealing with.
+  ObjectFile 
+
+  /// \brief Return the input file contents.
+  StringRef getInputFileContents() const { return Obj.getData(); }
+
+  /// \brief Return true if the provided section is an offload section and
+  /// return the triple by reference.
+  bool isOffloadSection(SectionRef CurSection, StringRef ) {
+StringRef SectionName;
+CurSection.getName(SectionName);
+
+if (SectionName.empty())
+  return false;
+
+// If it does not start with the reserved suffix, just skip this section.
+if (!SectionName.startswith(OFFLOAD_BUNDLER_MAGIC_STR))
+  return false;
+
+// Return the triple that is right after the reserved prefix.
+OffloadTriple = SectionName.substr(sizeof(OFFLOAD_BUNDLER_MAGIC_STR) - 1);
+return true;
+  }
+
+  /// \brief Total number of inputs.
+  unsigned NumberOfInputs = 0;
+
+  /// \brief Total number of processed inputs, i.e, inputs that were already
+  /// read from the buffers.
+  unsigned NumberOfProcessedInputs = 0;
+
+  /// \brief LLVM context used to to create the auxiliar modules.
+  LLVMContext VMContext;
+
+  /// \brief LLVM module used to create an object with all the bundle
+  /// components.
+  std::unique_ptr AuxModule;
+
+  /// \brief The current triple we are working with.
+  StringRef CurrentTriple;
+
+  /// \brief The name of the main input file.
+  StringRef MainInputFileName;
+
+  /// \brief Iterator of the current and next section.
+  section_iterator CurrentSection;
+  section_iterator NextSection;
+
+public:
+  void ReadHeader(MemoryBuffer ) {}
+  StringRef ReadBundleStart(MemoryBuffer ) {
+
+while (NextSection != Obj.section_end()) {
+  CurrentSection = NextSection;
+  ++NextSection;
+
+  StringRef OffloadTriple;
+  // Check if the current section name starts with the reserved prefix. If
+  // so, return the triple.
+  if (isOffloadSection(*CurrentSection, OffloadTriple))
+return OffloadTriple;
+}
+return StringRef();
+  }
+  void ReadBundleEnd(MemoryBuffer ) {}
+  void ReadBundle(raw_fd_ostream , MemoryBuffer ) {
+// If the current 

Re: [PATCH] D21666: [Tooling] Add optional argument to getFullyQualifiedName to prepend "::".

2016-06-29 Thread Reid Kleckner via cfe-commits
rnk accepted this revision.
rnk added a comment.

lgtm


http://reviews.llvm.org/D21666



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


  1   2   >