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

[Piotr Padlewski via cfe-commits]

Prazek updated this revision to Diff 64640.
Prazek marked an inline comment as done.

Repository:
  rL LLVM

https://reviews.llvm.org/D22208

Files:
  clang-tidy/modernize/UseEmplaceCheck.cpp
  clang-tidy/modernize/UseEmplaceCheck.h
  clang-tidy/utils/Matchers.h
  docs/clang-tidy/checks/modernize-use-emplace.rst
  test/clang-tidy/modernize-use-emplace.cpp

Index: test/clang-tidy/modernize-use-emplace.cpp
===
--- test/clang-tidy/modernize-use-emplace.cpp
+++ test/clang-tidy/modernize-use-emplace.cpp
@@ -1,4 +1,7 @@
-// RUN: %check_clang_tidy %s modernize-use-emplace %t
+// RUN: %check_clang_tidy %s modernize-use-emplace %t -- \
+// RUN:   -config="{CheckOptions: \
+// RUN: [{key: modernize-use-emplace.ContainersWithPushBack, \
+// RUN:   value: '::std::vector; ::std::list; ::std::deque; llvm::LikeASmallVector'}]}" -- -std=c++11
 
 namespace std {
 template 
@@ -9,6 +12,7 @@
 
   template 
   void emplace_back(Args &&... args){};
+  ~vector();
 };
 template 
 class list {
@@ -18,6 +22,7 @@
 
   template 
   void emplace_back(Args &&... args){};
+  ~list();
 };
 
 template 
@@ -28,6 +33,7 @@
 
   template 
   void emplace_back(Args &&... args){};
+  ~deque();
 };
 
 template 
@@ -54,10 +60,24 @@
 template 
 class unique_ptr {
 public:
-  unique_ptr(T *) {}
+  explicit unique_ptr(T *) {}
+  ~unique_ptr();
 };
 } // namespace std
 
+namespace llvm {
+template 
+class LikeASmallVector {
+public:
+  void push_back(const T &) {}
+  void push_back(T &&) {}
+
+  template 
+  void emplace_back(Args &&... args){};
+};
+
+} // llvm
+
 void testInts() {
   std::vector v;
   v.push_back(42);
@@ -117,6 +137,23 @@
   v.push_back(s);
 }
 
+template 
+void dependOnElem() {
+  std::vector v;
+  v.push_back(ElemType(42));
+}
+
+template 
+void dependOnContainer() {
+  ContainerType v;
+  v.push_back(Something(42));
+}
+
+void callDependent() {
+  dependOnElem();
+  dependOnContainer();
+}
+
 void test2() {
   std::vector v;
   v.push_back(Zoz(Something(21, 37)));
@@ -130,12 +167,20 @@
   v.push_back(getZoz(Something(1, 2)));
 }
 
+struct GetPair {
+  std::pair getPair();
+};
 void testPair() {
   std::vector> v;
   v.push_back(std::pair(1, 2));
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
   // CHECK-FIXES: v.emplace_back(1, 2);
 
+  GetPair g;
+  v.push_back(g.getPair());
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(g.getPair());
+
   std::vector> v2;
   v2.push_back(std::pair(Something(42, 42), Zoz(Something(21, 37;
   // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use emplace_back
@@ -206,14 +251,14 @@
   v.push_back(new int(5));
 
   std::vector v2;
-  v2.push_back(new int(42));
+  v2.push_back(std::unique_ptr(new int(42)));
   // This call can't be replaced with emplace_back.
   // If emplacement will fail (not enough memory to add to vector)
   // we will have leak of int because unique_ptr won't be constructed
   // (and destructed) as in push_back case.
 
   auto *ptr = new int;
-  v2.push_back(ptr);
+  v2.push_back(std::unique_ptr(ptr));
   // Same here
 }
 
@@ -240,6 +285,11 @@
   d.push_back(Something(42));
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
   // CHECK-FIXES: d.emplace_back(42);
+
+  llvm::LikeASmallVector ls;
+  ls.push_back(Something(42));
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use emplace_back
+  // CHECK-FIXES: ls.emplace_back(42);
 }
 
 class IntWrapper {
@@ -336,3 +386,29 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
   // CHECK-FIXES: v.emplace_back(42, var);
 }
+
+class PrivateCtor {
+  PrivateCtor(int z);
+
+public:
+  void doStuff() {
+std::vector v;
+// This should not change it because emplace back doesn't have permission.
+// Check currently doesn't support friend delcarations because pretty much
+// nobody would want to be friend with std::vector :(.
+v.push_back(PrivateCtor(42));
+  }
+};
+
+struct WithDtor {
+  WithDtor(int) {}
+  ~WithDtor();
+};
+
+void testWithDtor() {
+  std::vector v;
+
+  v.push_back(WithDtor(42));
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(42);
+}
Index: docs/clang-tidy/checks/modernize-use-emplace.rst
===
--- docs/clang-tidy/checks/modernize-use-emplace.rst
+++ docs/clang-tidy/checks/modernize-use-emplace.rst
@@ -3,29 +3,43 @@
 modernize-use-emplace
 =
 
-This check looks for cases when inserting new element into an STL
-container (``std::vector``, ``std::deque``, ``std::list``) or ``llvm::SmallVector``
-but the element is constructed temporarily.
+The check flags insertions to an STL-style container done by calling the
+``push_back`` method with an explicitly-constructed temporary of the 

[libcxx] r276091 - Add missed test in r276090.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Jul 20 00:22:35 2016
New Revision: 276091

URL: http://llvm.org/viewvc/llvm-project?rev=276091=rev
Log:
Add missed test in r276090.

Added:

libcxx/trunk/test/std/utilities/function.objects/func.wrap/func.wrap.func/derive_from.pass.cpp

Added: 
libcxx/trunk/test/std/utilities/function.objects/func.wrap/func.wrap.func/derive_from.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/function.objects/func.wrap/func.wrap.func/derive_from.pass.cpp?rev=276091=auto
==
--- 
libcxx/trunk/test/std/utilities/function.objects/func.wrap/func.wrap.func/derive_from.pass.cpp
 (added)
+++ 
libcxx/trunk/test/std/utilities/function.objects/func.wrap/func.wrap.func/derive_from.pass.cpp
 Wed Jul 20 00:22:35 2016
@@ -0,0 +1,23 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// 
+
+// See https://llvm.org/bugs/show_bug.cgi?id=20002
+
+#include 
+#include 
+
+using Fn = std::function;
+struct S : Fn { using function::function; };
+
+int main() {
+S f1( Fn{} );
+S f2(std::allocator_arg, std::allocator{}, Fn{});
+}
\ No newline at end of file


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

[libcxx] r276090 - Move std::function constructor SFINAE into template parameter list. Fixes PR20002.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Jul 20 00:21:00 2016
New Revision: 276090

URL: http://llvm.org/viewvc/llvm-project?rev=276090=rev
Log:
Move std::function constructor SFINAE into template parameter list. Fixes 
PR20002.

Although inheriting constructors have already been fixed in Clang 3.9 I still
choose to fix std::function so users can derive from it with older compilers.

Modified:
libcxx/trunk/include/functional

Modified: libcxx/trunk/include/functional
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/functional?rev=276090=276089=276090=diff
==
--- libcxx/trunk/include/functional (original)
+++ libcxx/trunk/include/functional Wed Jul 20 00:21:00 2016
@@ -1595,12 +1595,10 @@ public:
 function(nullptr_t) _NOEXCEPT : __f_(0) {}
 function(const function&);
 function(function&&) _NOEXCEPT;
-template
-  function(_Fp, typename enable_if
- <
-__callable<_Fp>::value &&
-!is_same<_Fp, function>::value
-  >::type* = 0);
+template::value && !is_same<_Fp, function>::value
+>::type>
+function(_Fp);
 
 template
   _LIBCPP_INLINE_VISIBILITY
@@ -1612,9 +1610,8 @@ public:
   function(allocator_arg_t, const _Alloc&, const function&);
 template
   function(allocator_arg_t, const _Alloc&, function&&);
-template
-  function(allocator_arg_t, const _Alloc& __a, _Fp __f,
-   typename enable_if<__callable<_Fp>::value>::type* = 0);
+template::value>::type>
+  function(allocator_arg_t, const _Alloc& __a, _Fp __f);
 
 function& operator=(const function&);
 function& operator=(function&&) _NOEXCEPT;
@@ -1728,13 +1725,8 @@ function<_Rp(_ArgTypes...)>::function(al
 }
 
 template
-template 
-function<_Rp(_ArgTypes...)>::function(_Fp __f,
- typename enable_if
- <
-__callable<_Fp>::value &&
-!is_same<_Fp, function>::value
- >::type*)
+template 
+function<_Rp(_ArgTypes...)>::function(_Fp __f)
 : __f_(0)
 {
 if (__function::__not_null(__f))
@@ -1757,9 +1749,8 @@ function<_Rp(_ArgTypes...)>::function(_F
 }
 
 template
-template 
-function<_Rp(_ArgTypes...)>::function(allocator_arg_t, const _Alloc& __a0, _Fp 
__f,
- typename 
enable_if<__callable<_Fp>::value>::type*)
+template 
+function<_Rp(_ArgTypes...)>::function(allocator_arg_t, const _Alloc& __a0, _Fp 
__f)
 : __f_(0)
 {
 typedef allocator_traits<_Alloc> __alloc_traits;


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

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

[Piotr Padlewski via cfe-commits]

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

Aaron, Alex thanks for the review. After running it on llvm I also have found 
the private constructor bug so I also fixed it.



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

aaron.ballman wrote:
> Looking at `VariadicFunction`, it appears that it already works if you pass 
> an `ArrayRef` to the `operator()()` overload. See 
> ASTMatchersInternal.h:81. So I still think the matcher can be used directly, 
> just with changing the type of the object passed to the functor.
That's cool! I convert the vector to SmallVector, because ArrayRef doesn't have 
ctor taking iterators.

I will later also change the code in FasterStringFind that also do this kind of 
things.


Repository:
  rL LLVM

https://reviews.llvm.org/D22208



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

[libcxx] r276084 - Reimplement is_constructible fallback implementation. Fixes PR21574.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Jul 20 00:01:24 2016
New Revision: 276084

URL: http://llvm.org/viewvc/llvm-project?rev=276084=rev
Log:
Reimplement is_constructible fallback implementation. Fixes PR21574.

The previous implementation relied highly on specializations to handle
special cases. This new implementation lets the compiler do the work when 
possible.

Modified:
libcxx/trunk/include/type_traits

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

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

Modified: libcxx/trunk/include/type_traits
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/type_traits?rev=276084=276083=276084=diff
==
--- libcxx/trunk/include/type_traits (original)
+++ libcxx/trunk/include/type_traits Wed Jul 20 00:01:24 2016
@@ -2913,119 +2913,75 @@ struct _LIBCPP_TYPE_VIS_ONLY is_construc
 
 //  main is_constructible test
 
-template 
-typename __select_2nd()...))), 
true_type>::type
-__is_constructible_test(_Tp&&, _Args&& ...);
-
-template 
-false_type
-__is_constructible_test(__any, _Args&& ...);
-
-template 
-struct __libcpp_is_constructible // false, _Tp is not a scalar
-: public common_type
- <
- decltype(__is_constructible_test(declval<_Tp>(), 
declval<_Args>()...))
- >::type
-{};
-
-//  function types are not constructible
-
-template 
-struct __libcpp_is_constructible
-: public false_type
-{};
 
-//  handle scalars and reference types
+struct __is_constructible_helper
+{
+template 
+static true_type __test_ref(_Tp);
+template 
+static false_type __test_ref(...);
+
+template ()...))>
+static true_type __test_nary(int);
+template 
+static false_type __test_nary(...);
+
+template ()))>
+static is_destructible<_Tp> __test_unary(int);
+template 
+static false_type __test_unary(...);
+};
 
-//  Scalars are default constructible, references are not
+template ::value>
+struct __is_default_constructible
+: decltype(__is_constructible_helper::__test_nary<_Tp>(0))
+{};
 
 template 
-struct __libcpp_is_constructible
-: public is_scalar<_Tp>
-{};
-
-//  Scalars and references are constructible from one arg if that arg is
-//  implicitly convertible to the scalar or reference.
+struct __is_default_constructible<_Tp, true> : false_type {};
 
 template 
-struct __is_constructible_ref
-{
-true_type static __lxx(_Tp);
-false_type static __lxx(...);
-};
+struct __is_default_constructible<_Tp[], false> : false_type {};
 
-template 
-struct __libcpp_is_constructible
-: public common_type
- <
- decltype(__is_constructible_ref<_Tp>::__lxx(declval<_A0>()))
- >::type
-{};
-
-//  Scalars and references are not constructible from multiple args.
-
-template 
-struct __libcpp_is_constructible
-: public false_type
-{};
-
-//  Treat scalars and reference types separately
-
-template 
-struct __is_constructible_void_check
-: public __libcpp_is_constructible::value || 
is_reference<_Tp>::value,
-_Tp, _Args...>
-{};
-
-//  If any of T or Args is void, is_constructible should be false
+template 
+struct __is_default_constructible<_Tp[_Nx], false>
+: __is_default_constructible::type>  {};
 
 template 
-struct __is_constructible_void_check
-: public false_type
-{};
+struct __libcpp_is_constructible
+{
+  static_assert(sizeof...(_Args) > 1, "Wrong specialization");
+  typedef decltype(__is_constructible_helper::__test_nary<_Tp, _Args...>(0))
+  type;
+};
 
-template  struct __contains_void;
+template 
+struct __libcpp_is_constructible<_Tp> : __is_default_constructible<_Tp> {};
 
-template <> struct __contains_void<> : false_type {};
+template 
+struct __libcpp_is_constructible<_Tp, _A0>
+: public decltype(__is_constructible_helper::__test_unary<_Tp, _A0>(0))
+{};
 
-template 
-struct __contains_void<_A0, _Args...>
-{
-static const bool value = is_void<_A0>::value ||
-  __contains_void<_Args...>::value;
-};
+template 
+struct __libcpp_is_constructible<_Tp&, _A0>
+: public decltype(__is_constructible_helper::
+__test_ref<_Tp&>(_VSTD::declval<_A0>()))
+{};
+
+template 
+struct __libcpp_is_constructible<_Tp&&, _A0>
+: public decltype(__is_constructible_helper::
+__test_ref<_Tp&&>(_VSTD::declval<_A0>()))
+{};
 
 //  is_constructible entry point
 
 template 
 struct _LIBCPP_TYPE_VIS_ONLY is_constructible
-: public __is_constructible_void_check<__contains_void<_Tp, 

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

[Ed Maste via cfe-commits]

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

I've committed the alignment change to the copy of llvm libunwind in the 
FreeBSD base system now.


https://reviews.llvm.org/D22543



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

[libcxx] r276078 - Add tests for reference binding assertions in std::tuple.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Jul 19 21:57:39 2016
New Revision: 276078

URL: http://llvm.org/viewvc/llvm-project?rev=276078=rev
Log:
Add tests for reference binding assertions in std::tuple.

Libc++ provides static assertions to detect reference binding issues inside
tuple. This patch adds tests for those diagnostics.

It should be noted that these static assertions technically violate the
standard since it allows these illegal bindings to occur.

Also see https://llvm.org/bugs/show_bug.cgi?id=20855

Added:
libcxx/trunk/test/libcxx/utilities/tuple/tuple.tuple/

libcxx/trunk/test/libcxx/utilities/tuple/tuple.tuple/diagnose_reference_binding.fail.cpp

libcxx/trunk/test/libcxx/utilities/tuple/tuple.tuple/diagnose_reference_binding.pass.cpp
Modified:
libcxx/trunk/include/tuple

Modified: libcxx/trunk/include/tuple
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/tuple?rev=276078=276077=276078=diff
==
--- libcxx/trunk/include/tuple (original)
+++ libcxx/trunk/include/tuple Tue Jul 19 21:57:39 2016
@@ -192,6 +192,20 @@ class __tuple_leaf
 {
 _Hp value;
 
+template 
+static constexpr bool __can_bind_reference() {
+using _RawTp = typename remove_reference<_Tp>::type;
+using _RawHp = typename remove_reference<_Hp>::type;
+using _CheckLValueArg = integral_constant::value
+||  is_same<_RawTp, reference_wrapper<_RawHp>>::value
+||  is_same<_RawTp, reference_wrapper::type>>::value
+>;
+return  !is_reference<_Hp>::value
+|| (is_lvalue_reference<_Hp>::value && _CheckLValueArg::value)
+|| (is_rvalue_reference<_Hp>::value && 
!is_lvalue_reference<_Tp>::value);
+}
+
 __tuple_leaf& operator=(const __tuple_leaf&);
 public:
 _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR __tuple_leaf()
@@ -231,59 +245,29 @@ public:
 _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
 explicit __tuple_leaf(_Tp&& __t) 
_NOEXCEPT_((is_nothrow_constructible<_Hp, _Tp>::value))
 : value(_VSTD::forward<_Tp>(__t))
-{static_assert(!is_reference<_Hp>::value ||
-   (is_lvalue_reference<_Hp>::value &&
-(is_lvalue_reference<_Tp>::value ||
- is_same::type,
- reference_wrapper<
-typename remove_reference<_Hp>::type
- >
->::value)) ||
-(is_rvalue_reference<_Hp>::value &&
- !is_lvalue_reference<_Tp>::value),
+{static_assert(__can_bind_reference<_Tp>(),
"Attempted to construct a reference element in a tuple with an 
rvalue");}
 
 template 
 _LIBCPP_INLINE_VISIBILITY
 explicit __tuple_leaf(integral_constant, const _Alloc&, _Tp&& 
__t)
 : value(_VSTD::forward<_Tp>(__t))
-{static_assert(!is_lvalue_reference<_Hp>::value ||
-   (is_lvalue_reference<_Hp>::value &&
-(is_lvalue_reference<_Tp>::value ||
- is_same::type,
- reference_wrapper<
-typename remove_reference<_Hp>::type
- >
->::value)),
+{static_assert(__can_bind_reference<_Tp>(),
"Attempted to construct a reference element in a tuple with an 
rvalue");}
 
 template 
 _LIBCPP_INLINE_VISIBILITY
 explicit __tuple_leaf(integral_constant, const _Alloc& __a, 
_Tp&& __t)
 : value(allocator_arg_t(), __a, _VSTD::forward<_Tp>(__t))
-{static_assert(!is_lvalue_reference<_Hp>::value ||
-   (is_lvalue_reference<_Hp>::value &&
-(is_lvalue_reference<_Tp>::value ||
- is_same::type,
- reference_wrapper<
-typename remove_reference<_Hp>::type
- >
->::value)),
-   "Attempted to construct a reference element in a tuple with an 
rvalue");}
+{static_assert(!is_reference<_Hp>::value,
+"Attempted to uses-allocator construct a reference element in a 
tuple");}
 
 template 
 _LIBCPP_INLINE_VISIBILITY
 explicit __tuple_leaf(integral_constant, const _Alloc& __a, 
_Tp&& __t)
 : value(_VSTD::forward<_Tp>(__t), __a)
-{static_assert(!is_lvalue_reference<_Hp>::value ||
-   (is_lvalue_reference<_Hp>::value &&
-(is_lvalue_reference<_Tp>::value ||
- is_same::type,
- reference_wrapper<
-typename 

Re: [PATCH] D22555: [Clang] Fix RHEL 6 build and other Include What You Use warnings

[Mehdi Amini via cfe-commits]

I'm not necessarily disagreeing, I'm saying that if I understand correctly, 
there are two unrelated changes (one is a build fix, and the other is a "good 
practice" kind of change).

> On Jul 19, 2016, at 6:43 PM, Eugene Zelenko  wrote:
> 
> Eugene.Zelenko added a comment.
> 
> But all of them are used in code. I don't see a reason to save lines :-)
> 
> 
> Repository:
>  rL LLVM
> 
> https://reviews.llvm.org/D22555
> 
> 
> 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D22557: [libcxx] Diagnose invalid memory order arguments in . Fixes PR21179.

[Eric Fiselier via cfe-commits]

EricWF created this revision.
EricWF added reviewers: mclow.lists, rsmith.
EricWF added subscribers: cfe-commits, rsmith.

This patch uses the __attribute__((enable_if)) hack suggested by @rsmith to 
diagnose invalid arguments when possible.

In order to diagnose an invalid argument `m` to `f(m)` we provide an additional 
overload of `f` that is only enabled when `m` is invalid. When that function is 
enabled it uses __attribute__((unavailable)) to produce a diagnostic message.

https://reviews.llvm.org/D22557

Files:
  include/atomic
  test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp

Index: test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp
===
--- /dev/null
+++ test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp
@@ -0,0 +1,81 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// The attributes used to diagnose incorrect memory order inputs is clang
+// specific.
+// UNSUPPORTED: gcc
+
+// 
+
+// Test that invalid memory order arguments are diagnosed where possible.
+
+#include 
+
+int main() {
+std::atomic x(42);
+volatile std::atomic& vx = x;
+int val1 = 1;
+int val2 = 2;
+// load operations
+{
+x.load(std::memory_order_release); // expected-error {{operation is invalid}}
+x.load(std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+vx.load(std::memory_order_release); // expected-error {{operation is invalid}}
+vx.load(std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+}
+{
+std::atomic_load_explicit(, std::memory_order_release); // expected-error {{operation is invalid}}
+std::atomic_load_explicit(, std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+std::atomic_load_explicit(, std::memory_order_release); // expected-error {{operation is invalid}}
+std::atomic_load_explicit(, std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+}
+// store operations
+{
+x.store(42, std::memory_order_consume); // expected-error {{operation is invalid}}
+x.store(42, std::memory_order_acquire); // expected-error {{operation is invalid}}
+x.store(42, std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+vx.store(42, std::memory_order_consume); // expected-error {{operation is invalid}}
+vx.store(42, std::memory_order_acquire); // expected-error {{operation is invalid}}
+vx.store(42, std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+}
+{
+std::atomic_store_explicit(, 42, std::memory_order_consume); // expected-error {{operation is invalid}}
+std::atomic_store_explicit(, 42, std::memory_order_acquire); // expected-error {{operation is invalid}}
+std::atomic_store_explicit(, 42, std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+std::atomic_store_explicit(, 42, std::memory_order_consume); // expected-error {{operation is invalid}}
+std::atomic_store_explicit(, 42, std::memory_order_acquire); // expected-error {{operation is invalid}}
+std::atomic_store_explicit(, 42, std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+}
+// compare exchange weak
+{
+x.compare_exchange_weak(val1, val2, std::memory_order_seq_cst, std::memory_order_release); // expected-error {{operation is invalid}}
+x.compare_exchange_weak(val1, val2, std::memory_order_seq_cst, std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+vx.compare_exchange_weak(val1, val2, std::memory_order_seq_cst, std::memory_order_release); // expected-error {{operation is invalid}}
+vx.compare_exchange_weak(val1, val2, std::memory_order_seq_cst, std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+}
+{
+std::atomic_compare_exchange_weak_explicit(, , val2, std::memory_order_seq_cst, std::memory_order_release); // expected-error {{operation is invalid}}
+std::atomic_compare_exchange_weak_explicit(, , val2, std::memory_order_seq_cst, std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+std::atomic_compare_exchange_weak_explicit(, , val2, std::memory_order_seq_cst, std::memory_order_release); // expected-error {{operation is invalid}}
+std::atomic_compare_exchange_weak_explicit(, , val2, std::memory_order_seq_cst, std::memory_order_acq_rel); // expected-error {{operation is invalid}}
+}
+// compare exchange strong
+{
+x.compare_exchange_strong(val1, val2, 

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

[Justin Lebar via cfe-commits]

jlebar added a comment.

FYI after talking to Chandler, I'm going to write up a separate proposal for 
the one-repository thing and send it to the list tomorrow.  The suggestion was 
that this phabricator thread isn't the right place to have this discussion.


https://reviews.llvm.org/D22463



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

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

[Akira Hatanaka via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL276076: [Sema] Compute the nullability of a conditional 
expression based on the (authored by ahatanak).

Changed prior to commit:
  https://reviews.llvm.org/D22392?vs=64557=64628#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22392

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

Index: cfe/trunk/lib/Sema/SemaExpr.cpp
===
--- cfe/trunk/lib/Sema/SemaExpr.cpp
+++ cfe/trunk/lib/Sema/SemaExpr.cpp
@@ -7002,6 +7002,55 @@
 SourceRange(CondRHS->getLocStart(), RHSExpr->getLocEnd()));
 }
 
+/// Compute the nullability of a conditional expression.
+static QualType computeConditionalNullability(QualType ResTy, bool IsBin,
+  QualType LHSTy, QualType RHSTy,
+  ASTContext ) {
+  if (!ResTy->isPointerType())
+return ResTy;
+
+  auto GetNullability = [](QualType Ty) {
+Optional Kind = Ty->getNullability(Ctx);
+if (Kind)
+  return *Kind;
+return NullabilityKind::Unspecified;
+  };
+
+  auto LHSKind = GetNullability(LHSTy), RHSKind = GetNullability(RHSTy);
+  NullabilityKind MergedKind;
+
+  // Compute nullability of a binary conditional expression.
+  if (IsBin) {
+if (LHSKind == NullabilityKind::NonNull)
+  MergedKind = NullabilityKind::NonNull;
+else
+  MergedKind = RHSKind;
+  // Compute nullability of a normal conditional expression.
+  } else {
+if (LHSKind == NullabilityKind::Nullable ||
+RHSKind == NullabilityKind::Nullable)
+  MergedKind = NullabilityKind::Nullable;
+else if (LHSKind == NullabilityKind::NonNull)
+  MergedKind = RHSKind;
+else if (RHSKind == NullabilityKind::NonNull)
+  MergedKind = LHSKind;
+else
+  MergedKind = NullabilityKind::Unspecified;
+  }
+
+  // Return if ResTy already has the correct nullability.
+  if (GetNullability(ResTy) == MergedKind)
+return ResTy;
+
+  // Strip all nullability from ResTy.
+  while (ResTy->getNullability(Ctx))
+ResTy = ResTy.getSingleStepDesugaredType(Ctx);
+
+  // Create a new AttributedType with the new nullability kind.
+  auto NewAttr = AttributedType::getNullabilityAttrKind(MergedKind);
+  return Ctx.getAttributedType(NewAttr, ResTy, ResTy);
+}
+
 /// ActOnConditionalOp - Parse a ?: operation.  Note that 'LHS' may be null
 /// in the case of a the GNU conditional expr extension.
 ExprResult Sema::ActOnConditionalOp(SourceLocation QuestionLoc,
@@ -7069,6 +7118,7 @@
 LHSExpr = CondExpr = opaqueValue;
   }
 
+  QualType LHSTy = LHSExpr->getType(), RHSTy = RHSExpr->getType();
   ExprValueKind VK = VK_RValue;
   ExprObjectKind OK = OK_Ordinary;
   ExprResult Cond = CondExpr, LHS = LHSExpr, RHS = RHSExpr;
@@ -7083,6 +7133,9 @@
 
   CheckBoolLikeConversion(Cond.get(), QuestionLoc);
 
+  result = computeConditionalNullability(result, commonExpr, LHSTy, RHSTy,
+ Context);
+
   if (!commonExpr)
 return new (Context)
 ConditionalOperator(Cond.get(), QuestionLoc, LHS.get(), ColonLoc,
Index: cfe/trunk/test/SemaCXX/nullability.cpp
===
--- cfe/trunk/test/SemaCXX/nullability.cpp
+++ cfe/trunk/test/SemaCXX/nullability.cpp
@@ -97,3 +97,23 @@
 
   TakeNonnull(ReturnNullable()); //expected-warning{{implicit conversion from nullable pointer 'void * _Nullable' to non-nullable pointer type 'void * _Nonnull}}
 }
+
+void ConditionalExpr(bool c) {
+  struct Base {};
+  struct Derived : Base {};
+
+  Base * _Nonnull p;
+  Base * _Nonnull nonnullB;
+  Base * _Nullable nullableB;
+  Derived * _Nonnull nonnullD;
+  Derived * _Nullable nullableD;
+
+  p = c ? nonnullB : nonnullD;
+  p = c ? nonnullB : nullableD; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableB : nonnullD; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableB : nullableD; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nonnullD : nonnullB;
+  p = c ? nonnullD : nullableB; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableD : nonnullB; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+  p = c ? nullableD : nullableB; // expected-warning{{implicit conversion from nullable pointer 'Base * _Nullable' to non-nullable pointer type 'Base * _Nonnull}}
+}
Index: cfe/trunk/test/Sema/nullability.c

r276076 - [Sema] Compute the nullability of a conditional expression based on the

[Akira Hatanaka via cfe-commits]

Author: ahatanak
Date: Tue Jul 19 20:48:11 2016
New Revision: 276076

URL: http://llvm.org/viewvc/llvm-project?rev=276076=rev
Log:
[Sema] Compute the nullability of a conditional expression based on the
nullabilities of its operands.

This patch defines a function to compute the nullability of conditional
expressions, which enables Sema to precisely detect implicit conversions
of nullable conditional expressions to nonnull pointers.

rdar://problem/25166556

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

Modified:
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/test/Sema/nullability.c
cfe/trunk/test/SemaCXX/nullability.cpp

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=276076=276075=276076=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Tue Jul 19 20:48:11 2016
@@ -7002,6 +7002,55 @@ static void DiagnoseConditionalPrecedenc
 SourceRange(CondRHS->getLocStart(), RHSExpr->getLocEnd()));
 }
 
+/// Compute the nullability of a conditional expression.
+static QualType computeConditionalNullability(QualType ResTy, bool IsBin,
+  QualType LHSTy, QualType RHSTy,
+  ASTContext ) {
+  if (!ResTy->isPointerType())
+return ResTy;
+
+  auto GetNullability = [](QualType Ty) {
+Optional Kind = Ty->getNullability(Ctx);
+if (Kind)
+  return *Kind;
+return NullabilityKind::Unspecified;
+  };
+
+  auto LHSKind = GetNullability(LHSTy), RHSKind = GetNullability(RHSTy);
+  NullabilityKind MergedKind;
+
+  // Compute nullability of a binary conditional expression.
+  if (IsBin) {
+if (LHSKind == NullabilityKind::NonNull)
+  MergedKind = NullabilityKind::NonNull;
+else
+  MergedKind = RHSKind;
+  // Compute nullability of a normal conditional expression.
+  } else {
+if (LHSKind == NullabilityKind::Nullable ||
+RHSKind == NullabilityKind::Nullable)
+  MergedKind = NullabilityKind::Nullable;
+else if (LHSKind == NullabilityKind::NonNull)
+  MergedKind = RHSKind;
+else if (RHSKind == NullabilityKind::NonNull)
+  MergedKind = LHSKind;
+else
+  MergedKind = NullabilityKind::Unspecified;
+  }
+
+  // Return if ResTy already has the correct nullability.
+  if (GetNullability(ResTy) == MergedKind)
+return ResTy;
+
+  // Strip all nullability from ResTy.
+  while (ResTy->getNullability(Ctx))
+ResTy = ResTy.getSingleStepDesugaredType(Ctx);
+
+  // Create a new AttributedType with the new nullability kind.
+  auto NewAttr = AttributedType::getNullabilityAttrKind(MergedKind);
+  return Ctx.getAttributedType(NewAttr, ResTy, ResTy);
+}
+
 /// ActOnConditionalOp - Parse a ?: operation.  Note that 'LHS' may be null
 /// in the case of a the GNU conditional expr extension.
 ExprResult Sema::ActOnConditionalOp(SourceLocation QuestionLoc,
@@ -7069,6 +7118,7 @@ ExprResult Sema::ActOnConditionalOp(Sour
 LHSExpr = CondExpr = opaqueValue;
   }
 
+  QualType LHSTy = LHSExpr->getType(), RHSTy = RHSExpr->getType();
   ExprValueKind VK = VK_RValue;
   ExprObjectKind OK = OK_Ordinary;
   ExprResult Cond = CondExpr, LHS = LHSExpr, RHS = RHSExpr;
@@ -7083,6 +7133,9 @@ ExprResult Sema::ActOnConditionalOp(Sour
 
   CheckBoolLikeConversion(Cond.get(), QuestionLoc);
 
+  result = computeConditionalNullability(result, commonExpr, LHSTy, RHSTy,
+ Context);
+
   if (!commonExpr)
 return new (Context)
 ConditionalOperator(Cond.get(), QuestionLoc, LHS.get(), ColonLoc,

Modified: cfe/trunk/test/Sema/nullability.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/nullability.c?rev=276076=276075=276076=diff
==
--- cfe/trunk/test/Sema/nullability.c (original)
+++ cfe/trunk/test/Sema/nullability.c Tue Jul 19 20:48:11 2016
@@ -128,3 +128,70 @@ void nullable_to_nonnull(_Nullable int *
 
   accepts_nonnull_1(ptr); // expected-warning{{implicit conversion from 
nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * 
_Nonnull'}}
 }
+
+// Check nullability of conditional expressions.
+void conditional_expr(int c) {
+  int * _Nonnull p;
+  int * _Nonnull nonnullP;
+  int * _Nullable nullableP;
+  int * _Null_unspecified unspecifiedP;
+  int *noneP;
+
+  p = c ? nonnullP : nonnullP;
+  p = c ? nonnullP : nullableP; // expected-warning{{implicit conversion from 
nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * 
_Nonnull'}}
+  p = c ? nonnullP : unspecifiedP;
+  p = c ? nonnullP : noneP;
+  p = c ? nullableP : nonnullP; // expected-warning{{implicit conversion from 
nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * 
_Nonnull'}}
+  p = c ? nullableP : nullableP; // expected-warning{{implicit conversion from 

Re: [PATCH] D22555: [Clang] Fix RHEL 6 build and other Include What You Use warnings

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added a comment.

But all of them are used in code. I don't see a reason to save lines :-)


Repository:
  rL LLVM

https://reviews.llvm.org/D22555



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

Re: [PATCH] D22555: [Clang] Fix RHEL 6 build and other Include What You Use warnings

[Mehdi AMINI via cfe-commits]

mehdi_amini added inline comments.


Comment at: lib/Basic/FileManager.cpp:35
@@ -29,2 +34,3 @@
 #include 
+#include 
 

That's a lot of includes though. Ok for the climits, but the other should be a 
separate patch I think.


Repository:
  rL LLVM

https://reviews.llvm.org/D22555



___
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

[Sean Silva via cfe-commits]

On Tue, Jul 19, 2016 at 5:01 PM, Xinliang David Li 
wrote:

> The new behavior works really well. There is one follow up change I would
> like to discuss.
>
> The EQ form of the option -fprofile-generate= takes a directory name as
> the argument instead of the filename. Currently the compiler will create a
> default 'default.profraw' name for it, but this means, online merging won't
> be available unless environment variable is also used, which is not
> convenient.  I propose we change the default behavior to enable profile
> online merging (i.e., use default_%m.profraw as the default name) for the
> following reasons:
>
> 1) There is almost no downside enabling profiling merging by default --
> new capability is enabled with no lost functionality
> 2) WIth profile merging enabled for instrumented programs with
> instrumented shared libs, each lib will dump its own profile data in the
> same dir, but users of -fprofile-generate= option usually do not care about
> what/how many raw profile names are in the directory (note that GCC's
> behavior is one profile per object module), they just pack up the while
> directory. llvm-profdata also support merging (for indexed profile) with
> input-list-file option.
> 3) GCC's has online merging support, so having online merging by default
> with this option matches up better the claim that it is a GCC compatible
> option.
>
> What do you think?
>
> thanks,
>
> David
>

This SGTM.

May only slight concern is making sure that tests which use globbing (which
`REQUIRES: shell`) to deal with %m expansions are kept separate if possible
-- otherwise windows (or windows-hosted, e.g. PS4) test coverage suffers.
Most of our tests use `env LLVM_PROFILE_FILE=` anyway so this hopefully
doesn't affect too many tests.

-- Sean Silva


>
>
>
> On Sat, Jul 9, 2016 at 4:39 PM, Sean Silva  wrote:
>
>> silvas added a comment.
>>
>> In http://reviews.llvm.org/D21823#479418, @davidxl wrote:
>>
>> > I should have brought it up earlier, but I forgot.I think a better
>> (and simpler) proposal is to make -fprofile-generate and -fprofile-use turn
>> on IR based PGO.
>> >
>> > -fprofile-generate and -fprofile-use options were introduced by Diego
>> (cc'ed) recently for GCC option compatibility. At that time, IR based PGO
>> was not yet ready, so they were made aliases to FE instrumentation options
>> -fprofile-instr-generate and -fprofile-instr-use.Now I think it is time
>> to make it right.   The documentation only says that these two options are
>> gcc compatible options to control profile generation and use, but does not
>> specify the underlying implementation. It is also likely that Google is the
>> only user of this option. If a user using this option really want FE
>> instrumentation, there is always -fprofile-instr-generate to use.  It also
>> more likely that IR instrumentation is what user wants when using GCC
>> compatible options (as they behave more similarly).
>>
>>
>> This SGTM.
>>
>> It may cause some user confusion since there is no obvious distinction
>> between "profile generate" and "profile instr generate" from a user
>> perspective. But we can avoid that with improved documentation.
>>
>> My main concern is that the existing documentation already says that
>> -fprofile-generate behaves identically to -fprofile-instr-generate
>> http://clang.llvm.org/docs/UsersManual.html#cmdoption-fprofile-generate
>> However, I think it is reasonable to change this behavior (and of course
>> the documentation), as users of this option are likely using it for
>> compatibility with GCC and so they likely don't care about the specifics of
>> clang FEPGO.
>> We probably want to at least leave a small note in the documentation
>> regarding this change of behavior.
>>
>>
>> Repository:
>>   rL LLVM
>>
>> http://reviews.llvm.org/D21823
>>
>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r276074 - Revert r276069: MSVC bots not happy

[Hubert Tong via cfe-commits]

Author: hubert.reinterpretcast
Date: Tue Jul 19 20:05:31 2016
New Revision: 276074

URL: http://llvm.org/viewvc/llvm-project?rev=276074=rev
Log:
Revert r276069: MSVC bots not happy

Modified:
cfe/trunk/include/clang/AST/DeclTemplate.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/ASTImporter.cpp
cfe/trunk/lib/AST/DeclTemplate.cpp
cfe/trunk/lib/Sema/SemaLambda.cpp
cfe/trunk/lib/Sema/SemaTemplate.cpp
cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp

Modified: cfe/trunk/include/clang/AST/DeclTemplate.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclTemplate.h?rev=276074=276073=276074=diff
==
--- cfe/trunk/include/clang/AST/DeclTemplate.h (original)
+++ cfe/trunk/include/clang/AST/DeclTemplate.h Tue Jul 19 20:05:31 2016
@@ -46,8 +46,7 @@ typedef llvm::PointerUnion3 {
+: private llvm::TrailingObjects {
 
   /// The location of the 'template' keyword.
   SourceLocation TemplateLoc;
@@ -57,36 +56,26 @@ class TemplateParameterList final
 
   /// The number of template parameters in this template
   /// parameter list.
-  unsigned NumParams : 30;
+  unsigned NumParams : 31;
 
   /// Whether this template parameter list contains an unexpanded parameter
   /// pack.
   unsigned ContainsUnexpandedParameterPack : 1;
 
-  /// Whether this template parameter list has an associated requires-clause
-  unsigned HasRequiresClause : 1;
-
 protected:
   size_t numTrailingObjects(OverloadToken) const {
 return NumParams;
   }
 
-  size_t numTrailingObjects(OverloadToken) const {
-return HasRequiresClause;
-  }
-
   TemplateParameterList(SourceLocation TemplateLoc, SourceLocation LAngleLoc,
-ArrayRef Params, SourceLocation RAngleLoc,
-Expr *RequiresClause);
+ArrayRef Params, SourceLocation 
RAngleLoc);
 
 public:
-  // FIXME: remove default argument for RequiresClause
   static TemplateParameterList *Create(const ASTContext ,
SourceLocation TemplateLoc,
SourceLocation LAngleLoc,
ArrayRef Params,
-   SourceLocation RAngleLoc,
-   Expr *RequiresClause = nullptr);
+   SourceLocation RAngleLoc);
 
   /// \brief Iterates through the template parameters in this list.
   typedef NamedDecl** iterator;
@@ -138,16 +127,6 @@ public:
 return ContainsUnexpandedParameterPack;
   }
 
-  /// \brief The constraint-expression of the associated requires-clause.
-  Expr *getRequiresClause() {
-return HasRequiresClause ? *getTrailingObjects() : nullptr;
-  }
-
-  /// \brief The constraint-expression of the associated requires-clause.
-  const Expr *getRequiresClause() const {
-return HasRequiresClause ? *getTrailingObjects() : nullptr;
-  }
-
   SourceLocation getTemplateLoc() const { return TemplateLoc; }
   SourceLocation getLAngleLoc() const { return LAngleLoc; }
   SourceLocation getRAngleLoc() const { return RAngleLoc; }
@@ -157,33 +136,36 @@ public:
   }
 
   friend TrailingObjects;
-
-  template 
-  friend class FixedSizeTemplateParameterListStorage;
+  template  friend class FixedSizeTemplateParameterListStorage;
 };
 
-/// \brief Stores a list of template parameters and the associated
-/// requires-clause (if any) for a TemplateDecl and its derived classes.
-/// Suitable for creating on the stack.
-template 
-class FixedSizeTemplateParameterListStorage
-: public TemplateParameterList::FixedSizeStorageOwner {
-  typename TemplateParameterList::FixedSizeStorage<
-  NamedDecl *, Expr *>::with_counts<
-  N, HasRequiresClause ? 1u : 0u
-  >::type storage;
+/// \brief Stores a list of template parameters for a TemplateDecl and its
+/// derived classes. Suitable for creating on the stack.
+template  class FixedSizeTemplateParameterListStorage {
+  // This is kinda ugly: TemplateParameterList usually gets allocated
+  // in a block of memory with NamedDecls appended to it. Here, to get
+  // it stack allocated, we include the params as a separate
+  // variable. After allocation, the TemplateParameterList object
+  // treats them as part of itself.
+  TemplateParameterList List;
+  NamedDecl *Params[N];
 
 public:
   FixedSizeTemplateParameterListStorage(SourceLocation TemplateLoc,
 SourceLocation LAngleLoc,
 ArrayRef Params,
-SourceLocation RAngleLoc,
-Expr *RequiresClause)
-  : FixedSizeStorageOwner(
-(assert(N == Params.size()),

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

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


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

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


https://reviews.llvm.org/D21962



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

r276073 - Fix r276069: add default argument for new parameter

[Hubert Tong via cfe-commits]

Author: hubert.reinterpretcast
Date: Tue Jul 19 19:57:56 2016
New Revision: 276073

URL: http://llvm.org/viewvc/llvm-project?rev=276073=rev
Log:
Fix r276069: add default argument for new parameter

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

Modified: cfe/trunk/include/clang/AST/DeclTemplate.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclTemplate.h?rev=276073=276072=276073=diff
==
--- cfe/trunk/include/clang/AST/DeclTemplate.h (original)
+++ cfe/trunk/include/clang/AST/DeclTemplate.h Tue Jul 19 19:57:56 2016
@@ -80,12 +80,13 @@ protected:
 Expr *RequiresClause);
 
 public:
+  // FIXME: remove default argument for RequiresClause
   static TemplateParameterList *Create(const ASTContext ,
SourceLocation TemplateLoc,
SourceLocation LAngleLoc,
ArrayRef Params,
SourceLocation RAngleLoc,
-   Expr *RequiresClause);
+   Expr *RequiresClause = nullptr);
 
   /// \brief Iterates through the template parameters in this list.
   typedef NamedDecl** iterator;


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

r276071 - Fix r276069: use LLVM_CONSTEXPR

[Hubert Tong via cfe-commits]

Author: hubert.reinterpretcast
Date: Tue Jul 19 19:41:30 2016
New Revision: 276071

URL: http://llvm.org/viewvc/llvm-project?rev=276071=rev
Log:
Fix r276069: use LLVM_CONSTEXPR

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

Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=276071=276070=276071=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Tue Jul 19 19:41:30 2016
@@ -653,7 +653,7 @@ ASTContext::getCanonicalTemplateTemplate
 
   assert(!TTP->getRequiresClause() &&
  "Unexpected requires-clause on template template-parameter");
-  constexpr Expr *const CanonRequiresClause = nullptr;
+  LLVM_CONSTEXPR Expr *const CanonRequiresClause = nullptr;
 
   TemplateTemplateParmDecl *CanonTTP
 = TemplateTemplateParmDecl::Create(*this, getTranslationUnitDecl(), 


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

[PATCH] D22555: [Clang] Fix RHEL 6 build and other Include What You Use warnings

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko created this revision.
Eugene.Zelenko added reviewers: hans, mehdi_amini.
Eugene.Zelenko added a subscriber: cfe-commits.
Eugene.Zelenko set the repository for this revision to rL LLVM.

Build was broken because of missing climits where PATH_MAX is defined.

Repository:
  rL LLVM

https://reviews.llvm.org/D22555

Files:
  lib/Basic/FileManager.cpp

Index: lib/Basic/FileManager.cpp
===
--- lib/Basic/FileManager.cpp
+++ lib/Basic/FileManager.cpp
@@ -26,7 +26,13 @@
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/raw_ostream.h"
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
 
 using namespace clang;
 
@@ -494,7 +500,6 @@
   UniqueRealFiles.erase(Entry->getUniqueID());
 }
 
-
 void FileManager::GetUniqueIDMapping(
SmallVectorImpl ) const {
   UIDToFiles.clear();


Index: lib/Basic/FileManager.cpp
===
--- lib/Basic/FileManager.cpp
+++ lib/Basic/FileManager.cpp
@@ -26,7 +26,13 @@
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/raw_ostream.h"
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
 
 using namespace clang;
 
@@ -494,7 +500,6 @@
   UniqueRealFiles.erase(Entry->getUniqueID());
 }
 
-
 void FileManager::GetUniqueIDMapping(
SmallVectorImpl ) const {
   UIDToFiles.clear();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Justin Lebar via cfe-commits]

jlebar added a subscriber: jlebar.
jlebar added a comment.

I'm sure you all have thought about this more than I have, and I apologize if 
this has been brought up before because I haven't been following the thread 
closely.  But I am not convinced by this document that using subrepositories 
beats using a single git repo.

I see two reasons here for using subrepos as opposed to one big repository.

1. Subrepos mirror our current scheme.
2. Subrepos let people check out only the bits of llvm that they want.

I don't find either of these particularly compelling, compared to the 
advantages of one-big-repo (discussed below).  Taking them in turn:

1. Although subrepos would mirror our current scheme, it's going to be 
different *enough* that existing tools are going to have to change either way.  
In particular, the svn view of the master repository is not going to be useful 
for anything.  I tried `svn checkout 
https://github.com/chapuni/llvm-project-submodule`, and the result was 
essentially an empty repository.

2. It's true that subrepos let people check out only the bits that they want.  
But disk space and bandwidth are very cheap today, and LLVM is not as large as 
one might think.  My copy of https://github.com/llvm-project/llvm-project, 
which includes *everything* is 2.5G, whereas my copy of just llvm is 626M.

  Given that a release build of llvm and clang is ~3.5G, a 2.5G source checkout 
doesn't seem at all unreasonable to me.

  If it's really problematic, you can do a shallow checkout, which would take 
the contains-everything repo from 2.5G to 1.3G.  Moreover if it's *really* a 
problem, you can mirror the subdir of llvm that you care about.  Maybe the LLVM 
project could maintain said mirrors for some of the small subrepos that are 
often used independently.

So what's the advantage of using one big repository?  The simple answer is: 
Have you ever *tried* using git submodules?  :)

Submodules make everything more complicated.  Here's an example that I hope 
proves the point.  Suppose you want to commit your current work and switch to a 
new clean branch off head.  You make some changes there, then come back to your 
current work.  And let's assume that all of your changes are to clang only.

  # Commit current work, switch to a clean branch off head, then switch back.
  
  # One big repo: 
  $ git commit  # on old-branch
  $ git fetch
  $ git checkout -b new-branch origin/master
  # Hack hack hack...
  $ git commit
  $ git checkout old-branch
  
  # Submodules, attempt 1:
  $ cd clang
  $ git commit  # on old-branch
  $ git fetch
  $ git checkout -b new-branch origin/master
  # Also have to update llvm...
  $ cd ../llvm
  $ git fetch
  $ git checkout origin/master
  $ cd ../clang
  # Hack hack hack
  $ git commit
  
  # Now we're ready to switch back to old-branch, but...it's not going to work.
  # When we committed our old branch, we didn't save the state of our llvm
  # checkout.  So in particular we don't know which revision to roll it back to.
  
  # Let's try again.
  # Submodules, attempt 2:
  $ cd clang
  $ git commit  # on old-branch
  $ cd ..
  $ git checkout -b old-branch # in master repo
  $ git commit
  
  # Now we have two branches called "old-branch": One in the master repo, and 
one
  # in the clang submodules.  Now let's fetch head.
  
  $ git fetch  # in master repo
  $ git checkout -b new-branch origin/master
  $ git submodule update
  $ cd clang
  $ git checkout -b new-branch
  # Hack hack hack
  $ git commit  # in submodule
  $ cd ..
  $ git commit  # in master repo
  
  # Now we're ready to switch back.
  
  $ git checkout old-branch  # in master repo
  $ git submodule update

For those keeping track at home, this is 5 git commands with the big repo, and 
15 commands (11 git commands) in the submodules world.

Above we assumed that all of our changes were only to clang.  If we're making 
changes to both llvm and clang (say), the one-big-repo workflow remains 
identical, but the submodules workflow becomes even more complicated.

I'm sure people who are better at git than I can golf the above commands, but 
I'll suggest that I'm an above-average git user, so this is probably a 
lower-than-average estimate for the number of git commands (particularly `git 
help` :).  git is hard enough as-is; using submodules like this is asking a lot.

Similarly, I'm sure much of this can be scripted, but...seriously?  :)

Sorry for the wall of text.  tl;dr: One big repo doesn't actually cost that 
much, and that cost is dwarfed by the cost to humans of using submodules as 
proposed.


https://reviews.llvm.org/D22463



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

r276069 - Concepts: Create space for requires-clause in TemplateParameterList; NFC

[Hubert Tong via cfe-commits]

Author: hubert.reinterpretcast
Date: Tue Jul 19 19:30:15 2016
New Revision: 276069

URL: http://llvm.org/viewvc/llvm-project?rev=276069=rev
Log:
Concepts: Create space for requires-clause in TemplateParameterList; NFC

Summary:
Space for storing the //constraint-expression// of the
//requires-clause// associated with a `TemplateParameterList` is
arranged by taking a bit out of the `NumParams` field for the purpose
of determining whether there is a //requires-clause// or not, and by
adding to the trailing objects tied to the `TemplateParameterList`. An
accessor is provided.

An appropriate argument is supplied to `TemplateParameterList::Create`
at the various call sites.

Serialization changes will addressed as the Concepts implementation
becomes more solid.

Drive-by fix:
This change also replaces the custom
`FixedSizeTemplateParameterListStorage` implementation with one that
follows the interface provided by `llvm::TrailingObjects`.

Reviewers: aaron.ballman, faisalv, rsmith

Subscribers: cfe-commits, nwilson

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

Modified:
cfe/trunk/include/clang/AST/DeclTemplate.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/ASTImporter.cpp
cfe/trunk/lib/AST/DeclTemplate.cpp
cfe/trunk/lib/Sema/SemaLambda.cpp
cfe/trunk/lib/Sema/SemaTemplate.cpp
cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp

Modified: cfe/trunk/include/clang/AST/DeclTemplate.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclTemplate.h?rev=276069=276068=276069=diff
==
--- cfe/trunk/include/clang/AST/DeclTemplate.h (original)
+++ cfe/trunk/include/clang/AST/DeclTemplate.h Tue Jul 19 19:30:15 2016
@@ -46,7 +46,8 @@ typedef llvm::PointerUnion3 {
+: private llvm::TrailingObjects {
 
   /// The location of the 'template' keyword.
   SourceLocation TemplateLoc;
@@ -56,26 +57,35 @@ class TemplateParameterList final
 
   /// The number of template parameters in this template
   /// parameter list.
-  unsigned NumParams : 31;
+  unsigned NumParams : 30;
 
   /// Whether this template parameter list contains an unexpanded parameter
   /// pack.
   unsigned ContainsUnexpandedParameterPack : 1;
 
+  /// Whether this template parameter list has an associated requires-clause
+  unsigned HasRequiresClause : 1;
+
 protected:
   size_t numTrailingObjects(OverloadToken) const {
 return NumParams;
   }
 
+  size_t numTrailingObjects(OverloadToken) const {
+return HasRequiresClause;
+  }
+
   TemplateParameterList(SourceLocation TemplateLoc, SourceLocation LAngleLoc,
-ArrayRef Params, SourceLocation 
RAngleLoc);
+ArrayRef Params, SourceLocation RAngleLoc,
+Expr *RequiresClause);
 
 public:
   static TemplateParameterList *Create(const ASTContext ,
SourceLocation TemplateLoc,
SourceLocation LAngleLoc,
ArrayRef Params,
-   SourceLocation RAngleLoc);
+   SourceLocation RAngleLoc,
+   Expr *RequiresClause);
 
   /// \brief Iterates through the template parameters in this list.
   typedef NamedDecl** iterator;
@@ -127,6 +137,16 @@ public:
 return ContainsUnexpandedParameterPack;
   }
 
+  /// \brief The constraint-expression of the associated requires-clause.
+  Expr *getRequiresClause() {
+return HasRequiresClause ? *getTrailingObjects() : nullptr;
+  }
+
+  /// \brief The constraint-expression of the associated requires-clause.
+  const Expr *getRequiresClause() const {
+return HasRequiresClause ? *getTrailingObjects() : nullptr;
+  }
+
   SourceLocation getTemplateLoc() const { return TemplateLoc; }
   SourceLocation getLAngleLoc() const { return LAngleLoc; }
   SourceLocation getRAngleLoc() const { return RAngleLoc; }
@@ -136,36 +156,33 @@ public:
   }
 
   friend TrailingObjects;
-  template  friend class FixedSizeTemplateParameterListStorage;
+
+  template 
+  friend class FixedSizeTemplateParameterListStorage;
 };
 
-/// \brief Stores a list of template parameters for a TemplateDecl and its
-/// derived classes. Suitable for creating on the stack.
-template  class FixedSizeTemplateParameterListStorage {
-  // This is kinda ugly: TemplateParameterList usually gets allocated
-  // in a block of memory with NamedDecls appended to it. Here, to get
-  // it stack allocated, we include the params as a separate
-  // variable. After allocation, the TemplateParameterList object
-  // treats them as part of itself.
-  TemplateParameterList List;
-  

Re: [PATCH] D4447: [libcxx] Fixes libc++ bug #19921 - Remove additional overloads for std::complex

[Eric Fiselier via cfe-commits]

EricWF abandoned this revision.
EricWF added a comment.

Fixed in r276067.


https://reviews.llvm.org/D4447



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

[libcxx] r276067 - Add SFINAE on additional overloads of std::complex functions. Fixes PR19921.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Jul 19 19:14:10 2016
New Revision: 276067

URL: http://llvm.org/viewvc/llvm-project?rev=276067=rev
Log:
Add SFINAE on additional overloads of std::complex functions. Fixes PR19921.

The functions arg, conj, imag, norm, proj, and real have additional overloads
for arguments of integral or floating point types. However these overloads 
should
not allow conversions to the integral/floating point types, only exact matches.

This patch constrains these functions so they no longer allow conversions.

Added:

libcxx/trunk/test/std/numerics/complex.number/cmplx.over/UDT_is_rejected.fail.cpp
Modified:
libcxx/trunk/include/complex
libcxx/trunk/test/libcxx/test/format.py

Modified: libcxx/trunk/include/complex
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/complex?rev=276067=276066=276067=diff
==
--- libcxx/trunk/include/complex (original)
+++ libcxx/trunk/include/complex Tue Jul 19 19:14:10 2016
@@ -795,6 +795,27 @@ operator!=(const _Tp& __x, const complex
 
 // 26.3.7 values:
 
+template ::value,
+ bool = is_floating_point<_Tp>::value
+ >
+struct __libcpp_complex_overload_traits {};
+
+// Integral Types
+template 
+struct __libcpp_complex_overload_traits<_Tp, true, false>
+{
+typedef double _ValueType;
+typedef complex _ComplexType;
+};
+
+// Floating point types
+template 
+struct __libcpp_complex_overload_traits<_Tp, false, true>
+{
+typedef _Tp _ValueType;
+typedef complex<_Tp> _ComplexType;
+};
+
 // real
 
 template
@@ -805,35 +826,10 @@ real(const complex<_Tp>& __c)
 return __c.real();
 }
 
+template 
 inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
-long double
-real(long double __re)
-{
-return __re;
-}
-
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
-double
-real(double __re)
-{
-return __re;
-}
-
-template
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
-typename enable_if
-<
-is_integral<_Tp>::value,
-double
->::type
-real(_Tp  __re)
-{
-return __re;
-}
-
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
-float
-real(float  __re)
+typename __libcpp_complex_overload_traits<_Tp>::_ValueType
+real(_Tp __re)
 {
 return __re;
 }
@@ -848,35 +844,10 @@ imag(const complex<_Tp>& __c)
 return __c.imag();
 }
 
+template 
 inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
-long double
-imag(long double __re)
-{
-return 0;
-}
-
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
-double
-imag(double __re)
-{
-return 0;
-}
-
-template
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
-typename enable_if
-<
-is_integral<_Tp>::value,
-double
->::type
-imag(_Tp  __re)
-{
-return 0;
-}
-
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
-float
-imag(float  __re)
+typename __libcpp_complex_overload_traits<_Tp>::_ValueType
+imag(_Tp __re)
 {
 return 0;
 }
@@ -901,25 +872,22 @@ arg(const complex<_Tp>& __c)
 return atan2(__c.imag(), __c.real());
 }
 
+template 
 inline _LIBCPP_INLINE_VISIBILITY
-long double
-arg(long double __re)
+typename enable_if<
+is_same<_Tp, long double>::value,
+long double
+>::type
+arg(_Tp __re)
 {
 return atan2l(0.L, __re);
 }
 
-inline _LIBCPP_INLINE_VISIBILITY
-double
-arg(double __re)
-{
-return atan2(0., __re);
-}
-
 template
 inline _LIBCPP_INLINE_VISIBILITY
 typename enable_if
 <
-is_integral<_Tp>::value,
+is_integral<_Tp>::value || is_same<_Tp, double>::value,
 double
 >::type
 arg(_Tp __re)
@@ -927,9 +895,13 @@ arg(_Tp __re)
 return atan2(0., __re);
 }
 
+template 
 inline _LIBCPP_INLINE_VISIBILITY
-float
-arg(float __re)
+typename enable_if<
+is_same<_Tp, float>::value,
+float
+>::type
+arg(_Tp __re)
 {
 return atan2f(0.F, __re);
 }
@@ -948,37 +920,13 @@ norm(const complex<_Tp>& __c)
 return __c.real() * __c.real() + __c.imag() * __c.imag();
 }
 
+template 
 inline _LIBCPP_INLINE_VISIBILITY
-long double
-norm(long double __re)
-{
-return __re * __re;
-}
-
-inline _LIBCPP_INLINE_VISIBILITY
-double
-norm(double __re)
-{
-return __re * __re;
-}
-
-template
-inline _LIBCPP_INLINE_VISIBILITY
-typename enable_if
-<
-is_integral<_Tp>::value,
-double
->::type
+typename __libcpp_complex_overload_traits<_Tp>::_ValueType
 norm(_Tp __re)
 {
-return (double)__re * __re;
-}
-
-inline _LIBCPP_INLINE_VISIBILITY
-float
-norm(float __re)
-{
-return __re * __re;
+typedef typename __libcpp_complex_overload_traits<_Tp>::_ValueType 
_ValueType;
+return static_cast<_ValueType>(__re) * __re;
 }
 
 // conj
@@ -991,38 +939,16 @@ conj(const complex<_Tp>& __c)
 return complex<_Tp>(__c.real(), -__c.imag());
 }
 
+template 
 inline _LIBCPP_INLINE_VISIBILITY
-complex
-conj(long double __re)
-{
-return complex(__re);
-}
-
-inline _LIBCPP_INLINE_VISIBILITY
-complex
-conj(double 

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

[Loki Astari via cfe-commits]

LokiAstari added a comment.

Each new style option must ::

- be used in a project of significant size (have dozens of contributors)
- have a publicly accessible style guide
- have a person willing to contribute and maintain patches

Example:

  https://github.com/openframeworks/openFrameworks
  Style Guide: 
https://github.com/openframeworks/openFrameworks/wiki/oF-code-style#indentation
  Contributors: 220
  Willing to maintain: Me (Loki Astari. I have more patches I want to 
contribute so I am not doing a drive bye :-)


https://reviews.llvm.org/D22505



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

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

[Xinliang David Li via cfe-commits]

On Tue, Jul 19, 2016 at 5:06 PM, Vedant Kumar  wrote:

>
> > On Jul 19, 2016, at 5:01 PM, Xinliang David Li 
> wrote:
> >
> > The new behavior works really well. There is one follow up change I
> would like to discuss.
> >
> > The EQ form of the option -fprofile-generate= takes a directory name as
> the argument instead of the filename. Currently the compiler will create a
> default 'default.profraw' name for it, but this means, online merging won't
> be available unless environment variable is also used, which is not
> convenient.  I propose we change the default behavior to enable profile
> online merging (i.e., use default_%m.profraw as the default name) for the
> following reasons:
> >
> > 1) There is almost no downside enabling profiling merging by default --
> new capability is enabled with no lost functionality
>
> To be clear, this is a behavior change, but IMO the new behavior would be
> better.
>
Instead of creating programs that clobber over existing profiles by default
> they would merge into a set of profiles.
>
>
I consider this a bug fix -- as it makes a broken behavior into a working
one ;)

The only real behavior change is the default file name and number of
produced profile files may change -- but it is more likely the users of
-fprofile-generate=<> option expect to see the new behavior vs the old.

David



>
> > 2) WIth profile merging enabled for instrumented programs with
> instrumented shared libs, each lib will dump its own profile data in the
> same dir, but users of -fprofile-generate= option usually do not care about
> what/how many raw profile names are in the directory (note that GCC's
> behavior is one profile per object module), they just pack up the while
> directory. llvm-profdata also support merging (for indexed profile) with
> input-list-file option.
> > 3) GCC's has online merging support, so having online merging by default
> with this option matches up better the claim that it is a GCC compatible
> option.
> >
> > What do you think?
>
> + 1
>
> thanks,
> vedant
>
> >
> > thanks,
> >
> > David
> >
> >
> >
> > On Sat, Jul 9, 2016 at 4:39 PM, Sean Silva 
> wrote:
> > silvas added a comment.
> >
> > In http://reviews.llvm.org/D21823#479418, @davidxl wrote:
> >
> > > I should have brought it up earlier, but I forgot.I think a better
> (and simpler) proposal is to make -fprofile-generate and -fprofile-use turn
> on IR based PGO.
> > >
> > > -fprofile-generate and -fprofile-use options were introduced by Diego
> (cc'ed) recently for GCC option compatibility. At that time, IR based PGO
> was not yet ready, so they were made aliases to FE instrumentation options
> -fprofile-instr-generate and -fprofile-instr-use.Now I think it is time
> to make it right.   The documentation only says that these two options are
> gcc compatible options to control profile generation and use, but does not
> specify the underlying implementation. It is also likely that Google is the
> only user of this option. If a user using this option really want FE
> instrumentation, there is always -fprofile-instr-generate to use.  It also
> more likely that IR instrumentation is what user wants when using GCC
> compatible options (as they behave more similarly).
> >
> >
> > This SGTM.
> >
> > It may cause some user confusion since there is no obvious distinction
> between "profile generate" and "profile instr generate" from a user
> perspective. But we can avoid that with improved documentation.
> >
> > My main concern is that the existing documentation already says that
> -fprofile-generate behaves identically to -fprofile-instr-generate
> http://clang.llvm.org/docs/UsersManual.html#cmdoption-fprofile-generate
> > However, I think it is reasonable to change this behavior (and of course
> the documentation), as users of this option are likely using it for
> compatibility with GCC and so they likely don't care about the specifics of
> clang FEPGO.
> > We probably want to at least leave a small note in the documentation
> regarding this change of behavior.
> >
> >
> > Repository:
> >   rL LLVM
> >
> > http://reviews.llvm.org/D21823
> >
> >
> >
> >
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Vedant Kumar via cfe-commits]

> On Jul 19, 2016, at 5:01 PM, Xinliang David Li  wrote:
> 
> The new behavior works really well. There is one follow up change I would 
> like to discuss.  
> 
> The EQ form of the option -fprofile-generate= takes a directory name as the 
> argument instead of the filename. Currently the compiler will create a 
> default 'default.profraw' name for it, but this means, online merging won't 
> be available unless environment variable is also used, which is not 
> convenient.  I propose we change the default behavior to enable profile 
> online merging (i.e., use default_%m.profraw as the default name) for the 
> following reasons:
> 
> 1) There is almost no downside enabling profiling merging by default -- new 
> capability is enabled with no lost functionality

To be clear, this is a behavior change, but IMO the new behavior would be
better.

Instead of creating programs that clobber over existing profiles by default
they would merge into a set of profiles.


> 2) WIth profile merging enabled for instrumented programs with instrumented 
> shared libs, each lib will dump its own profile data in the same dir, but 
> users of -fprofile-generate= option usually do not care about what/how many 
> raw profile names are in the directory (note that GCC's behavior is one 
> profile per object module), they just pack up the while directory. 
> llvm-profdata also support merging (for indexed profile) with input-list-file 
> option.  
> 3) GCC's has online merging support, so having online merging by default with 
> this option matches up better the claim that it is a GCC compatible option.
> 
> What do you think?

+ 1

thanks,
vedant

> 
> thanks,
> 
> David
> 
> 
> 
> On Sat, Jul 9, 2016 at 4:39 PM, Sean Silva  wrote:
> silvas added a comment.
> 
> In http://reviews.llvm.org/D21823#479418, @davidxl wrote:
> 
> > I should have brought it up earlier, but I forgot.I think a better (and 
> > simpler) proposal is to make -fprofile-generate and -fprofile-use turn on 
> > IR based PGO.
> >
> > -fprofile-generate and -fprofile-use options were introduced by Diego 
> > (cc'ed) recently for GCC option compatibility. At that time, IR based PGO 
> > was not yet ready, so they were made aliases to FE instrumentation options 
> > -fprofile-instr-generate and -fprofile-instr-use.Now I think it is time 
> > to make it right.   The documentation only says that these two options are 
> > gcc compatible options to control profile generation and use, but does not 
> > specify the underlying implementation. It is also likely that Google is the 
> > only user of this option. If a user using this option really want FE 
> > instrumentation, there is always -fprofile-instr-generate to use.  It also 
> > more likely that IR instrumentation is what user wants when using GCC 
> > compatible options (as they behave more similarly).
> 
> 
> This SGTM.
> 
> It may cause some user confusion since there is no obvious distinction 
> between "profile generate" and "profile instr generate" from a user 
> perspective. But we can avoid that with improved documentation.
> 
> My main concern is that the existing documentation already says that 
> -fprofile-generate behaves identically to -fprofile-instr-generate 
> http://clang.llvm.org/docs/UsersManual.html#cmdoption-fprofile-generate
> However, I think it is reasonable to change this behavior (and of course the 
> documentation), as users of this option are likely using it for compatibility 
> with GCC and so they likely don't care about the specifics of clang FEPGO.
> We probably want to at least leave a small note in the documentation 
> regarding this change of behavior.
> 
> 
> Repository:
>   rL LLVM
> 
> http://reviews.llvm.org/D21823
> 
> 
> 
> 

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

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

[Xinliang David Li via cfe-commits]

The new behavior works really well. There is one follow up change I would
like to discuss.

The EQ form of the option -fprofile-generate= takes a directory name as the
argument instead of the filename. Currently the compiler will create a
default 'default.profraw' name for it, but this means, online merging won't
be available unless environment variable is also used, which is not
convenient.  I propose we change the default behavior to enable profile
online merging (i.e., use default_%m.profraw as the default name) for the
following reasons:

1) There is almost no downside enabling profiling merging by default -- new
capability is enabled with no lost functionality
2) WIth profile merging enabled for instrumented programs with instrumented
shared libs, each lib will dump its own profile data in the same dir, but
users of -fprofile-generate= option usually do not care about what/how many
raw profile names are in the directory (note that GCC's behavior is one
profile per object module), they just pack up the while directory.
llvm-profdata also support merging (for indexed profile) with
input-list-file option.
3) GCC's has online merging support, so having online merging by default
with this option matches up better the claim that it is a GCC compatible
option.

What do you think?

thanks,

David



On Sat, Jul 9, 2016 at 4:39 PM, Sean Silva  wrote:

> silvas added a comment.
>
> In http://reviews.llvm.org/D21823#479418, @davidxl wrote:
>
> > I should have brought it up earlier, but I forgot.I think a better
> (and simpler) proposal is to make -fprofile-generate and -fprofile-use turn
> on IR based PGO.
> >
> > -fprofile-generate and -fprofile-use options were introduced by Diego
> (cc'ed) recently for GCC option compatibility. At that time, IR based PGO
> was not yet ready, so they were made aliases to FE instrumentation options
> -fprofile-instr-generate and -fprofile-instr-use.Now I think it is time
> to make it right.   The documentation only says that these two options are
> gcc compatible options to control profile generation and use, but does not
> specify the underlying implementation. It is also likely that Google is the
> only user of this option. If a user using this option really want FE
> instrumentation, there is always -fprofile-instr-generate to use.  It also
> more likely that IR instrumentation is what user wants when using GCC
> compatible options (as they behave more similarly).
>
>
> This SGTM.
>
> It may cause some user confusion since there is no obvious distinction
> between "profile generate" and "profile instr generate" from a user
> perspective. But we can avoid that with improved documentation.
>
> My main concern is that the existing documentation already says that
> -fprofile-generate behaves identically to -fprofile-instr-generate
> http://clang.llvm.org/docs/UsersManual.html#cmdoption-fprofile-generate
> However, I think it is reasonable to change this behavior (and of course
> the documentation), as users of this option are likely using it for
> compatibility with GCC and so they likely don't care about the specifics of
> clang FEPGO.
> We probably want to at least leave a small note in the documentation
> regarding this change of behavior.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D21823
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D21303: [clang-tidy] Adds performance-returning-type check.

[Alexander Kornienko via cfe-commits]

alexfh requested changes to this revision.
alexfh added a comment.
This revision now requires changes to proceed.

removing from my dashboard, while the check is waiting for Richard's comments.


https://reviews.llvm.org/D21303



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

Re: [PATCH] D19577: [clang-tidy] Enhance misc-suspicious-string-compare by matching string.compare

[Alexander Kornienko via cfe-commits]

alexfh requested changes to this revision.
alexfh added a comment.
This revision now requires changes to proceed.

In https://reviews.llvm.org/D19577#413888, @etienneb wrote:

> In https://reviews.llvm.org/D19577#413526, @alexfh wrote:
>
> > I'm somewhat reluctant to add LLVM-specific checks to misc-. I would prefer 
> > either to split the LLVM-specific part to a separate check in llvm/ (which 
> > might derive from this check or somehow reuse the logic) or make the check 
> > configurable enough so that these checks can be enabled for LLVM in the 
> > config file.
>
>
> How should we solve adding other code base to checkers.
>  It will be common to have these code base: chromium, llvm, boost, stl.
>
> Should we use the local/global to configure them?


(we might have discussed this offline, but I'm not sure now, so posting it here)

I don't think that checks should know about specifics of different code bases, 
since this doesn't scale well. One of alternative approaches should be used 
instead, depending on the amount and complexity of the project-specific parts:

1. Provide enough configuration options to support known and unknown code bases 
(within certain limits). If needed, register checks with a project-specific 
alias and corresponding option values. Alternatively, specify options in the 
project's .clang-tidy file. Example: google-readability-namespace-comments 
check.
2. Make the check extensible via inheritance. Example: llvm-header-guard check.
3. Pull out some utility functions/matchers/classes/... and make a separate 
check for each code base.

One more thing to consider is that it's usually better to keep the overlap in 
patterns detected by the different variants of the check minimal. E.g. a check 
detecting a certain problematic pattern applied to LLVM containers should not 
complain about the same pattern applied to STL containers to avoid duplicate 
warnings in case both checks are turned on (consider a code base that uses 
LLVM, boost and STL, and needs three variants of some check).


https://reviews.llvm.org/D19577



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

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

[kled...@apple.com via cfe-commits]

kledzik added a comment.

LGTM


https://reviews.llvm.org/D22543



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

[libcxx] r276059 - Add heterogeneous comparator support for __debug_less. Fixes PR17147.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Jul 19 18:27:18 2016
New Revision: 276059

URL: http://llvm.org/viewvc/llvm-project?rev=276059=rev
Log:
Add heterogeneous comparator support for __debug_less. Fixes PR17147.

Added:
libcxx/trunk/test/libcxx/algorithms/debug_less.pass.cpp
Modified:
libcxx/trunk/include/algorithm

Modified: libcxx/trunk/include/algorithm
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/algorithm?rev=276059=276058=276059=diff
==
--- libcxx/trunk/include/algorithm (original)
+++ libcxx/trunk/include/algorithm Tue Jul 19 18:27:18 2016
@@ -749,14 +749,28 @@ struct __debug_less
 {
 _Compare __comp_;
 __debug_less(_Compare& __c) : __comp_(__c) {}
+
 template 
 bool operator()(const _Tp& __x, const _Up& __y)
 {
 bool __r = __comp_(__x, __y);
 if (__r)
-_LIBCPP_ASSERT(!__comp_(__y, __x), "Comparator does not induce a 
strict weak ordering");
+__do_compare_assert(0, __y, __x);
 return __r;
 }
+
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+decltype((void)_VSTD::declval<_Compare&>()(
+_VSTD::declval<_LHS const&>(), _VSTD::declval<_RHS const&>()))
+__do_compare_assert(int, _LHS const& __l, _RHS const& __r) {
+_LIBCPP_ASSERT(!__comp_(__l, __r),
+"Comparator does not induce a strict weak ordering");
+}
+
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+void __do_compare_assert(long, _LHS const&, _RHS const&) {}
 };
 
 #endif  // _LIBCPP_DEBUG

Added: libcxx/trunk/test/libcxx/algorithms/debug_less.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/algorithms/debug_less.pass.cpp?rev=276059=auto
==
--- libcxx/trunk/test/libcxx/algorithms/debug_less.pass.cpp (added)
+++ libcxx/trunk/test/libcxx/algorithms/debug_less.pass.cpp Tue Jul 19 18:27:18 
2016
@@ -0,0 +1,167 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// UNSUPPORTED: libcpp-no-exceptions
+
+// 
+
+// template  struct __debug_less
+
+// __debug_less checks that a comparator actually provides a strict-weak 
ordering.
+
+struct DebugException {};
+
+#define _LIBCPP_DEBUG 0
+#define _LIBCPP_ASSERT(x, m) ((x) ? (void)0 : throw ::DebugException())
+
+#include 
+#include 
+
+template 
+struct MyType {
+int value;
+explicit MyType(int xvalue = 0) : value(xvalue) {}
+};
+
+template 
+bool operator<(MyType const& LHS, MyType const& RHS) {
+return LHS.value < RHS.value;
+}
+
+struct CompareBase {
+static int called;
+static void reset() {
+called = 0;
+}
+};
+
+int CompareBase::called = 0;
+
+template 
+struct GoodComparator : public CompareBase {
+bool operator()(ValueType const& lhs, ValueType const& rhs) const {
+++CompareBase::called;
+return lhs < rhs;
+}
+};
+
+template 
+struct BadComparator : public CompareBase {
+bool operator()(ValueType const&, ValueType const&) const {
+++CompareBase::called;
+return true;
+}
+};
+
+template 
+struct TwoWayHomoComparator : public CompareBase {
+bool operator()(T1 const& lhs, T2 const& rhs) const {
+++CompareBase::called;
+return lhs < rhs;
+}
+
+bool operator()(T2 const& lhs, T1 const& rhs) const {
+++CompareBase::called;
+return lhs < rhs;
+}
+};
+
+template 
+struct OneWayHomoComparator : public CompareBase {
+bool operator()(T1 const& lhs, T2 const& rhs) const {
+++CompareBase::called;
+return lhs < rhs;
+}
+};
+
+using std::__debug_less;
+
+typedef MyType<0> MT0;
+typedef MyType<1> MT1;
+
+void test_passing() {
+int& called = CompareBase::called;
+called = 0;
+MT0 one(1);
+MT0 two(2);
+MT1 three(3);
+MT1 four(4);
+
+{
+typedef GoodComparator C;
+typedef __debug_less D;
+
+C c;
+D d(c);
+
+assert(d(one, two) == true);
+assert(called == 2);
+called = 0;
+
+assert(d(one, one) == false);
+assert(called == 1);
+called = 0;
+
+assert(d(two, one) == false);
+assert(called == 1);
+called = 0;
+}
+{
+typedef TwoWayHomoComparator C;
+typedef __debug_less D;
+C c;
+D d(c);
+
+assert(d(one, three) == true);
+assert(called == 2);
+called = 0;
+
+assert(d(three, one) == false);
+assert(called == 1);
+called = 0;
+}
+{
+typedef OneWayHomoComparator C;
+typedef __debug_less D;
+C 

Re: [PATCH] D22057: Prevent devirtualization of calls to un-instantiated functions.

[Arthur O'Dwyer via cfe-commits]

Quuxplusone added a subscriber: Quuxplusone.


Comment at: test/CodeGen/no-devirt.cpp:16
@@ +15,3 @@
+   if (a > 6) return data[a] ;  // Should not devirtualize
+   if (a > 4) return data.func1(a); // Should devirtualize
+   return data.func2(a);// Should devirtualize

This is a really dumb question from the peanut gallery, but, could you explain 
why these two cases (lines 15 and 16) should differ?  It really seems like both 
calls should be able to be devirtualized, because the compiler statically knows 
what they should call.

I think you mention the difference between lines 15 and 16 here:

> except, for some reason, when it is an operator and used with an operator 
> syntax

but you don't explain *why* the difference is desirable. Shouldn't we just fix 
that difference, then?

Is your first fix (

> The first fix will be in the front end to force the instantiation on virtual 
> calls that are potentially devirtualizable.

) basically "fix the difference between lines 15 and 16", or is it talking 
about something else entirely?


https://reviews.llvm.org/D22057



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

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

[Alexander Kornienko via cfe-commits]

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


Comment at: clang-tidy/modernize/UseEmplaceCheck.cpp:31
@@ +30,3 @@
+
+const std::string DefaultContainersWithPushBack =
+"::std::vector; ::std::list; ::std::deque";

A std::string is not needed here, please change to `const char []`.


Comment at: clang-tidy/modernize/UseEmplaceCheck.h:36
@@ -32,1 +35,3 @@
+private:
+  std::vector ContainersWithPushBack, SmartPointers;
 };

Declarations with multiple variables can be misleading. Please split this into 
two separate declarations.


Comment at: docs/clang-tidy/checks/modernize-use-emplace.rst:7
@@ -6,3 +6,3 @@
 This check looks for cases when inserting new element into an STL
-container (``std::vector``, ``std::deque``, ``std::list``) or 
``llvm::SmallVector``
-but the element is constructed temporarily.
+container, but the element is constructed temporarily.
+

IMO, this sentence fails to convey the most important parts of the information. 
Consider changing to something like this:
> The check flags insertions to an STL-style container done by calling the 
> `push_back` method with an explicitly-constructed temporary of the container 
> element type. In this case, the corresponding `emplace_back` method results 
> in less verbose and potentially more efficient code.

Maybe also explain, why the check only looks for `push_back`, and not `insert`, 
`push_front` and `push`.


Comment at: docs/clang-tidy/checks/modernize-use-emplace.rst:10
@@ +9,3 @@
+By default only ``std::vector``, ``std::deque``, ``std::list`` are considered.
+This list can be modified by passing a `;` separated list of class names using 
the `ContainersWithPushBack`
+option.

s/`;` separated/semicolon-separated/


Repository:
  rL LLVM

https://reviews.llvm.org/D22208



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

Re: r275895 - [Driver] Compute effective target triples once per job (NFCI)

[Vedant Kumar via cfe-commits]

> On Jul 19, 2016, at 3:38 PM, Eric Christopher  wrote:
> 
> 
> 
> On Tue, Jul 19, 2016 at 3:24 PM Vedant Kumar  wrote:
> 
> > On Jul 19, 2016, at 3:02 PM, Eric Christopher  wrote:
> >
> > ... this is pretty crazy. I think that you needed to plumb the effective 
> > triple through everything means that it really needs to be owned somewhere 
> > else and cached.
> >
> > Can you rethink this? In general it doesn't make sense to have everything 
> > need this passed down.
> 
> This came up during review.
> 
> I couldn't find a thread anywhere - and there's not one in the phab revision.

Here's the relevant part of the discussion:

  http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160711/164519.html


> I did try to find a suitable place to cache the effective triple, but did not
> see one. I still don't, and am open to suggestions / willing to revert for 
> more
> review if you'd like.
> 
> Initially I thought it would be possible to cache the triple in the Tool or
> ToolChain, but that seems like it could break use-cases in which jobs are
> constructed from different threads.
> 
> 
> Where do we do that? As far as I know we don't have a case where this applies 
> and I'd consider all of this infrastructure to be internal for any external 
> tools.

We don't do that in-tree.


> Caching the triple in the Compilation seems like it would have have the same
> issue. I'm not sure how much of a problem this is in practice. We could try
> setting the effective triple in the Compilation with a RAII wrapper, e.g:
> 
>   {
> RegisterEffectiveTriple TripleRAII(C, EffectiveTriple);
> T->ConstructJob(...);
>   } // Effective triple cleared from the Compilation.
> 
> Let me know if you have alternate suggestions, and how you'd like to move
> forward.
> 
> 
> Adding Justin here a bit since he's looked at it more recently, but my 
> general case would be to cache in the ToolChain. Anything that has problems 
> with that caching will need to be fixed to deal (either anything depending on 
> ToolChain in clang or external code).

Sure, I can give that a shot (barring any alternate suggestions that may come
up).

To sketch it:

  - Add {get,set}EffectiveTriple to ToolChain
  - Assert that the triple exists in getEffectiveTriple()
  - Use a wrapper to set the triple before Tool::ConstructJob()
  - Remove the extra triple arguments

vedant


> 
> -eric
>  
> thanks,
> vedant
> 
> 
> >
> > Thanks!
> >
> > -eric
> >
> > On Mon, Jul 18, 2016 at 1:04 PM Vedant Kumar via cfe-commits 
> >  wrote:
> > Author: vedantk
> > Date: Mon Jul 18 14:56:38 2016
> > New Revision: 275895
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=275895=rev
> > Log:
> > [Driver] Compute effective target triples once per job (NFCI)
> >
> > Compute an effective target triple exactly once in ConstructJob(), and
> > then simply pass around references to it. This eliminates wasteful
> > re-computation of effective triples (e.g in getARMFloatABI()).
> >
> > Differential Revision: https://reviews.llvm.org/D22290
> >
> > Modified:
> > cfe/trunk/docs/ReleaseNotes.rst
> > cfe/trunk/include/clang/Driver/SanitizerArgs.h
> > cfe/trunk/include/clang/Driver/Tool.h
> > cfe/trunk/include/clang/Driver/ToolChain.h
> > cfe/trunk/lib/Driver/Driver.cpp
> > cfe/trunk/lib/Driver/SanitizerArgs.cpp
> > cfe/trunk/lib/Driver/ToolChain.cpp
> > cfe/trunk/lib/Driver/ToolChains.cpp
> > cfe/trunk/lib/Driver/ToolChains.h
> > cfe/trunk/lib/Driver/Tools.cpp
> > cfe/trunk/lib/Driver/Tools.h
> >
> > Modified: cfe/trunk/docs/ReleaseNotes.rst
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=275895=275894=275895=diff
> > ==
> > --- cfe/trunk/docs/ReleaseNotes.rst (original)
> > +++ cfe/trunk/docs/ReleaseNotes.rst Mon Jul 18 14:56:38 2016
> > @@ -121,7 +121,8 @@ These are major API changes that have ha
> >  Clang. If upgrading an external codebase that uses Clang as a library,
> >  this section should help get you past the largest hurdles of upgrading.
> >
> > --  ...
> > +- Classes which inherit from ``driver::Tool`` must be updated to use 
> > effective
> > +  target triples when constructing jobs.
> >
> >  AST Matchers
> >  
> >
> > Modified: cfe/trunk/include/clang/Driver/SanitizerArgs.h
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/SanitizerArgs.h?rev=275895=275894=275895=diff
> > ==
> > --- cfe/trunk/include/clang/Driver/SanitizerArgs.h (original)
> > +++ cfe/trunk/include/clang/Driver/SanitizerArgs.h Mon Jul 18 14:56:38 2016
> > @@ -16,6 +16,10 @@
> >  #include 
> >  #include 
> >
> > +namespace llvm {
> > +class Triple;
> > +}
> > +
> >  namespace clang {
> >  namespace driver {
> >
> > @@ -66,7 +70,8 @@ class 

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

[Doug Gregor via cfe-commits]

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

LGTM!


https://reviews.llvm.org/D22392



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

Re: r275895 - [Driver] Compute effective target triples once per job (NFCI)

[Vedant Kumar via cfe-commits]

> On Jul 19, 2016, at 3:02 PM, Eric Christopher  wrote:
> 
> ... this is pretty crazy. I think that you needed to plumb the effective 
> triple through everything means that it really needs to be owned somewhere 
> else and cached.
> 
> Can you rethink this? In general it doesn't make sense to have everything 
> need this passed down.

This came up during review.

I did try to find a suitable place to cache the effective triple, but did not
see one. I still don't, and am open to suggestions / willing to revert for more
review if you'd like.

Initially I thought it would be possible to cache the triple in the Tool or
ToolChain, but that seems like it could break use-cases in which jobs are
constructed from different threads.

Caching the triple in the Compilation seems like it would have have the same
issue. I'm not sure how much of a problem this is in practice. We could try
setting the effective triple in the Compilation with a RAII wrapper, e.g:

  {
RegisterEffectiveTriple TripleRAII(C, EffectiveTriple);
T->ConstructJob(...);
  } // Effective triple cleared from the Compilation.

Let me know if you have alternate suggestions, and how you'd like to move
forward.

thanks,
vedant


> 
> Thanks!
> 
> -eric
> 
> On Mon, Jul 18, 2016 at 1:04 PM Vedant Kumar via cfe-commits 
>  wrote:
> Author: vedantk
> Date: Mon Jul 18 14:56:38 2016
> New Revision: 275895
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=275895=rev
> Log:
> [Driver] Compute effective target triples once per job (NFCI)
> 
> Compute an effective target triple exactly once in ConstructJob(), and
> then simply pass around references to it. This eliminates wasteful
> re-computation of effective triples (e.g in getARMFloatABI()).
> 
> Differential Revision: https://reviews.llvm.org/D22290
> 
> Modified:
> cfe/trunk/docs/ReleaseNotes.rst
> cfe/trunk/include/clang/Driver/SanitizerArgs.h
> cfe/trunk/include/clang/Driver/Tool.h
> cfe/trunk/include/clang/Driver/ToolChain.h
> cfe/trunk/lib/Driver/Driver.cpp
> cfe/trunk/lib/Driver/SanitizerArgs.cpp
> cfe/trunk/lib/Driver/ToolChain.cpp
> cfe/trunk/lib/Driver/ToolChains.cpp
> cfe/trunk/lib/Driver/ToolChains.h
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/lib/Driver/Tools.h
> 
> Modified: cfe/trunk/docs/ReleaseNotes.rst
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=275895=275894=275895=diff
> ==
> --- cfe/trunk/docs/ReleaseNotes.rst (original)
> +++ cfe/trunk/docs/ReleaseNotes.rst Mon Jul 18 14:56:38 2016
> @@ -121,7 +121,8 @@ These are major API changes that have ha
>  Clang. If upgrading an external codebase that uses Clang as a library,
>  this section should help get you past the largest hurdles of upgrading.
> 
> --  ...
> +- Classes which inherit from ``driver::Tool`` must be updated to use 
> effective
> +  target triples when constructing jobs.
> 
>  AST Matchers
>  
> 
> Modified: cfe/trunk/include/clang/Driver/SanitizerArgs.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/SanitizerArgs.h?rev=275895=275894=275895=diff
> ==
> --- cfe/trunk/include/clang/Driver/SanitizerArgs.h (original)
> +++ cfe/trunk/include/clang/Driver/SanitizerArgs.h Mon Jul 18 14:56:38 2016
> @@ -16,6 +16,10 @@
>  #include 
>  #include 
> 
> +namespace llvm {
> +class Triple;
> +}
> +
>  namespace clang {
>  namespace driver {
> 
> @@ -66,7 +70,8 @@ class SanitizerArgs {
>bool requiresPIE() const;
>bool needsUnwindTables() const;
>bool linkCXXRuntimes() const { return LinkCXXRuntimes; }
> -  void addArgs(const ToolChain , const llvm::opt::ArgList ,
> +  void addArgs(const ToolChain , const llvm::Triple ,
> +   const llvm::opt::ArgList ,
> llvm::opt::ArgStringList , types::ID InputType) const;
>  };
> 
> 
> Modified: cfe/trunk/include/clang/Driver/Tool.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Tool.h?rev=275895=275894=275895=diff
> ==
> --- cfe/trunk/include/clang/Driver/Tool.h (original)
> +++ cfe/trunk/include/clang/Driver/Tool.h Mon Jul 18 14:56:38 2016
> @@ -14,6 +14,7 @@
>  #include "llvm/Support/Program.h"
> 
>  namespace llvm {
> +class Triple;
>  namespace opt {
>class ArgList;
>  }
> @@ -127,6 +128,7 @@ public:
>virtual void ConstructJob(Compilation , const JobAction ,
>  const InputInfo ,
>  const InputInfoList ,
> +const llvm::Triple ,
>  const llvm::opt::ArgList ,
>  const char *LinkingOutput) const = 0;
>  };
> 
> Modified: cfe/trunk/include/clang/Driver/ToolChain.h
> URL: 
> 

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

[Saleem Abdulrasool via cfe-commits]

compnerd added a comment.

LGTM; we should make sure Nick is okay with it as well (for Darwin).  This 
should also make its way into 3.9 I think.


https://reviews.llvm.org/D22543



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

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

[Eric Fiselier via cfe-commits]

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

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

https://reviews.llvm.org/D22543

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

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


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

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

[Erik Pilkington via cfe-commits]

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

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

Fixes PR28609.

https://reviews.llvm.org/D22542

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

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


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

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

[Matt via cfe-commits]

mmasten updated this revision to Diff 64571.

https://reviews.llvm.org/D19544

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

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

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

[Piotr Padlewski via cfe-commits]

Prazek added a subscriber: Prazek.


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

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

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


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

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


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

typo s/expliciti/explicit


Repository:
  rL LLVM

https://reviews.llvm.org/D22513



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

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

[Richard Smith via cfe-commits]

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

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

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

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


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

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

[Akira Hatanaka via cfe-commits]

ahatanak added a comment.

ping


https://reviews.llvm.org/D21453



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

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

[Akira Hatanaka via cfe-commits]

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

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


https://reviews.llvm.org/D22392

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

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

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

[Bruno Cardoso Lopes via cfe-commits]

bruno closed this revision.
bruno added a comment.

Thanks Manman, Committed r276020


https://reviews.llvm.org/D22183



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

r276020 - [SemaObjC] Improve ObjCDictionaryLiteral and ObjCArryLiteral diagnostics

[Bruno Cardoso Lopes via cfe-commits]

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

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

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

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

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

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

rdar://problem/21046678

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

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

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

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

[Richard Smith via cfe-commits]

rsmith closed this revision.
rsmith added a comment.

Committed as r276016.


Repository:
  rL LLVM

https://reviews.llvm.org/D22528



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

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

[Richard Smith via cfe-commits]

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

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

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

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

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

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

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

[Akira Hatanaka via cfe-commits]

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

Address review comments.

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


https://reviews.llvm.org/D22392

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

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

r276014 - Let FuncAttrs infer the 'returned' argument attribute

[David Majnemer via cfe-commits]

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

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

This reverts commit r275756.

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

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

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

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


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

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

[Eric Fiselier via cfe-commits]

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

LGTM.


Repository:
  rL LLVM

https://reviews.llvm.org/D22528



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

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

[Richard Smith via cfe-commits]

rsmith added inline comments.


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

Err, ignore this :)


Repository:
  rL LLVM

https://reviews.llvm.org/D22528



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

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

[Richard Smith via cfe-commits]

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

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

Repository:
  rL LLVM

https://reviews.llvm.org/D22528

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

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

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

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added a comment.

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


Repository:
  rL LLVM

https://reviews.llvm.org/D22513



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

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

[Yaxun Liu via cfe-commits]

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

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

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

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

Patch by Aaron En Ye Shi.

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

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

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

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

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

[Yaxun Liu via cfe-commits]

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

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

Repository:
  rL LLVM

https://reviews.llvm.org/D22424

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

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

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

[Serge Pavlov via cfe-commits]

Unit test ImportVAArgExpr fails on Windows. The source file:

void declToImport(__builtin_va_list list, ...) {

  (void)__builtin_va_arg(list, int);

}


When compiled on Windows it produces AST:


TranslationUnitDecl 0x638f150 <> 



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

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

  `-CompoundStmt 0x638f880 

`-CStyleCastExpr 0x638f868  'void' 

  `-VAArgExpr 0x638f848  'int'

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

while on Linux 64 the result is:

TranslationUnitDecl 0x9fef870 <> 

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

Maybe it can help.

Thanks,
--Serge

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

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

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

[Yaxun Liu via cfe-commits]

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

LGTM. Thanks!


Repository:
  rL LLVM

https://reviews.llvm.org/D22523



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

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

[Eli Friedman via cfe-commits]

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

LGTM.


Repository:
  rL LLVM

https://reviews.llvm.org/D22105



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

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

[Matt Arsenault via cfe-commits]

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

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

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

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

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


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

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

[Aaron En Ye Shi via cfe-commits]

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

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


Repository:
  rL LLVM

https://reviews.llvm.org/D22523

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

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

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

[Simon Pilgrim via cfe-commits]

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

Removed sitofp conversion changes


Repository:
  rL LLVM

https://reviews.llvm.org/D22105

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

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

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

[Bruno Cardoso Lopes via cfe-commits]

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

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

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

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

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

https://reviews.llvm.org/D22525

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

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

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

[Simon Pilgrim via cfe-commits]

RKSimon added a comment.

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

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


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


Repository:
  rL LLVM

https://reviews.llvm.org/D22105



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

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

[Yaxun Liu via cfe-commits]

yaxunl added inline comments.


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

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


Repository:
  rL LLVM

https://reviews.llvm.org/D22523



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

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

[Yaxun Liu via cfe-commits]

yaxunl added inline comments.


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

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

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


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

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


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

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

function with no prototype cannot use the spir_function calling convention

adding void argument suppresses this error msg.


https://reviews.llvm.org/D21567



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

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

[Yaxun Liu via cfe-commits]

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

Revised by Anastasia's comments.


https://reviews.llvm.org/D21567

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

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

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

[Matt Arsenault via cfe-commits]

arsenm added inline comments.


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

No else after return


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

Positive checks are greatly preferred 


https://reviews.llvm.org/D20168



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

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

[Aaron En Ye Shi via cfe-commits]

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

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

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

Repository:
  rL LLVM

https://reviews.llvm.org/D22523

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

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

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

[Sanjay Patel via cfe-commits]

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

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

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


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

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

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


https://reviews.llvm.org/D19544



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

[libcxx] r276003 - Fix undefined behavior in __tree

[Eric Fiselier via cfe-commits]

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

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

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

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

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

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

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

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

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

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

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

Please let me know what you think.





Reviewers: howard.hinnant, mclow.lists

Subscribers: howard.hinnant, bbannier, cfe-commits

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

Added:

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

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

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

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

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

[Eric Fiselier via cfe-commits]

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

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


https://reviews.llvm.org/D20786

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

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

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

[Alexander Droste via cfe-commits]

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

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

One comment inline.



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

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


https://reviews.llvm.org/D21962



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

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

[Matt via cfe-commits]

mmasten added a comment.

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

Thanks,

Matt


https://reviews.llvm.org/D19544



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

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

[David Majnemer via cfe-commits]

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

LGTM


https://reviews.llvm.org/D18360



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

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

[Eli Friedman via cfe-commits]

eli.friedman added a comment.

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

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


Repository:
  rL LLVM

https://reviews.llvm.org/D22105



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

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

[Ed Maste via cfe-commits]

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

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

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

Modified:
libunwind/trunk/src/DwarfParser.hpp

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


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

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

[Simon Pilgrim via cfe-commits]

RKSimon added a comment.

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

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


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


Repository:
  rL LLVM

https://reviews.llvm.org/D22105



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

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

[Andrew Paprocki via cfe-commits]

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

Increased context and removed accidental inclusion of Solaris change.


https://reviews.llvm.org/D18360

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

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

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

[Etienne Bergeron via cfe-commits]

etienneb added a comment.

drive-by, some comments.
Thanks for the check



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

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


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

nit: remove empty line


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

nit: static


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

nit: remove empty line


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

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


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

nit: line too long


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

A common pattern is:

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

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


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

nit: no empty line


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

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


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

nit: remove the space after (s)


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

To be consistent with your comments, add newline here.


Repository:
  rL LLVM

https://reviews.llvm.org/D22507



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

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

[Ed Maste via cfe-commits]

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

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

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

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

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

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

[Eli Friedman via cfe-commits]

eli.friedman added a comment.

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


Repository:
  rL LLVM

https://reviews.llvm.org/D22105



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

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

[Eugene Zelenko via cfe-commits]

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

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



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

Please separate with empty line.


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

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


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

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


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

Unnecessary empty line. Same at the end of function.


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

Please fix -Wextra-semi.


Repository:
  rL LLVM

https://reviews.llvm.org/D22507



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

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

[Matthias Gehre via cfe-commits]

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

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

Summary:
The code

  struct A {
int x[3];
  };

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

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

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

Reviewers: alexfh, aaron.ballman

Subscribers: aemerson, nemanjai, cfe-commits

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

Modified:

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

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

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

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


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

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

[Matthias Gehre via cfe-commits]

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

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

Repository:
  rL LLVM

https://reviews.llvm.org/D22381

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

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


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

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

[Eugene Zelenko via cfe-commits]

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

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



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

Please add space between = and delete.


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

Please separate different cases with empty lines.


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

Looks like = delete is missed fall all class methods.


Repository:
  rL LLVM

https://reviews.llvm.org/D22513



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

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

[Artem Belevich via cfe-commits]

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

Looks good.


https://reviews.llvm.org/D22518



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

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

[Aaron En Ye Shi via cfe-commits]

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

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


Repository:
  rL LLVM

https://reviews.llvm.org/D22424

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

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


Index: 

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

[NAKAMURA Takumi via cfe-commits]

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

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

Note, ClangRenameTests is linking USRFindingAction.cpp directly.

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

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


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

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

[NAKAMURA Takumi via cfe-commits]

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

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

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

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


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

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

[Jonathan Roelofs via cfe-commits]

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

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

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


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

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

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

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

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

—
Mehdi


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


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


Jon



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

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



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

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

[Samuel F Antao via cfe-commits]

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

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

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

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

[Ben Craig via cfe-commits]

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

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


https://reviews.llvm.org/D22470

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

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

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

[Samuel Antao via cfe-commits]

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

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

This was suggested by @rsmith in response to r275931.

https://reviews.llvm.org/D22518

Files:
  lib/Driver/Tools.cpp

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

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

[Haojian Wu via cfe-commits]

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

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

Repository:
  rL LLVM

https://reviews.llvm.org/D22510

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

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

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

[Daniel Jasper via cfe-commits]

djasper added a comment.

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


https://reviews.llvm.org/D22505



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

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

[Haojian Wu via cfe-commits]

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

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

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

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

Reviewers: bkramer

Subscribers: cfe-commits

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

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

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

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

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

[Anastasia Stulova via cfe-commits]

Anastasia added inline comments.


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

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


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

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

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


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

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


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

CurInit.get() can be changed to Init


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

Why was this change required?


https://reviews.llvm.org/D21567



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

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

[Robinson, Paul via cfe-commits]

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

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

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

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

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