Re: [PATCH] D12502: [libcxx] Better constain tuples constructors -- Fix PR23256 and PR22806

[Eric Fiselier via cfe-commits]

EricWF abandoned this revision.
EricWF added a comment.

Abandoning. This is super old and a different fix has been checked in.as 
r266461.


http://reviews.llvm.org/D12502



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

Re: [PATCH] D11781: Refactored pthread usage in libcxx

[Eric Fiselier via cfe-commits]

EricWF added a comment.

I would like to see this patch without the `support/pthread/*.cpp` files. There 
are a couple of reasons for this.

1. The symbols in those files are private to the dylib, but they are declared 
in the headers and given external visibility.
2. Those symbols frequently use std::chrono types in their interface. This 
creates a layering violating between the main STL and the support headers.
3. Moving the implementations of those functions now creates a bunch of noise 
in an already noisy patch. Keep the implementations in place for now.

Those changes can be re-added in a follow up patch.

Please combine all everything in `support` into a single file in the top level 
directory called `__thread_support` (Or similar, the name really doesn't matter 
but it should start with two underscores). Libc++ keeps the number of private 
headers is kept to a minimum and only introduces a new one when it needs to 
break a cycle or factor out code used in two places.

Overall this is looking good. Have you implemented a support layer for windows 
at all? If so I would be curious to see it, I would like to get a better idea 
of the end goal.



Comment at: include/support/pthread/condition_variable.h:54
@@ +53,3 @@
+_LIBCPP_FUNC_VIS
+void __os_cond_var_timed_wait(__os_cond_var* __cv,
+ __os_mutex* __m,

This is an internal function. It shouldn't be declared in these headers.


Comment at: include/support/pthread/mutex.h:27
@@ +26,3 @@
+typedef pthread_mutex_t __os_mutex;
+_LIBCPP_CONSTEXPR pthread_mutex_t __os_mutex_init = PTHREAD_MUTEX_INITIALIZER;
+

I think with would work for C++11 onward but unfortunately the mutex internals 
need to support C++03. For this reason we have to use a macro to ensure the 
initializer is constexpr.


Comment at: include/support/pthread/mutex.h:59
@@ +58,3 @@
+_LIBCPP_FUNC_VIS
+void __os_recursive_mutex_init(__os_mutex* __m);
+

This is an internal function and shouldn't be declared in the headers.


Comment at: include/support/pthread/mutex.h:62
@@ +61,3 @@
+inline _LIBCPP_INLINE_VISIBILITY
+int __os_recursive_mutex_lock(__os_mutex* __m)
+{

Shouldn't these functions take `__os_recursive_mutex*` types?


Comment at: include/support/pthread/mutex.h:85
@@ +84,3 @@
+
+_LIBCPP_FUNC_VIS void __os_call_once(volatile unsigned long&, void*, 
void(*)(void*));
+

This is an internal function and shouldn't be declared in the headers.


Comment at: include/support/pthread/thread.h:60
@@ +59,3 @@
+{
+bool res = pthread_equal(t1, t2);
+return res != 0 ? 0 : (t1 < t2 ? -1 : 1);

`res` needs to be an int, not a bool.


Comment at: include/support/pthread/thread.h:67
@@ +66,3 @@
+basic_ostream<_CharT, _Traits>&
+__os_write_to_ostream(basic_ostream<_CharT, _Traits>& __os, __os_thread_id 
__id)
+{

This function seems superfluous and introduces a dependency on IO streams. Get 
rid of it.


Comment at: include/support/pthread/thread.h:114
@@ +113,3 @@
+
+_LIBCPP_FUNC_VIS void __os_sleep_for(const chrono::nanoseconds& ns);
+

This is an internal function and shouldn't be declared in the headers.


Comment at: include/thread:238
@@ -236,3 +237,3 @@
 bool operator==(__thread_id __x, __thread_id __y) _NOEXCEPT
-{return __x.__id_ == __y.__id_;}
+{return __libcpp_support::__os_thread_id_compare(__x.__id_, __y.__id_) 
== 0;}
 friend _LIBCPP_INLINE_VISIBILITY

This now call's `pthread_equal`, across a library boundary, where it didn't 
before. That seems like a pessimization.
 


Comment at: include/thread:244
@@ -242,3 +243,3 @@
 bool operator< (__thread_id __x, __thread_id __y) _NOEXCEPT
-{return __x.__id_ < __y.__id_;}
+{return  __libcpp_support::__os_thread_id_compare(__x.__id_, 
__y.__id_) < 0;}
 friend _LIBCPP_INLINE_VISIBILITY

Same as above.


Comment at: include/thread:260
@@ -258,3 +259,3 @@
 operator<<(basic_ostream<_CharT, _Traits>& __os, __thread_id __id)
-{return __os << __id.__id_;}
+{return __libcpp_support::__os_write_to_ostream(__os, __id.__id_);}
 

As mentioned elsewhere just do this operation inline. No need for an extra 
function.


Comment at: include/thread:393
@@ -390,3 +392,3 @@
 std::unique_ptr<_Fp> __p(new _Fp(__f));
-int __ec = pthread_create(&__t_, 0, &__thread_proxy<_Fp>, __p.get());
+int __ec = __libcpp_support::__os_create_thread(&__t_, 
&__thread_proxy<_Gp>, __p.get());
 if (__ec == 0)

Typo `_Gp` should be `_Fp`.


Repository:
  rL LLVM

http://reviews.llvm.org/D11781



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://list

Re: [PATCH] D16545: [libcxxabi] Enable testing for static libc++abi

[Eric Fiselier via cfe-commits]

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

This part LGTM. Sorry about the delay.



Comment at: CMakeLists.txt:187
@@ +186,3 @@
+if (NOT LIBCXXABI_LIBCXX_LIBRARY_PATH)
+  set(LIBCXXABI_LIBCXX_LIBRARY_PATH "${LIBCXXABI_LIBRARY_DIR}" CACHE PATH
+  "The path to libc++ library.")

This variable should still probably be re-set even if it's given on the command 
line. By doing that you update the type and help text for the variable in the 
cache.


http://reviews.llvm.org/D16545



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

Re: [PATCH] D19146: [clang-tidy] New checker to detect suspicious string constructor.

[Etienne Bergeron via cfe-commits]

etienneb updated this revision to Diff 53979.
etienneb marked an inline comment as done.
etienneb added a comment.

alexfh nits.


http://reviews.llvm.org/D19146

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/StringConstructorCheck.cpp
  clang-tidy/misc/StringConstructorCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-string-constructor.rst
  test/clang-tidy/misc-string-constructor.cpp

Index: test/clang-tidy/misc-string-constructor.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-string-constructor.cpp
@@ -0,0 +1,54 @@
+// RUN: %check_clang_tidy %s misc-string-constructor %t
+
+namespace std {
+template 
+class allocator {};
+template 
+class char_traits {};
+template , typename A = std::allocator >
+struct basic_string {
+  basic_string();
+  basic_string(const C*, unsigned int size);
+  basic_string(unsigned int size, C c);
+};
+typedef basic_string string;
+typedef basic_string wstring;
+}
+
+const char* kText = "";
+const char kText2[] = "";
+extern const char kText3[];
+
+void Test() {
+  std::string str('x', 4);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor parameters are probably swapped [misc-string-constructor]
+  std::wstring wstr(L'x', 4);
+  // CHECK-MESSAGES: [[@LINE-1]]:16: warning: constructor parameters are probably swapped
+  std::string s0(0, 'x');
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor creating an empty string
+  std::string s1(-4, 'x');
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: negative value used as length parameter
+  std::string s2(0x100, 'x');
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: suspicious large length parameter
+  
+  std::string q0("test", 0);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor creating an empty string
+  std::string q1(kText, -4);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: negative value used as length parameter
+  std::string q2("test", 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+  std::string q3(kText, 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+  std::string q4(kText2, 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+  std::string q5(kText3,  0x100);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: suspicious large length parameter
+}
+
+void Valid() {
+  std::string empty();
+  std::string str(4, 'x');
+  std::wstring wstr(4, L'x');
+  std::string s1("test", 4);
+  std::string s2("test", 3);
+}
Index: docs/clang-tidy/checks/misc-string-constructor.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-string-constructor.rst
@@ -0,0 +1,36 @@
+.. title:: clang-tidy - misc-string-constructor
+
+misc-string-constructor
+===
+
+Finds string constructors that are suspicious and probably errors.
+
+
+A common mistake is to swap parameters to the 'fill' string-constructor.
+
+Examples:
+
+.. code:: c++
+
+  std::string('x', 50) str; // should be std::string(50, 'x') 
+
+
+Calling the string-literal constructor with a length bigger than the literal is
+suspicious and adds extra random characters to the string.
+
+Examples:
+
+.. code:: c++
+
+  std::string("test", 200);   // Will include random characters after "test".
+
+
+Creating an empty string from constructors with parameters is considered
+suspicious. The programmer should use the empty constructor instead.
+
+Examples:
+
+.. code:: c++
+
+  std::string("test", 0);   // Creation of an empty string.
+
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -69,6 +69,7 @@
misc-sizeof-container
misc-sizeof-expression
misc-static-assert
+   misc-string-constructor
misc-string-integer-assignment
misc-string-literal-with-embedded-nul
misc-suspicious-missing-comma
Index: clang-tidy/misc/StringConstructorCheck.h
===
--- /dev/null
+++ clang-tidy/misc/StringConstructorCheck.h
@@ -0,0 +1,39 @@
+//===--- StringConstructorCheck.h - clang-tidy---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_STRING_CONSTRUCTOR_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_STRING_CONSTRUCTOR_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+/// Finds suspicious string constructor and check their parameters.
+///
+/// For the user-facing documentation see:
+/// http:

Re: [PATCH] D18703: [clang-tidy] Add new checker for comparison with runtime string functions.

[Etienne Bergeron via cfe-commits]

etienneb updated this revision to Diff 53978.
etienneb added a comment.

nits


http://reviews.llvm.org/D18703

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/SuspiciousStringCompareCheck.cpp
  clang-tidy/misc/SuspiciousStringCompareCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-suspicious-string-compare.rst
  test/clang-tidy/misc-suspicious-string-compare.c
  test/clang-tidy/misc-suspicious-string-compare.cpp

Index: test/clang-tidy/misc-suspicious-string-compare.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-suspicious-string-compare.cpp
@@ -0,0 +1,299 @@
+// RUN: %check_clang_tidy %s misc-suspicious-string-compare %t -- \
+// RUN: -config='{CheckOptions: \
+// RUN:  [{key: misc-suspicious-string-compare.WarnOnImplicitComparison, value: 1}, \
+// RUN:   {key: misc-suspicious-string-compare.WarnOnLogicalNotComparison, value: 1}]}' \
+// RUN: --
+
+typedef __SIZE_TYPE__ size;
+
+struct locale_t {
+  void* dummy;
+} locale;
+
+static const char A[] = "abc";
+static const unsigned char U[] = "abc";
+static const unsigned char V[] = "xyz";
+static const wchar_t W[] = L"abc";
+
+int memcmp(const void *, const void *, size);
+int wmemcmp(const wchar_t *, const wchar_t *, size);
+int memicmp(const void *, const void *, size);
+int _memicmp(const void *, const void *, size);
+int _memicmp_l(const void *, const void *, size, locale_t);
+
+int strcmp(const char *, const char *);
+int strncmp(const char *, const char *, size);
+int strcasecmp(const char *, const char *);
+int strncasecmp(const char *, const char *, size);
+int stricmp(const char *, const char *);
+int strcmpi(const char *, const char *);
+int strnicmp(const char *, const char *, size);
+int _stricmp(const char *, const char * );
+int _strnicmp(const char *, const char *, size);
+int _stricmp_l(const char *, const char *, locale_t);
+int _strnicmp_l(const char *, const char *, size, locale_t);
+
+int wcscmp(const wchar_t *, const wchar_t *);
+int wcsncmp(const wchar_t *, const wchar_t *, size);
+int wcscasecmp(const wchar_t *, const wchar_t *);
+int wcsicmp(const wchar_t *, const wchar_t *);
+int wcsnicmp(const wchar_t *, const wchar_t *, size);
+int _wcsicmp(const wchar_t *, const wchar_t *);
+int _wcsnicmp(const wchar_t *, const wchar_t *, size);
+int _wcsicmp_l(const wchar_t *, const wchar_t *, locale_t);
+int _wcsnicmp_l(const wchar_t *, const wchar_t *, size, locale_t);
+
+int _mbscmp(const unsigned char *, const unsigned char *);
+int _mbsncmp(const unsigned char *, const unsigned char *, size);
+int _mbsnbcmp(const unsigned char *, const unsigned char *, size);
+int _mbsnbicmp(const unsigned char *, const unsigned char *, size);
+int _mbsicmp(const unsigned char *, const unsigned char *);
+int _mbsnicmp(const unsigned char *, const unsigned char *, size);
+int _mbscmp_l(const unsigned char *, const unsigned char *, locale_t);
+int _mbsncmp_l(const unsigned char *, const unsigned char *, size, locale_t);
+int _mbsicmp_l(const unsigned char *, const unsigned char *, locale_t);
+int _mbsnicmp_l(const unsigned char *, const unsigned char *, size, locale_t);
+int _mbsnbcmp_l(const unsigned char *, const unsigned char *, size, locale_t);
+int _mbsnbicmp_l(const unsigned char *, const unsigned char *, size, locale_t);
+
+int test_warning_patterns() {
+  if (strcmp(A, "a"))
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is called without explicitly comparing result [misc-suspicious-string-compare]
+  // CHECK-FIXES: if (strcmp(A, "a") != 0)
+
+  if (strcmp(A, "a") == 0 ||
+  strcmp(A, "b"))
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is called without explicitly comparing result
+  // CHECK-FIXES: strcmp(A, "b") != 0)
+
+  if (strcmp(A, "a") == 1)
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is compared to a suspicious constant
+
+  if (strcmp(A, "a") == -1)
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is compared to a suspicious constant
+
+  if (strcmp(A, "a") == true)
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is compared to a suspicious constant
+
+  if (strcmp(A, "a") < '0')
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is compared to a suspicious constant
+
+  if (strcmp(A, "a") < 0.)
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' has suspicious implicit cast
+}
+
+int test_valid_patterns() {
+  // The following cases are valid.
+  if (strcmp(A, "a") < 0)
+return 0;
+  if (strcmp(A, "a") == 0)
+return 0;
+  if (strcmp(A, "a") <= 0)
+return 0;
+
+  if (wcscmp(W, L"a") < 0)
+return 0;
+  if (wcscmp(W, L"a") == 0)
+return 0;
+  if (wcscmp(W, L"a") <= 0)
+return 0;
+
+  return 1;
+}
+
+int test_implicit_compare_with_functions() {
+
+  if (memcmp(A, "a", 1)

Re: [PATCH] D18703: [clang-tidy] Add new checker for comparison with runtime string functions.

[Etienne Bergeron via cfe-commits]

etienneb marked 4 inline comments as done.
etienneb added a comment.

ship draft.


http://reviews.llvm.org/D18703



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

[clang-tools-extra] r266511 - Add missing override keyword to silence -Winconsistent-missing-override. NFC

[Craig Topper via cfe-commits]

Author: ctopper
Date: Fri Apr 15 21:42:03 2016
New Revision: 266511

URL: http://llvm.org/viewvc/llvm-project?rev=266511&view=rev
Log:
Add missing override keyword to silence -Winconsistent-missing-override. NFC

Modified:
clang-tools-extra/trunk/clang-tidy/misc/SizeofExpressionCheck.h

Modified: clang-tools-extra/trunk/clang-tidy/misc/SizeofExpressionCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/SizeofExpressionCheck.h?rev=266511&r1=266510&r2=266511&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/SizeofExpressionCheck.h (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/SizeofExpressionCheck.h Fri Apr 15 
21:42:03 2016
@@ -23,7 +23,7 @@ namespace misc {
 class SizeofExpressionCheck : public ClangTidyCheck {
 public:
   SizeofExpressionCheck(StringRef Name, ClangTidyContext *Context);
-  void storeOptions(ClangTidyOptions::OptionMap &Opts);
+  void storeOptions(ClangTidyOptions::OptionMap &Opts) override;
   void registerMatchers(ast_matchers::MatchFinder *Finder) override;
   void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
 


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

Re: [PATCH] D16544: [libcxx] Framework to allow testing of static libc++abi

[Eric Fiselier via cfe-commits]

EricWF added a comment.

If we choose not to use full library paths could you please remove the 
'libcxx_library' option?  It just does what your trying here but worse, no need 
to keep it around.


http://reviews.llvm.org/D16544



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

Re: [PATCH] D16544: [libcxx] Framework to allow testing of static libc++abi

[Eric Fiselier via cfe-commits]

EricWF added a comment.

Just spitballing but have you considered simply passing the full path, 
including the library name, to LIT? Instead of needing `enable_shared` 
variables we would simply use the named library, be it DSO or archive.



Comment at: test/libcxx/test/config.py:488
@@ +487,3 @@
+if cxxabi_library_root:
+abs_path = cxxabi_library_root + "/libc++abi.a"
+self.cxx.link_flags += [abs_path]

`os.path.join`


Comment at: test/libcxx/test/target_info.py:113
@@ +112,3 @@
+# See PR22654.
+if(self.full_config.get_lit_conf('name', '') == 'libc++abi'):
+return True

This part makes me uncomfortable. Half the reason this was disabled in the 
first place was to help find bugs like this.

Make the comment a FIXME and file a bug and I'm OK with this going in for now.


http://reviews.llvm.org/D16544



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

Re: [PATCH] D9085: Fix tuple to A conversion in SFINAE for tuple(_Up...) constructor

[Eric Fiselier via cfe-commits]

EricWF resigned from this revision.
EricWF removed a reviewer: EricWF.
EricWF added a comment.

Resigning as reviewer because this patch is no longer relevant.

I fixed the issues today in r266461.


Repository:
  rL LLVM

http://reviews.llvm.org/D9085



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

Re: [PATCH] D18115: [libcxx] unordered_set: Update test for unnecessary mallocs in insert, NFC

[Eric Fiselier via cfe-commits]

EricWF resigned from this revision.
EricWF removed a reviewer: EricWF.
EricWF added a comment.

This patch is no longer relevant.


http://reviews.llvm.org/D18115



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

Re: [PATCH] D17410: [libcxxabi] Respect LIBCXXABI_LIBDIR_SUFFIX before an install

[Eric Fiselier via cfe-commits]

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

So we already do this for the standalone builds but not for in-tree builds. 
Before committing please make sure to remove the code on CMakeLists.txt line 99 
that does this same thing.

I'm assuming changing these CMake variables doesn't propagate upwards to other 
in-tree projects?

My one concern is that libc++ won't be able to find libc++abi when it's in a 
custom directory.
But that shouldn't cause problems unless it's made to.

After all that this LGTM.


http://reviews.llvm.org/D17410



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

Re: [PATCH] D16791: unordered_map: Match emplace_hint logic when _LIBCPP_DEBUG, NFC

[Eric Fiselier via cfe-commits]

EricWF resigned from this revision.
EricWF removed a reviewer: EricWF.
EricWF added a comment.

This no longer seems relevant.


http://reviews.llvm.org/D16791



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

Re: [PATCH] D16792: unordered_map: Use __hash_table::__emplace_unique(), NFC

[Eric Fiselier via cfe-commits]

EricWF resigned from this revision.
EricWF removed a reviewer: EricWF.
EricWF added a comment.

I think this has been landed (or is no longer relevent) after all of the recent 
changes.


http://reviews.llvm.org/D16792



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

Re: [PATCH] D19165: [clang-tidy] Add modernize-increment-bool check.

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

In http://reviews.llvm.org/D19165#403099, @Prazek wrote:

> In http://reviews.llvm.org/D19165#402657, @aaron.ballman wrote:
>
> > This strikes me as something the compiler should diagnose instead of a 
> > clang-tidy check. Incrementing a bool has been deprecated for some time, 
> > but it is outright removed in C++17, so I think giving users a migration 
> > path as part of the compiler would be far more beneficial. What do you 
> > think?
>
>
> clang already warns about it, but I don't think it has good fixits.


What clang diagnostic flags this issue? I'd rather make sure it provides good 
fixits than as a clang-tidy check that does almost the same. Clang-tidy can be 
configured to run Clang diagnostics and it will happily apply fixes if asked to.


http://reviews.llvm.org/D19165



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

Re: [PATCH] D17734: [libcxx] PR26777 Fix tests when built with CXX="ccache clang++"

[Eric Fiselier via cfe-commits]

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

I appreciate the patch, handling 'ccache' is a good thing to have.  I'll look 
at this again once the inline comment is addressed.



Comment at: CMakeLists.txt:225
@@ +224,3 @@
+# treated as seperate parameters.
+if(CMAKE_CXX_COMPILER_ARG1)
+  string(STRIP ${CMAKE_CXX_COMPILER_ARG1} LIBCXX_COMPILER )

What if somebody uses CXX='clang++ --foo'. It seems incorrect to handle ccache 
in this way. Instead I would rather we
1) Check if 'ARG1' is present.
2) If so attempt to find the string 'ccache' within 'CMAKE_CXX_COMPILER'
3) Only if we manage to match it do we use  'CMAKE_CXX_COMPILER_ARG1' as 
'LIBCXX_COMPILER'. 


http://reviews.llvm.org/D17734



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

Re: [PATCH] D19146: [clang-tidy] New checker to detect suspicious string constructor.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/misc/StringConstructorCheck.cpp:104
@@ +103,3 @@
+  const auto *E = Result.Nodes.getNodeAs("constructor");
+  assert(E);
+

We usually add some description to asserts (`assert(X && "X should not be 
nullptr");`).


Comment at: clang-tidy/misc/StringConstructorCheck.cpp:107
@@ +106,3 @@
+  if (Result.Nodes.getNodeAs("swapped-parameter")) {
+diag(E->getLocStart(), "constructor parameters are probably swapped");
+  } else if (Result.Nodes.getNodeAs("empty-string")) {

Might be nicer to pull `E->getLocStart()` to a variable.


http://reviews.llvm.org/D19146



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

Re: [PATCH] D19146: [clang-tidy] New checker to detect suspicious string constructor.

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

In http://reviews.llvm.org/D19146#402414, @alexfh wrote:

> In http://reviews.llvm.org/D19146#402410, @alexfh wrote:
>
> > I wonder whether `misc-swapped-arguments` can be tuned to handle these 
> > cases in a more generic way? The only missing part so far seems to be the 
> > lack of `cxxConstructExpr` support.
>
>
> And by "these cases" I mean the swapped arguments mistake, not the more 
> string-specific ones.


What about this comment?


http://reviews.llvm.org/D19146



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

r266501 - [modules] Don't expose *intrin.h headers that cannot be included standalone as

[Richard Smith via cfe-commits]

Author: rsmith
Date: Fri Apr 15 19:46:26 2016
New Revision: 266501

URL: http://llvm.org/viewvc/llvm-project?rev=266501&view=rev
Log:
[modules] Don't expose *intrin.h headers that cannot be included standalone as
separate modules. These cause build breakage with 
-fmodules-local-submodule-visibility.

Modified:
cfe/trunk/lib/Headers/module.modulemap
cfe/trunk/test/Headers/cxx11.cpp

Modified: cfe/trunk/lib/Headers/module.modulemap
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/module.modulemap?rev=266501&r1=266500&r2=266501&view=diff
==
--- cfe/trunk/lib/Headers/module.modulemap (original)
+++ cfe/trunk/lib/Headers/module.modulemap Fri Apr 15 19:46:26 2016
@@ -47,7 +47,19 @@ module _Builtin_intrinsics [system] [ext
 export *
 
 header "immintrin.h"
+textual header "f16cintrin.h"
+textual header "avxintrin.h"
+textual header "avx2intrin.h"
+textual header "avx512fintrin.h"
+textual header "avx512erintrin.h"
+textual header "fmaintrin.h"
+
 header "x86intrin.h"
+textual header "bmiintrin.h"
+textual header "bmi2intrin.h"
+textual header "lzcntintrin.h"
+textual header "xopintrin.h"
+textual header "fma4intrin.h"
 
 explicit module mm_malloc {
   header "mm_malloc.h"
@@ -62,10 +74,6 @@ module _Builtin_intrinsics [system] [ext
   header "mmintrin.h"
 }
 
-explicit module f16c {
-  header "f16cintrin.h"
-}
-
 explicit module sse {
   export mm_malloc
   export mmx
@@ -103,46 +111,6 @@ module _Builtin_intrinsics [system] [ext
   header "ammintrin.h"
 }
 
-explicit module avx {
-  export sse4_2
-  header "avxintrin.h"
-}
-
-explicit module avx2 {
-  export avx
-  header "avx2intrin.h"
-}
-
-explicit module avx512f {
-  export avx2
-  header "avx512fintrin.h"
-}
-
-explicit module avx512er {
-  header "avx512erintrin.h"
-}
-
-explicit module bmi {
-  header "bmiintrin.h"
-}
-
-explicit module bmi2 {
-  header "bmi2intrin.h"
-}
-
-explicit module fma {
-  header "fmaintrin.h"
-}
-
-explicit module fma4 {
-  export sse3
-  header "fma4intrin.h"
-}
-
-explicit module lzcnt {
-  header "lzcntintrin.h"
-}
-
 explicit module popcnt {
   header "popcntintrin.h"
 }
@@ -151,11 +119,6 @@ module _Builtin_intrinsics [system] [ext
   header "mm3dnow.h"
 }
 
-explicit module xop {
-  export fma4
-  header "xopintrin.h"
-}
-
 explicit module aes_pclmul {
   header "wmmintrin.h"
   export aes

Modified: cfe/trunk/test/Headers/cxx11.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/cxx11.cpp?rev=266501&r1=266500&r2=266501&view=diff
==
--- cfe/trunk/test/Headers/cxx11.cpp (original)
+++ cfe/trunk/test/Headers/cxx11.cpp Fri Apr 15 19:46:26 2016
@@ -1,6 +1,7 @@
 // RUN: rm -rf %t
 // RUN: %clang_cc1 -ffreestanding -fsyntax-only -std=c++11 %s
 // RUN: %clang_cc1 -ffreestanding -fsyntax-only -std=c++11 -fmodules 
-fmodules-cache-path=%t %s
+// RUN: %clang_cc1 -ffreestanding -fsyntax-only -std=c++11 -fmodules 
-fmodules-cache-path=%t -fmodules-local-submodule-visibility %s
 
 // This test fails on systems with older OS X 10.9 SDK headers, see PR18322.
 


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

Re: [PATCH] D17469: [libcxx] Add deployment knobs to tests (for Apple platforms)

[Eric Fiselier via cfe-commits]

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

LGTM.



Comment at: test/libcxx/test/config.py:66
@@ -65,3 +65,3 @@
 self.env = {}
 self.use_target = False
 self.use_system_cxx_lib = False

Was the omission of `self.use_deployment` here intentional? Python linters 
typically get upset by this.


http://reviews.llvm.org/D17469



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

[libcxx] r266498 - Teach map/unordered_map how to optimize 'emplace(Key, T)'.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Fri Apr 15 19:23:12 2016
New Revision: 266498

URL: http://llvm.org/viewvc/llvm-project?rev=266498&view=rev
Log:
Teach map/unordered_map how to optimize 'emplace(Key, T)'.

In cases where emplace is called with two arguments and the first one
matches the key_type we can Key to check for duplicates before allocating.

This patch expands on work done by dexonsm...@apple.com.

Modified:
libcxx/trunk/include/__hash_table
libcxx/trunk/include/__tree
libcxx/trunk/include/type_traits
libcxx/trunk/test/std/containers/map_allocator_requirement_test_templates.h
libcxx/trunk/test/std/containers/set_allocator_requirement_test_templates.h

libcxx/trunk/test/std/containers/unord/unord.map/unord.map.modifiers/insert_and_emplace_allocator_requirements.pass.cpp
libcxx/trunk/test/support/container_test_types.h

Modified: libcxx/trunk/include/__hash_table
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__hash_table?rev=266498&r1=266497&r2=266498&view=diff
==
--- libcxx/trunk/include/__hash_table (original)
+++ libcxx/trunk/include/__hash_table Fri Apr 15 19:23:12 2016
@@ -1056,6 +1056,17 @@ public:
   return __emplace_unique_extract_key(_VSTD::forward<_Pp>(__x),
   __can_extract_key<_Pp, key_type>());
 }
+
+template 
+_LIBCPP_INLINE_VISIBILITY
+typename enable_if<
+__can_extract_map_key<_First, key_type, __container_value_type>::value,
+pair
+>::type __emplace_unique(_First&& __f, _Second&& __s) {
+return __emplace_unique_key_args(__f, _VSTD::forward<_First>(__f),
+  _VSTD::forward<_Second>(__s));
+}
+
 template 
 _LIBCPP_INLINE_VISIBILITY
 pair __emplace_unique(_Args&&... __args) {

Modified: libcxx/trunk/include/__tree
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tree?rev=266498&r1=266497&r2=266498&view=diff
==
--- libcxx/trunk/include/__tree (original)
+++ libcxx/trunk/include/__tree Fri Apr 15 19:23:12 2016
@@ -1082,6 +1082,16 @@ public:
 __can_extract_key<_Pp, 
key_type>());
 }
 
+template 
+_LIBCPP_INLINE_VISIBILITY
+typename enable_if<
+__can_extract_map_key<_First, key_type, __container_value_type>::value,
+pair
+>::type __emplace_unique(_First&& __f, _Second&& __s) {
+return __emplace_unique_key_args(__f, _VSTD::forward<_First>(__f),
+  _VSTD::forward<_Second>(__s));
+}
+
 template 
 _LIBCPP_INLINE_VISIBILITY
 pair __emplace_unique(_Args&&... __args) {
@@ -1116,6 +1126,17 @@ public:
 __can_extract_key<_Pp, 
key_type>());
 }
 
+template 
+_LIBCPP_INLINE_VISIBILITY
+typename enable_if<
+__can_extract_map_key<_First, key_type, __container_value_type>::value,
+iterator
+>::type __emplace_hint_unique(const_iterator __p, _First&& __f, _Second&& 
__s) {
+return __emplace_hint_unique_key_args(__p, __f,
+  _VSTD::forward<_First>(__f),
+  _VSTD::forward<_Second>(__s));
+}
+
 template 
 _LIBCPP_INLINE_VISIBILITY
 iterator __emplace_hint_unique(const_iterator __p, _Args&&... __args) {

Modified: libcxx/trunk/include/type_traits
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/type_traits?rev=266498&r1=266497&r2=266498&view=diff
==
--- libcxx/trunk/include/type_traits (original)
+++ libcxx/trunk/include/type_traits Fri Apr 15 19:23:12 2016
@@ -4452,6 +4452,21 @@ template >
 : conditional::type, _Key>::value,
   __extract_key_first_tag, __extract_key_fail_tag>::type {};
+
+// __can_extract_map_key uses true_type/false_type instead of the tags.
+// It returns true if _Key != _ContainerValueTy (the container is a map not a 
set)
+// and _ValTy == _Key.
+template ::type>
+struct __can_extract_map_key
+: integral_constant::value> {};
+
+// This specialization returns __extract_key_fail_tag for non-map containers
+// because _Key == _ContainerValueTy
+template 
+struct __can_extract_map_key<_ValTy, _Key, _Key, _RawValTy>
+: false_type {};
+
 #endif
 
 _LIBCPP_END_NAMESPACE_STD

Modified: 
libcxx/trunk/test/std/containers/map_allocator_requirement_test_templates.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/map_allocator_requirement_test_templates.h?rev=266498&r1=266497&r2=266498&view=diff
==
--- libcxx/trunk/test/std/containers/map_allocator_requirement_test_templates.h 
(original)
+++ libcxx/trunk/test/

Re: [PATCH] D19180: [CUDA] Raise an error if the CUDA install can't be found.

[Justin Lebar via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL266496: [CUDA] Raise an error if the CUDA install can't be 
found. (authored by jlebar).

Changed prior to commit:
  http://reviews.llvm.org/D19180?vs=53954&id=53973#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D19180

Files:
  cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
  cfe/trunk/lib/Driver/ToolChains.cpp

Index: cfe/trunk/lib/Driver/ToolChains.cpp
===
--- cfe/trunk/lib/Driver/ToolChains.cpp
+++ cfe/trunk/lib/Driver/ToolChains.cpp
@@ -4118,11 +4118,14 @@
   if (DriverArgs.hasArg(options::OPT_nocudainc))
 return;
 
-  if (CudaInstallation.isValid()) {
-addSystemInclude(DriverArgs, CC1Args, CudaInstallation.getIncludePath());
-CC1Args.push_back("-include");
-CC1Args.push_back("__clang_cuda_runtime_wrapper.h");
+  if (!CudaInstallation.isValid()) {
+getDriver().Diag(diag::err_drv_no_cuda_installation);
+return;
   }
+
+  addSystemInclude(DriverArgs, CC1Args, CudaInstallation.getIncludePath());
+  CC1Args.push_back("-include");
+  CC1Args.push_back("__clang_cuda_runtime_wrapper.h");
 }
 
 bool Linux::isPIEDefault() const { return getSanitizerArgs().requiresPIE(); }
Index: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
@@ -23,6 +23,9 @@
 def err_drv_invalid_arch_name : Error<
   "invalid arch name '%0'">;
 def err_drv_cuda_bad_gpu_arch : Error<"Unsupported CUDA gpu architecture: %0">;
+def err_drv_no_cuda_installation : Error<
+  "cannot find CUDA installation.  Provide its path via --cuda-path, or pass "
+  "-nocudainc to build without CUDA includes.">;
 def err_drv_invalid_thread_model_for_target : Error<
   "invalid thread model '%0' in '%1' for this target">;
 def err_drv_invalid_linker_name : Error<


Index: cfe/trunk/lib/Driver/ToolChains.cpp
===
--- cfe/trunk/lib/Driver/ToolChains.cpp
+++ cfe/trunk/lib/Driver/ToolChains.cpp
@@ -4118,11 +4118,14 @@
   if (DriverArgs.hasArg(options::OPT_nocudainc))
 return;
 
-  if (CudaInstallation.isValid()) {
-addSystemInclude(DriverArgs, CC1Args, CudaInstallation.getIncludePath());
-CC1Args.push_back("-include");
-CC1Args.push_back("__clang_cuda_runtime_wrapper.h");
+  if (!CudaInstallation.isValid()) {
+getDriver().Diag(diag::err_drv_no_cuda_installation);
+return;
   }
+
+  addSystemInclude(DriverArgs, CC1Args, CudaInstallation.getIncludePath());
+  CC1Args.push_back("-include");
+  CC1Args.push_back("__clang_cuda_runtime_wrapper.h");
 }
 
 bool Linux::isPIEDefault() const { return getSanitizerArgs().requiresPIE(); }
Index: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
@@ -23,6 +23,9 @@
 def err_drv_invalid_arch_name : Error<
   "invalid arch name '%0'">;
 def err_drv_cuda_bad_gpu_arch : Error<"Unsupported CUDA gpu architecture: %0">;
+def err_drv_no_cuda_installation : Error<
+  "cannot find CUDA installation.  Provide its path via --cuda-path, or pass "
+  "-nocudainc to build without CUDA includes.">;
 def err_drv_invalid_thread_model_for_target : Error<
   "invalid thread model '%0' in '%1' for this target">;
 def err_drv_invalid_linker_name : Error<
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r266496 - [CUDA] Raise an error if the CUDA install can't be found.

[Justin Lebar via cfe-commits]

Author: jlebar
Date: Fri Apr 15 19:11:11 2016
New Revision: 266496

URL: http://llvm.org/viewvc/llvm-project?rev=266496&view=rev
Log:
[CUDA] Raise an error if the CUDA install can't be found.

Summary:
Without this change, we silently proceed on without including
__clang_cuda_runtime_wrapper.h.  This leads to very strange behavior --
you say you're compiling CUDA code, but e.g. __device__ is not defined!

Reviewers: tra

Subscribers: cfe-commits

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
cfe/trunk/lib/Driver/ToolChains.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=266496&r1=266495&r2=266496&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Fri Apr 15 19:11:11 
2016
@@ -23,6 +23,9 @@ def err_drv_unknown_language : Error<"la
 def err_drv_invalid_arch_name : Error<
   "invalid arch name '%0'">;
 def err_drv_cuda_bad_gpu_arch : Error<"Unsupported CUDA gpu architecture: %0">;
+def err_drv_no_cuda_installation : Error<
+  "cannot find CUDA installation.  Provide its path via --cuda-path, or pass "
+  "-nocudainc to build without CUDA includes.">;
 def err_drv_invalid_thread_model_for_target : Error<
   "invalid thread model '%0' in '%1' for this target">;
 def err_drv_invalid_linker_name : Error<

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=266496&r1=266495&r2=266496&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Fri Apr 15 19:11:11 2016
@@ -4118,11 +4118,14 @@ void Linux::AddCudaIncludeArgs(const Arg
   if (DriverArgs.hasArg(options::OPT_nocudainc))
 return;
 
-  if (CudaInstallation.isValid()) {
-addSystemInclude(DriverArgs, CC1Args, CudaInstallation.getIncludePath());
-CC1Args.push_back("-include");
-CC1Args.push_back("__clang_cuda_runtime_wrapper.h");
+  if (!CudaInstallation.isValid()) {
+getDriver().Diag(diag::err_drv_no_cuda_installation);
+return;
   }
+
+  addSystemInclude(DriverArgs, CC1Args, CudaInstallation.getIncludePath());
+  CC1Args.push_back("-include");
+  CC1Args.push_back("__clang_cuda_runtime_wrapper.h");
 }
 
 bool Linux::isPIEDefault() const { return getSanitizerArgs().requiresPIE(); }


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

Re: [PATCH] D19180: [CUDA] Raise an error if the CUDA install can't be found.

[Artem Belevich via cfe-commits]

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

LGTM.


http://reviews.llvm.org/D19180



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

r266495 - Improve diagnostic for the case when a non-defined function-like macro is used

[Richard Smith via cfe-commits]

Author: rsmith
Date: Fri Apr 15 19:07:09 2016
New Revision: 266495

URL: http://llvm.org/viewvc/llvm-project?rev=266495&view=rev
Log:
Improve diagnostic for the case when a non-defined function-like macro is used
in a preprocessor constant expression.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
cfe/trunk/lib/Lex/PPExpressions.cpp
cfe/trunk/test/Preprocessor/expr_invalid_tok.c
cfe/trunk/test/Preprocessor/has_attribute.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td?rev=266495&r1=266494&r2=266495&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td Fri Apr 15 19:07:09 2016
@@ -409,6 +409,8 @@ def err_pp_remainder_by_zero : Error<
   "remainder by zero in preprocessor expression">;
 def err_pp_expr_bad_token_binop : Error<
   "token is not a valid binary operator in a preprocessor subexpression">;
+def err_pp_expr_bad_token_lparen : Error<
+  "function-like macro %0 is not defined">;
 def err_pp_expr_bad_token_start_expr : Error<
   "invalid token at start of a preprocessor expression">;
 def err_pp_invalid_poison : Error<"can only poison identifier tokens">;

Modified: cfe/trunk/lib/Lex/PPExpressions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPExpressions.cpp?rev=266495&r1=266494&r2=266495&view=diff
==
--- cfe/trunk/lib/Lex/PPExpressions.cpp (original)
+++ cfe/trunk/lib/Lex/PPExpressions.cpp Fri Apr 15 19:07:09 2016
@@ -33,12 +33,18 @@ namespace {
 /// conditional and the source range covered by it.
 class PPValue {
   SourceRange Range;
+  IdentifierInfo *II;
 public:
   llvm::APSInt Val;
 
   // Default ctor - Construct an 'invalid' PPValue.
   PPValue(unsigned BitWidth) : Val(BitWidth) {}
 
+  // If this value was produced by directly evaluating an identifier, produce
+  // that identifier.
+  IdentifierInfo *getIdentifier() const { return II; }
+  void setIdentifier(IdentifierInfo *II) { this->II = II; }
+
   unsigned getBitWidth() const { return Val.getBitWidth(); }
   bool isUnsigned() const { return Val.isUnsigned(); }
 
@@ -209,6 +215,8 @@ static bool EvaluateValue(PPValue &Resul
   bool ValueLive, Preprocessor &PP) {
   DT.State = DefinedTracker::Unknown;
 
+  Result.setIdentifier(nullptr);
+
   if (PeekTok.is(tok::code_completion)) {
 if (PP.getCodeCompletionHandler())
   PP.getCodeCompletionHandler()->CodeCompletePreprocessorExpression();
@@ -234,6 +242,7 @@ static bool EvaluateValue(PPValue &Resul
   PP.Diag(PeekTok, diag::warn_pp_undef_identifier) << II;
 Result.Val = II->getTokenID() == tok::kw_true;
 Result.Val.setIsUnsigned(false);  // "0" is signed intmax_t 0.
+Result.setIdentifier(II);
 Result.setRange(PeekTok.getLocation());
 PP.LexNonComment(PeekTok);
 return false;
@@ -392,6 +401,7 @@ static bool EvaluateValue(PPValue &Resul
   DT.State = DefinedTracker::Unknown;
 }
 Result.setRange(Start, PeekTok.getLocation());
+Result.setIdentifier(nullptr);
 PP.LexNonComment(PeekTok);  // Eat the ).
 return false;
   }
@@ -401,6 +411,7 @@ static bool EvaluateValue(PPValue &Resul
 PP.LexNonComment(PeekTok);
 if (EvaluateValue(Result, PeekTok, DT, ValueLive, PP)) return true;
 Result.setBegin(Start);
+Result.setIdentifier(nullptr);
 return false;
   }
   case tok::minus: {
@@ -408,6 +419,7 @@ static bool EvaluateValue(PPValue &Resul
 PP.LexNonComment(PeekTok);
 if (EvaluateValue(Result, PeekTok, DT, ValueLive, PP)) return true;
 Result.setBegin(Loc);
+Result.setIdentifier(nullptr);
 
 // C99 6.5.3.3p3: The sign of the result matches the sign of the operand.
 Result.Val = -Result.Val;
@@ -428,6 +440,7 @@ static bool EvaluateValue(PPValue &Resul
 PP.LexNonComment(PeekTok);
 if (EvaluateValue(Result, PeekTok, DT, ValueLive, PP)) return true;
 Result.setBegin(Start);
+Result.setIdentifier(nullptr);
 
 // C99 6.5.3.3p4: The sign of the result matches the sign of the operand.
 Result.Val = ~Result.Val;
@@ -443,6 +456,7 @@ static bool EvaluateValue(PPValue &Resul
 Result.Val = !Result.Val;
 // C99 6.5.3.3p5: The sign of the result is 'int', aka it is signed.
 Result.Val.setIsUnsigned(false);
+Result.setIdentifier(nullptr);
 
 if (DT.State == DefinedTracker::DefinedMacro)
   DT.State = DefinedTracker::NotDefinedMacro;
@@ -491,6 +505,15 @@ static unsigned getPrecedence(tok::Token
   }
 }
 
+static void diagnoseUnexpectedOperator(Preprocessor &PP, PPValue &LHS,
+   Token &Tok) {
+  if (Tok.is(tok::l_paren) && LHS.getIdentifier())
+PP.Diag(LHS.getRange().getBegin(), diag::err_pp_expr_bad_token_lparen)
+   

Re: [PATCH] D18876: NFC: unify clang / LLVM atomic ordering

[JF Bastien via cfe-commits]

jfb added a comment.

In http://reviews.llvm.org/D18876#403119, @jyknight wrote:

> In http://reviews.llvm.org/D18876#402855, @jfb wrote:
>
> > In http://reviews.llvm.org/D18876#399934, @jyknight wrote:
> >
> > > The large amount of casting to/from integers for AtomicOrderingCABI makes 
> > > me think that it probably ought not actually be converted to an enum 
> > > class after all.
> >
> >
> > Untrusted user input with enums is a problem: you have to range-check 
> > before casting the int to the enum, with or without enum class, otherwise 
> > out-of-range is UB. I like it being explicit, but yeah what I had was wordy 
> > so I factored out the check.
> >
> > Casting *out* of the enum to generate constants is also wordy, but I think 
> > that's also fine. We could add a version of `ConstantInt` which takes in 
> > `is_integral_or_enum` but that seems like a lot of work for little typing? 
> > I'm happy to do that if you think it's worthwhile.
>
>
> Well, my suggestion had been to just leave it as a non-enum-class, like it 
> was before -- with no casts to or from the enum type. I think the code as it 
> was before was actually safe, too, wasn't it?
>
> I'm just not really sure using strong enums for the CABI type is really 
> buying much, since the basically only point of the C ABI kind is to use it as 
> an integer. Essentially every uses of it will be converting to/from integers, 
> won't it?


Yup the previous code was correct because it didn't create an enum from an 
untrusted int and then use it, it always carried the int around and relied on 
the known-good enum to convert to int when needed.

> I don't really feel strongly though, so if you want to go ahead, I'm okay 
> with that.


Yeah maybe it's a personal preference, but IMO the explicitness makes it harder 
to mess up :-)


http://reviews.llvm.org/D18876



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

[PATCH] D19184: Remove MaxFunctionCount module flag annotation

[Easwaran Raman via cfe-commits]

eraman created this revision.
eraman added a reviewer: vsk.
eraman added subscribers: cfe-commits, davidxl.

Step 2 of MaxFunctionCount removal. It is superseded by ProfileSummary flag.

http://reviews.llvm.org/D19184

Files:
  lib/CodeGen/CodeGenModule.cpp
  test/Profile/max-function-count.c

Index: test/Profile/max-function-count.c
===
--- test/Profile/max-function-count.c
+++ /dev/null
@@ -1,24 +0,0 @@
-// Test that maximum function counts are set correctly.
-
-// RUN: llvm-profdata merge %S/Inputs/max-function-count.proftext -o 
%t.profdata
-// RUN: %clang %s -o - -mllvm -disable-llvm-optzns -emit-llvm -S 
-fprofile-instr-use=%t.profdata | FileCheck %s
-//
-int begin(int i) {
-  if (i)
-return 0;
-  return 1;
-}
-
-int end(int i) {
-  if (i)
-return 0;
-  return 1;
-}
-
-int main(int argc, const char *argv[]) {
-  begin(0);
-  end(1);
-  end(1);
-  return 0;
-}
-// CHECK: !{{[0-9]+}} = !{i32 1, !"MaxFunctionCount", i32 2}
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -393,7 +393,6 @@
 OpenMPRuntime->emitRegistrationFunction())
   AddGlobalCtor(OpenMPRegistrationFunction, 0);
   if (PGOReader) {
-getModule().setMaximumFunctionCount(PGOReader->getMaximumFunctionCount());
 getModule().setProfileSummary(PGOReader->getSummary().getMD(VMContext));
 if (PGOStats.hasDiagnostics())
   PGOStats.reportDiagnostics(getDiags(), getCodeGenOpts().MainFileName);


Index: test/Profile/max-function-count.c
===
--- test/Profile/max-function-count.c
+++ /dev/null
@@ -1,24 +0,0 @@
-// Test that maximum function counts are set correctly.
-
-// RUN: llvm-profdata merge %S/Inputs/max-function-count.proftext -o %t.profdata
-// RUN: %clang %s -o - -mllvm -disable-llvm-optzns -emit-llvm -S -fprofile-instr-use=%t.profdata | FileCheck %s
-//
-int begin(int i) {
-  if (i)
-return 0;
-  return 1;
-}
-
-int end(int i) {
-  if (i)
-return 0;
-  return 1;
-}
-
-int main(int argc, const char *argv[]) {
-  begin(0);
-  end(1);
-  end(1);
-  return 0;
-}
-// CHECK: !{{[0-9]+}} = !{i32 1, !"MaxFunctionCount", i32 2}
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -393,7 +393,6 @@
 OpenMPRuntime->emitRegistrationFunction())
   AddGlobalCtor(OpenMPRegistrationFunction, 0);
   if (PGOReader) {
-getModule().setMaximumFunctionCount(PGOReader->getMaximumFunctionCount());
 getModule().setProfileSummary(PGOReader->getSummary().getMD(VMContext));
 if (PGOStats.hasDiagnostics())
   PGOStats.reportDiagnostics(getDiags(), getCodeGenOpts().MainFileName);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r266491 - Extract key to avoid preemptive mallocs in insert/emplace in associative containers

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Fri Apr 15 18:27:27 2016
New Revision: 266491

URL: http://llvm.org/viewvc/llvm-project?rev=266491&view=rev
Log:
Extract key to avoid preemptive mallocs in insert/emplace in associative 
containers

Summary: This patch applies Duncan's work on __hash_table to __tree.

Reviewers: mclow.lists, dexonsmith

Subscribers: dexonsmith, cfe-commits

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

Added:

libcxx/trunk/test/std/containers/associative/map/map.modifiers/insert_and_emplace_allocator_requirements.pass.cpp

libcxx/trunk/test/std/containers/associative/set/insert_and_emplace_allocator_requirements.pass.cpp
libcxx/trunk/test/std/containers/map_allocator_requirement_test_templates.h
libcxx/trunk/test/std/containers/set_allocator_requirement_test_templates.h
libcxx/trunk/test/support/assert_checkpoint.h
Removed:

libcxx/trunk/test/std/containers/associative/map/map.modifiers/insert_allocator_requirements.pass.cpp

libcxx/trunk/test/std/containers/associative/set/insert_allocator_requirements.pass.cpp
Modified:
libcxx/trunk/include/__hash_table
libcxx/trunk/include/__tree
libcxx/trunk/include/__tuple
libcxx/trunk/include/type_traits

libcxx/trunk/test/std/containers/associative/multimap/multimap.modifiers/insert_allocator_requirements.pass.cpp

libcxx/trunk/test/std/containers/associative/multiset/insert_allocator_requirements.pass.cpp

libcxx/trunk/test/std/containers/unord/unord.map/unord.map.modifiers/insert_and_emplace_allocator_requirements.pass.cpp

libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.modifiers/insert_allocator_requirements.pass.cpp

libcxx/trunk/test/std/containers/unord/unord.multiset/insert_allocator_requirements.pass.cpp

libcxx/trunk/test/std/containers/unord/unord.set/insert_and_emplace_allocator_requirements.pass.cpp

Modified: libcxx/trunk/include/__hash_table
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__hash_table?rev=266491&r1=266490&r2=266491&view=diff
==
--- libcxx/trunk/include/__hash_table (original)
+++ libcxx/trunk/include/__hash_table Fri Apr 15 18:27:27 2016
@@ -100,22 +100,6 @@ __next_hash_pow2(size_t __n)
 return size_t(1) << (std::numeric_limits::digits - __clz(__n-1));
 }
 
-#ifndef _LIBCPP_CXX03_LANG
-struct __extract_key_fail_tag {};
-struct __extract_key_self_tag {};
-struct __extract_key_first_tag {};
-
-template ::type>
-struct __can_extract_key
-: conditional::value, __extract_key_self_tag,
-  __extract_key_fail_tag>::type {};
-
-template 
-struct __can_extract_key<_Pair, _Key, pair<_First, _Second>>
-: conditional::type, _Key>::value,
-  __extract_key_first_tag, __extract_key_fail_tag>::type {};
-#endif
 
 template  class 
__hash_table;
 

Modified: libcxx/trunk/include/__tree
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tree?rev=266491&r1=266490&r2=266491&view=diff
==
--- libcxx/trunk/include/__tree (original)
+++ libcxx/trunk/include/__tree Fri Apr 15 18:27:27 2016
@@ -1064,16 +1064,85 @@ public:
 __emplace_hint_unique_key_args(const_iterator, _Key const&, _Args&&...);
 
 template 
-pair __emplace_unique(_Args&&... __args);
+pair __emplace_unique_impl(_Args&&... __args);
 
 template 
-iterator __emplace_hint_unique(const_iterator __p, _Args&&... __args);
+iterator __emplace_hint_unique_impl(const_iterator __p, _Args&&... __args);
 
 template 
 iterator __emplace_multi(_Args&&... __args);
 
 template 
 iterator __emplace_hint_multi(const_iterator __p, _Args&&... __args);
+
+template 
+_LIBCPP_INLINE_VISIBILITY
+pair __emplace_unique(_Pp&& __x) {
+return __emplace_unique_extract_key(_VSTD::forward<_Pp>(__x),
+__can_extract_key<_Pp, 
key_type>());
+}
+
+template 
+_LIBCPP_INLINE_VISIBILITY
+pair __emplace_unique(_Args&&... __args) {
+return __emplace_unique_impl(_VSTD::forward<_Args>(__args)...);
+}
+
+template 
+_LIBCPP_INLINE_VISIBILITY
+pair
+__emplace_unique_extract_key(_Pp&& __x, __extract_key_fail_tag) {
+  return __emplace_unique_impl(_VSTD::forward<_Pp>(__x));
+}
+
+template 
+_LIBCPP_INLINE_VISIBILITY
+pair
+__emplace_unique_extract_key(_Pp&& __x, __extract_key_self_tag) {
+  return __emplace_unique_key_args(__x, _VSTD::forward<_Pp>(__x));
+}
+
+template 
+_LIBCPP_INLINE_VISIBILITY
+pair
+__emplace_unique_extract_key(_Pp&& __x, __extract_key_first_tag) {
+  return __emplace_unique_key_args(__x.first, _VSTD::forward<_Pp>(__x));
+}
+
+template 
+_LIBCPP_INLINE_VISIBILITY
+iterator __emplace_hint_unique(const_iterator __p, _Pp&& __x) {
+return __emplace_hint_unique_extract_key(__p, _VSTD::

Re: [PATCH] D18637: Extract key to avoid preemptive mallocs in insert/emplace in associative containers

[Eric Fiselier via cfe-commits]

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

I've silenced the tests when they pass as suggested. I added a 
'assert_checkpoint.h' support header that stores the last checkpoint a test has 
passed and prints that information when std::abort is called.

I also moved the allocator requirement test templates into generic headers so 
the same version can be used by both the associative and unordered containers.  
Previously each test was duplicated.


http://reviews.llvm.org/D18637

Files:
  include/__hash_table
  include/__tree
  include/__tuple
  include/type_traits
  
test/std/containers/associative/map/map.modifiers/insert_allocator_requirements.pass.cpp
  
test/std/containers/associative/map/map.modifiers/insert_and_emplace_allocator_requirements.pass.cpp
  
test/std/containers/associative/multimap/multimap.modifiers/insert_allocator_requirements.pass.cpp
  
test/std/containers/associative/multiset/insert_allocator_requirements.pass.cpp
  test/std/containers/associative/set/insert_allocator_requirements.pass.cpp
  
test/std/containers/associative/set/insert_and_emplace_allocator_requirements.pass.cpp
  test/std/containers/map_allocator_requirement_test_templates.h
  test/std/containers/set_allocator_requirement_test_templates.h
  
test/std/containers/unord/unord.map/unord.map.modifiers/insert_and_emplace_allocator_requirements.pass.cpp
  
test/std/containers/unord/unord.multimap/unord.multimap.modifiers/insert_allocator_requirements.pass.cpp
  
test/std/containers/unord/unord.multiset/insert_allocator_requirements.pass.cpp
  
test/std/containers/unord/unord.set/insert_and_emplace_allocator_requirements.pass.cpp
  test/support/assert_checkpoint.h

Index: test/support/assert_checkpoint.h
===
--- /dev/null
+++ test/support/assert_checkpoint.h
@@ -0,0 +1,62 @@
+#ifndef SUPPORT_ASSERT_CHECKPOINT_H
+#define SUPPORT_ASSERT_CHECKPOINT_H
+
+#include 
+#include 
+#include 
+
+struct Checkpoint {
+  const char* file;
+  const char* func;
+  int line;
+  const char* msg;
+
+  template 
+  void print(Stream& s) const {
+  if (!file) {
+  s << "NO CHECKPOINT\n";
+  return;
+  }
+  s << file << ":" << line << " " << func << ": Checkpoint";
+  if (msg)
+s << " '" << msg << "'";
+  s << std::endl;
+  }
+};
+
+inline Checkpoint& globalCheckpoint() {
+static Checkpoint C;
+return C;
+}
+
+inline void clearCheckpoint() {
+globalCheckpoint() = Checkpoint{0};
+}
+
+#define CHECKPOINT(msg) globalCheckpoint() = Checkpoint{__FILE__, __PRETTY_FUNCTION__, __LINE__, msg}
+
+inline void checkpointSignalHandler(int signal) {
+if (signal == SIGABRT) {
+globalCheckpoint().print(std::cerr);
+} else {
+std::cerr << "Unexpected signal " << signal << " received\n";
+}
+std::_Exit(EXIT_FAILURE);
+}
+
+inline bool initCheckpointHandler() {
+typedef void(*HandlerT)(int);
+static bool isInit = false;
+if (isInit) return true;
+HandlerT prev_h = std::signal(SIGABRT, checkpointSignalHandler);
+if (prev_h == SIG_ERR) {
+std::cerr << "Setup failed.\n";
+std::_Exit(EXIT_FAILURE);
+}
+isInit = true;
+return false;
+}
+
+static bool initDummy = initCheckpointHandler();
+
+#endif
Index: test/std/containers/unord/unord.set/insert_and_emplace_allocator_requirements.pass.cpp
===
--- test/std/containers/unord/unord.set/insert_and_emplace_allocator_requirements.pass.cpp
+++ test/std/containers/unord/unord.set/insert_and_emplace_allocator_requirements.pass.cpp
@@ -17,199 +17,13 @@
 // UNSUPPORTED: c++98, c++03
 
 #include 
-#include 
-#include 
 
-#include "test_macros.h"
-#include "count_new.hpp"
 #include "container_test_types.h"
-
-template 
-void PrintInfo(int line, Arg&& arg)
-{
-  std::cout << "In " << __FILE__ << ":" << line << ":\n" << arg << "\n" << std::endl;
-}
-#define PRINT(msg) PrintInfo(__LINE__, msg)
-
-template 
-void testContainerInsert()
-{
-  typedef typename Container::value_type ValueTp;
-  typedef Container C;
-  typedef std::pair R;
-  ConstructController* cc = getConstructController();
-  cc->reset();
-  {
-PRINT("Testing C::insert(const value_type&)");
-Container c;
-const ValueTp v(42);
-cc->expect();
-assert(c.insert(v).second);
-assert(!cc->unchecked());
-{
-  DisableAllocationGuard g;
-  const ValueTp v2(42);
-  assert(c.insert(v2).second == false);
-}
-  }
-  {
-PRINT("Testing C::insert(value_type&)");
-Container c;
-ValueTp v(42);
-cc->expect();
-assert(c.insert(v).second);
-assert(!cc->unchecked());
-{
-  DisableAllocationGuard g;
-  ValueTp v2(42);
-  assert(c.insert(v2).second == false);
-}
-  }
-  {
-PRINT("Testing C::insert(value_type&&)");
-Container c;
-ValueTp v(42);
-cc->expect();
-assert(c.insert(std::move(v)).second);
-

Re: [PATCH] D18876: NFC: unify clang / LLVM atomic ordering

[James Y Knight via cfe-commits]

jyknight added a comment.

In http://reviews.llvm.org/D18876#402855, @jfb wrote:

> In http://reviews.llvm.org/D18876#399934, @jyknight wrote:
>
> > The large amount of casting to/from integers for AtomicOrderingCABI makes 
> > me think that it probably ought not actually be converted to an enum class 
> > after all.
>
>
> Untrusted user input with enums is a problem: you have to range-check before 
> casting the int to the enum, with or without enum class, otherwise 
> out-of-range is UB. I like it being explicit, but yeah what I had was wordy 
> so I factored out the check.
>
> Casting *out* of the enum to generate constants is also wordy, but I think 
> that's also fine. We could add a version of `ConstantInt` which takes in 
> `is_integral_or_enum` but that seems like a lot of work for little typing? 
> I'm happy to do that if you think it's worthwhile.


Well, my suggestion had been to just leave it as a non-enum-class, like it was 
before -- with no casts to or from the enum type. I think the code as it was 
before was actually safe, too, wasn't it?

I'm just not really sure using strong enums for the CABI type is really buying 
much, since the basically only point of the C ABI kind is to use it as an 
integer. Essentially every uses of it will be converting to/from integers, 
won't it?

I don't really feel strongly though, so if you want to go ahead, I'm okay with 
that.


http://reviews.llvm.org/D18876



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

Re: [PATCH] D18821: Add modernize-bool-to-integer-conversion

[Piotr Padlewski via cfe-commits]

Prazek added a comment.

In http://reviews.llvm.org/D18821#402686, @Prazek wrote:

> In http://reviews.llvm.org/D18821#398843, @alexfh wrote:
>
> > BTW, why is the check in the 'modernize' module? It doesn't seem to make 
> > anything more modern. I would guess, the pattern it detects is most likely 
> > to result from a programming error. Also, the fix, though it retains the 
> > behavior, has a high chance to be incorrect. Can you share the results of 
> > running this check on LLVM? At least, how many problems it found and how 
> > many times the suggested fix was correct.
> >
> > I'd suggest to move the check to `misc` or maybe it's time to create a 
> > separate directory for checks targeting various bug-prone patterns.
>
>
> Do you have any thought about the name for such a module? I belive that misc 
> is overloaded.
>
> So for this we are looking for something that is probably not a bug, but it 
> makes code a little bit inaccurate
>  Maybe something like:
>
> - accuracy,
> - correctness,
> - certainity,
> - safety,
> - maybebugmaybenothardtosay


after a long though I think that "accuracy" is the best name here - we want to 
look for a code that is valid, but not accurate


http://reviews.llvm.org/D18821



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

Re: [PATCH] D18821: Add modernize-bool-to-integer-conversion

[Piotr Padlewski via cfe-commits]

Prazek added a comment.

In http://reviews.llvm.org/D18821#403103, @Quuxplusone wrote:

> I would like to see a new version of http://reviews.llvm.org/D19105 with all 
> the "1-bit-bitfield" diffs removed.
>  Right now, it's hard to see that there's *anything* in 
> http://reviews.llvm.org/D19105 that's not a miscorrection of a 1-bit bitfield.
>
> Do you have an example of a large codebase where this check runs with few 
> false positives and a non-zero number of true positives?


I will post fixex tomorrow. I don't think there will be any false or true 
positives in warnings, but the main problems with fixes are that many times 
developer wants to use bools, but it decalres field/return type as int.


http://reviews.llvm.org/D18821



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

Re: [PATCH] D19165: [clang-tidy] Add modernize-increment-bool check.

[Piotr Padlewski via cfe-commits]

Prazek added a comment.

Besides comments, looks good to me. But before posting make sure that 
clang-diagnostics doesn't already have fixits.



Comment at: clang-tidy/modernize/IncrementBoolCheck.cpp:51
@@ +50,3 @@
+  // Don't fix if expression type is dependent on template initialization
+  if (MatchedExpr->isTypeDependent())
+return;

doesn't isInTemplateInstantiation fix it?


Comment at: clang-tidy/modernize/ModernizeTidyModule.cpp:38
@@ -36,1 +37,3 @@
 "modernize-deprecated-headers");
+CheckFactories.registerCheck(
+"modernize-increment-bool");

run git-clang-format on your patch, because I see that perhaps this one and 
other files coud be clang-formatted


Comment at: docs/clang-tidy/checks/modernize-increment-bool.rst:50-55
@@ +49,8 @@
+
+  /* Equivalent to:
+if (!first) {
+  second = false;
+  first = true;
+}
+  */
+  if (!first) second = first++;

put this one under the if statment and remove comments liek this:

 if (!first) 
second = first++;
// is equivalent to
  if (!first) {
  second = false;
  first = true;
}


http://reviews.llvm.org/D19165



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

Re: [PATCH] D18821: Add modernize-bool-to-integer-conversion

[Arthur O'Dwyer via cfe-commits]

Quuxplusone added a subscriber: Quuxplusone.
Quuxplusone added a comment.

I would like to see a new version of http://reviews.llvm.org/D19105 with all 
the "1-bit-bitfield" diffs removed.
Right now, it's hard to see that there's *anything* in 
http://reviews.llvm.org/D19105 that's not a miscorrection of a 1-bit bitfield.

Do you have an example of a large codebase where this check runs with few false 
positives and a non-zero number of true positives?


http://reviews.llvm.org/D18821



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

Re: [PATCH] D18703: [clang-tidy] Add new checker for comparison with runtime string functions.

[Etienne Bergeron via cfe-commits]

etienneb added a comment.

ok, alexfh.
I addressed your comments.


http://reviews.llvm.org/D18703



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

Re: [PATCH] D19165: [clang-tidy] Add modernize-increment-bool check.

[Piotr Padlewski via cfe-commits]

Prazek added a comment.

In http://reviews.llvm.org/D19165#402657, @aaron.ballman wrote:

> This strikes me as something the compiler should diagnose instead of a 
> clang-tidy check. Incrementing a bool has been deprecated for some time, but 
> it is outright removed in C++17, so I think giving users a migration path as 
> part of the compiler would be far more beneficial. What do you think?


clang already warns about it, but I don't think it has good fixits.


http://reviews.llvm.org/D19165



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

Re: [PATCH] D18703: [clang-tidy] Add new checker for comparison with runtime string functions.

[Etienne Bergeron via cfe-commits]

etienneb updated this revision to Diff 53966.
etienneb added a comment.

alexfh comments.


http://reviews.llvm.org/D18703

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/SuspiciousStringCompareCheck.cpp
  clang-tidy/misc/SuspiciousStringCompareCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-suspicious-string-compare.rst
  test/clang-tidy/misc-suspicious-string-compare.c
  test/clang-tidy/misc-suspicious-string-compare.cpp

Index: test/clang-tidy/misc-suspicious-string-compare.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-suspicious-string-compare.cpp
@@ -0,0 +1,299 @@
+// RUN: %check_clang_tidy %s misc-suspicious-string-compare %t -- \
+// RUN: -config='{CheckOptions: \
+// RUN:  [{key: misc-suspicious-string-compare.WarnOnImplicitComparison, value: 1}, \
+// RUN:   {key: misc-suspicious-string-compare.WarnOnLogicalNotComparison, value: 1}]}' \
+// RUN: --
+
+typedef __SIZE_TYPE__ size;
+
+struct locale_t {
+  void* dummy;
+} locale;
+
+static const char A[] = "abc";
+static const unsigned char U[] = "abc";
+static const unsigned char V[] = "xyz";
+static const wchar_t W[] = L"abc";
+
+int memcmp(const void *, const void *, size);
+int wmemcmp(const wchar_t *, const wchar_t *, size);
+int memicmp(const void *, const void *, size);
+int _memicmp(const void *, const void *, size);
+int _memicmp_l(const void *, const void *, size, locale_t);
+
+int strcmp(const char *, const char *);
+int strncmp(const char *, const char *, size);
+int strcasecmp(const char *, const char *);
+int strncasecmp(const char *, const char *, size);
+int stricmp(const char *, const char *);
+int strcmpi(const char *, const char *);
+int strnicmp(const char *, const char *, size);
+int _stricmp(const char *, const char * );
+int _strnicmp(const char *, const char *, size);
+int _stricmp_l(const char *, const char *, locale_t);
+int _strnicmp_l(const char *, const char *, size, locale_t);
+
+int wcscmp(const wchar_t *, const wchar_t *);
+int wcsncmp(const wchar_t *, const wchar_t *, size);
+int wcscasecmp(const wchar_t *, const wchar_t *);
+int wcsicmp(const wchar_t *, const wchar_t *);
+int wcsnicmp(const wchar_t *, const wchar_t *, size);
+int _wcsicmp(const wchar_t *, const wchar_t *);
+int _wcsnicmp(const wchar_t *, const wchar_t *, size);
+int _wcsicmp_l(const wchar_t *, const wchar_t *, locale_t);
+int _wcsnicmp_l(const wchar_t *, const wchar_t *, size, locale_t);
+
+int _mbscmp(const unsigned char *, const unsigned char *);
+int _mbsncmp(const unsigned char *, const unsigned char *, size);
+int _mbsnbcmp(const unsigned char *, const unsigned char *, size);
+int _mbsnbicmp(const unsigned char *, const unsigned char *, size);
+int _mbsicmp(const unsigned char *, const unsigned char *);
+int _mbsnicmp(const unsigned char *, const unsigned char *, size);
+int _mbscmp_l(const unsigned char *, const unsigned char *, locale_t);
+int _mbsncmp_l(const unsigned char *, const unsigned char *, size, locale_t);
+int _mbsicmp_l(const unsigned char *, const unsigned char *, locale_t);
+int _mbsnicmp_l(const unsigned char *, const unsigned char *, size, locale_t);
+int _mbsnbcmp_l(const unsigned char *, const unsigned char *, size, locale_t);
+int _mbsnbicmp_l(const unsigned char *, const unsigned char *, size, locale_t);
+
+int test_warning_patterns() {
+  if (strcmp(A, "a"))
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is called without explicitly comparing result [misc-suspicious-string-compare]
+  // CHECK-FIXES: if (strcmp(A, "a") != 0)
+
+  if (strcmp(A, "a") == 0 ||
+  strcmp(A, "b"))
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is called without explicitly comparing result
+  // CHECK-FIXES: strcmp(A, "b") != 0)
+
+  if (strcmp(A, "a") == 1)
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is compared to a suspicious constant
+
+  if (strcmp(A, "a") == -1)
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is compared to a suspicious constant
+
+  if (strcmp(A, "a") == true)
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is compared to a suspicious constant
+
+  if (strcmp(A, "a") < '0')
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' is compared to a suspicious constant
+
+  if (strcmp(A, "a") < 0.)
+return 0;
+  // CHECK-MESSAGES: [[@LINE-2]]:7: warning: function 'strcmp' has suspicious implicit cast
+}
+
+int test_valid_patterns() {
+  // The following cases are valid.
+  if (strcmp(A, "a") < 0)
+return 0;
+  if (strcmp(A, "a") == 0)
+return 0;
+  if (strcmp(A, "a") <= 0)
+return 0;
+
+  if (wcscmp(W, L"a") < 0)
+return 0;
+  if (wcscmp(W, L"a") == 0)
+return 0;
+  if (wcscmp(W, L"a") <= 0)
+return 0;
+
+  return 1;
+}
+
+int test_implicit_compare_with_functions() {
+
+  if (memcm

[PATCH] D19183: [clang-tidy] Add modernize-make-shared check

[Piotr Padlewski via cfe-commits]

Prazek created this revision.
Prazek added reviewers: alexfh, mnbvmar, staronj, krystyna, angelgarcia.
Prazek added a subscriber: cfe-commits.

Because modernize-make-shared do almos the same job,
  I refactored common code to MakeSmartPtrCheck.

http://reviews.llvm.org/D19183

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/MakeSharedCheck.cpp
  clang-tidy/modernize/MakeSharedCheck.h
  clang-tidy/modernize/MakeSmartPtrCheck.cpp
  clang-tidy/modernize/MakeSmartPtrCheck.h
  clang-tidy/modernize/MakeUniqueCheck.cpp
  clang-tidy/modernize/MakeUniqueCheck.h
  clang-tidy/modernize/ModernizeTidyModule.cpp
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-make-shared.rst
  test/clang-tidy/modernize-make-shared.cpp

Index: test/clang-tidy/modernize-make-shared.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-make-shared.cpp
@@ -0,0 +1,198 @@
+// RUN: %check_clang_tidy %s modernize-make-shared %t
+
+namespace std {
+
+template 
+class shared_ptr {
+public:
+  shared_ptr(type *ptr);
+  shared_ptr(const shared_ptr &t) {}
+  shared_ptr(shared_ptr &&t) {}
+  ~shared_ptr();
+  type &operator*() { return *ptr; }
+  type *operator->() { return ptr; }
+  type *release();
+  void reset();
+  void reset(type *pt);
+
+private:
+  type *ptr;
+};
+}
+
+struct Base {
+  Base();
+  Base(int, int);
+};
+
+struct Derived : public Base {
+  Derived();
+  Derived(int, int);
+};
+
+struct APair {
+  int a, b;
+};
+
+struct DPair {
+  DPair() : a(0), b(0) {}
+  DPair(int x, int y) : a(y), b(x) {}
+  int a, b;
+};
+
+struct Empty {};
+
+template 
+using shared_ptr_ = std::shared_ptr;
+
+void *operator new(__SIZE_TYPE__ Count, void *Ptr);
+
+int g(std::shared_ptr P);
+
+std::shared_ptr getPointer() {
+  return std::shared_ptr(new Base);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: use std::make_shared instead
+  // CHECK-FIXES: return std::make_shared();
+}
+
+void basic() {
+  std::shared_ptr P1 = std::shared_ptr(new int());
+  // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_shared instead [modernize-make-shared]
+  // CHECK-FIXES: std::shared_ptr P1 = std::make_shared();
+
+  // Without parenthesis.
+  std::shared_ptr P2 = std::shared_ptr(new int);
+  // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_shared instead [modernize-make-shared]
+  // CHECK-FIXES: std::shared_ptr P2 = std::make_shared();
+
+  // With auto.
+  auto P3 = std::shared_ptr(new int());
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use std::make_shared instead
+  // CHECK-FIXES: auto P3 = std::make_shared();
+
+  {
+// No std.
+using namespace std;
+shared_ptr Q = shared_ptr(new int());
+// CHECK-MESSAGES: :[[@LINE-1]]:25: warning: use std::make_shared instead
+// CHECK-FIXES: shared_ptr Q = std::make_shared();
+  }
+
+  std::shared_ptr R(new int());
+
+  // Create the shared_ptr as a parameter to a function.
+  int T = g(std::shared_ptr(new int()));
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use std::make_shared instead
+  // CHECK-FIXES: int T = g(std::make_shared());
+
+  // Only replace if the type in the template is the same than the type returned
+  // by the new operator.
+  auto Pderived = std::shared_ptr(new Derived());
+
+  // The pointer is returned by the function, nothing to do.
+  std::shared_ptr RetPtr = getPointer();
+
+  // This emulates std::move.
+  std::shared_ptr Move = static_cast &&>(P1);
+
+  // Placemenet arguments should not be removed.
+  int *PInt = new int;
+  std::shared_ptr Placement = std::shared_ptr(new (PInt) int{3});
+}
+
+void initialization(int T, Base b) {
+  // Test different kinds of initialization of the pointee.
+
+  // Direct initialization with parenthesis.
+  std::shared_ptr PDir1 = std::shared_ptr(new DPair(1, T));
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: use std::make_shared instead
+  // CHECK-FIXES: std::shared_ptr PDir1 = std::make_shared(1, T);
+
+  // Direct initialization with braces.
+  std::shared_ptr PDir2 = std::shared_ptr(new DPair{2, T});
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: use std::make_shared instead
+  // CHECK-FIXES: std::shared_ptr PDir2 = std::make_shared(2, T);
+
+  // Aggregate initialization.
+  std::shared_ptr PAggr = std::shared_ptr(new APair{T, 1});
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: use std::make_shared instead
+  // CHECK-FIXES: std::shared_ptr PAggr = std::make_shared(APair{T, 1});
+
+  // Test different kinds of initialization of the pointee, when the shared_ptr
+  // is initialized with braces.
+
+  // Direct initialization with parenthesis.
+  std::shared_ptr PDir3 = std::shared_ptr{new DPair(3, T)};
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: use std::make_shared instead
+  // CHECK-FIXES: std::shared_ptr PDir3 = std::make_shared(3, T);
+
+  // Direct initialization with braces.
+  std::shared_ptr PDir4 = std::shared_ptr{new DPair{4, T}};
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: 

Re: [PATCH] D16396: Warn if variable cannot be implicitly instantiated

[Richard Smith via cfe-commits]

On Fri, Apr 15, 2016 at 12:56 AM, Serge Pavlov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> 2016-04-14 2:44 GMT+06:00 Richard Smith :
>
>> rsmith added a comment.
>>
>> I would prefer to avoid adding the `%qt` format if we can. But if we do
>> provide it, the template parameter names we use should match what was
>> written in the declaration of the template itself.
>>
>> New format was not a good idea. Removed it.
>
>
>>
>> 
>> Comment at: lib/AST/Decl.cpp:1423
>> @@ +1422,3 @@
>> +///
>> +/// is printed as C1::C2>::meth rather than
>> C1::C2::meth.
>> +///
>> 
>> Presumably you mean `C1::C2::meth`?
>>
>> Fixed.
>
>
>> 
>> Comment at: lib/AST/Decl.cpp:1447
>> @@ +1446,3 @@
>> +  OS << "...";
>> +OS << 'T';
>> +if (TypePNo)
>> 
>> Please don't invent a name here. If you really want this formatting for
>> template names, please query the `TemplateDecl` to find the names that were
>> used when declaring its parameters.
>>
>> 
>> Comment at: lib/AST/Decl.cpp:1464
>> @@ +1463,3 @@
>> +  OS << TemplPNo;
>> +OS << "<>";
>> +TemplPNo++;
>> 
>> This doesn't make sense: a template template argument is passed as a
>> template, but adding `<>` would make it a type instead. Remove this.
>>
>> Both fixed.
>
>
>> 
>> Comment at: lib/Sema/SemaTemplateInstantiateDecl.cpp:3611
>> @@ +3610,3 @@
>> +  if (AtEndOfTU && !getDiagnostics().hasErrorOccurred()) {
>> +Diag(PointOfInstantiation, diag::warn_func_template_missing)
>> +  << Function << PatternDecl;
>> 
>> Please produce a note pointing at the declaration of the undefined
>> template. With a bit of rewording the diagnostics, I think you can remove
>> the need for the `%qt` format entirely:
>>
>>   warning: instantiation for 'X::f' is required but no
>> definition is available
>> X::f(0.0);
>> ^
>>   note: forward declaration of template entity is here
>> template void f(T);
>>   ^
>>   note: add an explicit instantiation declaration to suppress this
>> warning if 'X::f' is explicitly instantiated in another
>> translation unit
>>
>>
>> If the purpose is to get rid of '%qt', probably the current solution
> (printing template parameters) fits? It seems that decorating templates
> with parameters can improve readability of messages.
>
> After the last changes big part of the patch do not refer to undefined
> templates directly.
>

My suggested wording said "template entity", which is the (not quite
standard yet) term for a template or class/function/whatever declared
within a template.


> May be it is worth splitting the patch into one that implements printing
> template parameters and another that implements warnings on undefined
> templates?
>
> Thanks,
> --Serge
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D19062: Add functions in ctype.h to builtin function database (Fix)

[Richard Smith via cfe-commits]

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

LGTM too, but please wait for @joerg's review as e had concerns about the 
previous revision.


http://reviews.llvm.org/D19062



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

Re: [PATCH] D16396: Warn if variable cannot be implicitly instantiated

[Richard Smith via cfe-commits]

rsmith added a comment.

I have a lingering concern with this style of formatting, because it risks 
making our diagnostics (more) ambiguous. Consider this:

  template struct X {};
  
  struct T {};
  X xt;

If we give a diagnostic talking about `X`, it's ambiguous whether we're 
referring to the `X` template itself or the concrete type of `xt`. That said, 
the actual diagnostic changes here do look like improvements, particularly 
because the template parameter names we're using are typically in scope at the 
point where we issue the diagnostic (so there is no ambiguity). On the whole, I 
think the risk of ambiguity is less than the benefit here.



Comment at: lib/Sema/SemaTemplateInstantiateDecl.cpp:3611
@@ +3610,3 @@
+  if (AtEndOfTU && !getDiagnostics().hasErrorOccurred()) {
+Diag(PointOfInstantiation, diag::warn_func_template_missing)
+  << Function << PatternDecl;

I would still like this note to be added to the diagnostic.


Comment at: test/OpenMP/parallel_ast_print.cpp:135
@@ -134,3 +134,3 @@
 // CHECK:static T TS;
-// CHECK-NEXT:   #pragma omp threadprivate(S::TS)
+// CHECK-NEXT:   #pragma omp threadprivate(S::TS)
 // CHECK:  };

This looks like an undesirable change. Can you turn off 
`PrintTemplateArguments` by default and turn it on only for `%t` in diagnostics?


http://reviews.llvm.org/D16396



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

Re: [PATCH] D19170: [safestack] Link SafeStack runtime only when not using separate stack segment

[Evgeniy Stepanov via cfe-commits]

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

LGTM


http://reviews.llvm.org/D19170



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

Re: [PATCH] D15509: Suggest missing 'template' for dependent member templates

[Richard Smith via cfe-commits]

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


Comment at: lib/Parse/ParseTemplate.cpp:1233-1240
@@ -1240,1 +1232,10 @@
+
+  SuppressAllDiagnostics S(Diags);
+  GreaterThanIsOperatorScope G(GreaterThanIsOperator, false);
+  TemplateArgList TemplateArgs;
+  if (ParseTemplateArgumentList(TemplateArgs))
+return false;
+
+  // Closing '>'
+  return Tok.is(tok::greater);
 }

This looks wrong: it will parse anything that could be a template argument list 
as a template argument list. In ambiguous cases, we must parse as a `<` 
operator.


Comment at: test/SemaTemplate/dependent-template-recover.cpp:14-15
@@ -13,5 +13,4 @@
 
-// FIXME: We can't recover from these yet
-(*t).f2(); // expected-error{{expected expression}}
-(*t).f2<0>(); // expected-error{{expected expression}}
+(*t).f2(); // expected-error{{use 'template' keyword to treat 'f2' as a 
dependent template name}}
+(*t).f2<0>(); // expected-error{{use 'template' keyword to treat 'f2' as a 
dependent template name}}
   }

I think you will incorrectly treat

(*t).f2<0>(0);

... as a dependent template name. Instead, it's required to be parsed as

  ((*t.f2) < 0) > 0;


Comment at: test/SemaTemplate/dependent-template-recover.cpp:35
@@ +34,3 @@
+  s.foo<1>(); // expected-error{{use 'template' keyword to treat 'foo' as a 
dependent template name}}
+  s.foo<1>(0); // expected-error{{use 'template' keyword to treat 'foo' as a 
dependent template name}}
+}

This diagnostic is incorrect.


http://reviews.llvm.org/D15509



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

Re: [PATCH] D19170: [safestack] Link SafeStack runtime only when not using separate stack segment

[Michael LeMay via cfe-commits]

mlemay-intel updated this revision to Diff 53956.
mlemay-intel added a comment.

Add test.


http://reviews.llvm.org/D19170

Files:
  lib/Driver/Tools.cpp
  test/Driver/sanitizer-ld.c

Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -347,6 +347,15 @@
 // CHECK-SAFESTACK-LINUX: "-lpthread"
 // CHECK-SAFESTACK-LINUX: "-ldl"
 
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target i386-unknown-linux -fsanitize=safe-stack \
+// RUN: -mseparate-stack-seg \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-SAFESTACK-LINUX-SEP-STK %s
+//
+// CHECK-SAFESTACK-LINUX-SEP-STK: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-SAFESTACK-LINUX-SEP-STK-NOT: libclang_rt.safestack-i386.a"
+
 // RUN: %clang -fsanitize=cfi -fsanitize-stats %s -### -o %t.o 2>&1 \
 // RUN: -target x86_64-unknown-linux \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -2993,7 +2993,9 @@
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("ubsan_standalone_cxx");
   }
-  if (SanArgs.needsSafeStackRt())
+  // Using a separate stack segment with SafeStack requires more extensive
+  // runtime support than this provides.
+  if (SanArgs.needsSafeStackRt() && 
!Args.hasArg(options::OPT_mseparate_stack_seg))
 StaticRuntimes.push_back("safestack");
   if (SanArgs.needsCfiRt())
 StaticRuntimes.push_back("cfi");


Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -347,6 +347,15 @@
 // CHECK-SAFESTACK-LINUX: "-lpthread"
 // CHECK-SAFESTACK-LINUX: "-ldl"
 
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target i386-unknown-linux -fsanitize=safe-stack \
+// RUN: -mseparate-stack-seg \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-SAFESTACK-LINUX-SEP-STK %s
+//
+// CHECK-SAFESTACK-LINUX-SEP-STK: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-SAFESTACK-LINUX-SEP-STK-NOT: libclang_rt.safestack-i386.a"
+
 // RUN: %clang -fsanitize=cfi -fsanitize-stats %s -### -o %t.o 2>&1 \
 // RUN: -target x86_64-unknown-linux \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -2993,7 +2993,9 @@
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("ubsan_standalone_cxx");
   }
-  if (SanArgs.needsSafeStackRt())
+  // Using a separate stack segment with SafeStack requires more extensive
+  // runtime support than this provides.
+  if (SanArgs.needsSafeStackRt() && !Args.hasArg(options::OPT_mseparate_stack_seg))
 StaticRuntimes.push_back("safestack");
   if (SanArgs.needsCfiRt())
 StaticRuntimes.push_back("cfi");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D19180: [CUDA] Raise an error if the CUDA install can't be found.

[Justin Lebar via cfe-commits]

jlebar created this revision.
jlebar added a reviewer: tra.
jlebar added a subscriber: cfe-commits.

Without this change, we silently proceed on without including
__clang_cuda_runtime_wrapper.h.  This leads to very strange behavior --
you say you're compiling CUDA code, but e.g. __device__ is not defined!

http://reviews.llvm.org/D19180

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  lib/Driver/ToolChains.cpp

Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -4118,11 +4118,14 @@
   if (DriverArgs.hasArg(options::OPT_nocudainc))
 return;
 
-  if (CudaInstallation.isValid()) {
-addSystemInclude(DriverArgs, CC1Args, CudaInstallation.getIncludePath());
-CC1Args.push_back("-include");
-CC1Args.push_back("__clang_cuda_runtime_wrapper.h");
+  if (!CudaInstallation.isValid()) {
+getDriver().Diag(diag::err_drv_no_cuda_installation);
+return;
   }
+
+  addSystemInclude(DriverArgs, CC1Args, CudaInstallation.getIncludePath());
+  CC1Args.push_back("-include");
+  CC1Args.push_back("__clang_cuda_runtime_wrapper.h");
 }
 
 bool Linux::isPIEDefault() const { return getSanitizerArgs().requiresPIE(); }
Index: include/clang/Basic/DiagnosticDriverKinds.td
===
--- include/clang/Basic/DiagnosticDriverKinds.td
+++ include/clang/Basic/DiagnosticDriverKinds.td
@@ -23,6 +23,9 @@
 def err_drv_invalid_arch_name : Error<
   "invalid arch name '%0'">;
 def err_drv_cuda_bad_gpu_arch : Error<"Unsupported CUDA gpu architecture: %0">;
+def err_drv_no_cuda_installation : Error<
+  "cannot find CUDA installation.  Provide its path via --cuda-path, or pass "
+  "-nocudainc to build without CUDA includes.">;
 def err_drv_invalid_thread_model_for_target : Error<
   "invalid thread model '%0' in '%1' for this target">;
 def err_drv_invalid_linker_name : Error<


Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -4118,11 +4118,14 @@
   if (DriverArgs.hasArg(options::OPT_nocudainc))
 return;
 
-  if (CudaInstallation.isValid()) {
-addSystemInclude(DriverArgs, CC1Args, CudaInstallation.getIncludePath());
-CC1Args.push_back("-include");
-CC1Args.push_back("__clang_cuda_runtime_wrapper.h");
+  if (!CudaInstallation.isValid()) {
+getDriver().Diag(diag::err_drv_no_cuda_installation);
+return;
   }
+
+  addSystemInclude(DriverArgs, CC1Args, CudaInstallation.getIncludePath());
+  CC1Args.push_back("-include");
+  CC1Args.push_back("__clang_cuda_runtime_wrapper.h");
 }
 
 bool Linux::isPIEDefault() const { return getSanitizerArgs().requiresPIE(); }
Index: include/clang/Basic/DiagnosticDriverKinds.td
===
--- include/clang/Basic/DiagnosticDriverKinds.td
+++ include/clang/Basic/DiagnosticDriverKinds.td
@@ -23,6 +23,9 @@
 def err_drv_invalid_arch_name : Error<
   "invalid arch name '%0'">;
 def err_drv_cuda_bad_gpu_arch : Error<"Unsupported CUDA gpu architecture: %0">;
+def err_drv_no_cuda_installation : Error<
+  "cannot find CUDA installation.  Provide its path via --cuda-path, or pass "
+  "-nocudainc to build without CUDA includes.">;
 def err_drv_invalid_thread_model_for_target : Error<
   "invalid thread model '%0' in '%1' for this target">;
 def err_drv_invalid_linker_name : Error<
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D19170: [safestack] Link SafeStack runtime only when not using separate stack segment

[Michael LeMay via cfe-commits]

mlemay-intel added a comment.

In http://reviews.llvm.org/D19170#402861, @eugenis wrote:

> Test, please.


Do you know of any examples of the sort of test that you would like to see for 
a feature like this?

> Where is this runtime support implemented? Some platform's libc, or an 
> external library?


In my experience, supporting a separate stack segment seems to require a 
modified libc.  The whole program, including libc routines, needs to be 
recompiled to direct memory accesses to the appropriate segment.  This requires 
setting up an unsafe stack early enough that those recompiled routines can run 
successfully.


http://reviews.llvm.org/D19170



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

Re: [PATCH] D19170: [safestack] Link SafeStack runtime only when not using separate stack segment

[Evgeniy Stepanov via cfe-commits]

eugenis added a comment.

In http://reviews.llvm.org/D19170#402939, @mlemay-intel wrote:

> In http://reviews.llvm.org/D19170#402861, @eugenis wrote:
>
> > Test, please.
>
>
> Do you know of any examples of the sort of test that you would like to see 
> for a feature like this?


test/Driver/sanitizer-ld.c


http://reviews.llvm.org/D19170



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

Re: [PATCH] D18876: NFC: unify clang / LLVM atomic ordering

[JF Bastien via cfe-commits]

jfb added a comment.

In http://reviews.llvm.org/D18876#399934, @jyknight wrote:

> The large amount of casting to/from integers for AtomicOrderingCABI makes me 
> think that it probably ought not actually be converted to an enum class after 
> all.


Untrusted user input with enums is a problem: you have to range-check before 
casting the int to the enum, with or without enum class, otherwise out-of-range 
is UB. I like it being explicit, but yeah what I had was wordy so I factored 
out the check.

Casting *out* of the enum to generate constants is also wordy, but I think 
that's also fine. We could add a version of `ConstantInt` which takes in 
`is_integral_or_enum` but that seems like a lot of work for little typing? I'm 
happy to do that if you think it's worthwhile.


http://reviews.llvm.org/D18876



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

Re: [PATCH] D19175: Fix for PR27015 (variable template initialized with a generic lambda expression)

[Richard Smith via cfe-commits]

rsmith added inline comments.


Comment at: lib/Sema/SemaTemplateInstantiateDecl.cpp:3899-3901
@@ -3898,5 +3898,5 @@
 // Instantiate the initializer.
 ExprResult Init =
 SubstInitializer(OldVar->getInit(), TemplateArgs,
- OldVar->getInitStyle() == VarDecl::CallInit);
+ OldVar->getInitStyle() == VarDecl::CallInit, Var);
 if (!Init.isInvalid()) {

Instead of the other changes, switch `CurContext` to the context of the 
variable template here:

Sema::ContextRAII SwitchContext(*this, Var->getDeclContext());


http://reviews.llvm.org/D19175



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

[PATCH] D19175: Fix for PR27015 (variable template initialized with a generic lambda expression)

[Akira Hatanaka via cfe-commits]

ahatanak created this revision.
ahatanak added a reviewer: rsmith.
ahatanak added a subscriber: cfe-commits.

I'm sending a WIP patch which fixes PR27015 to get an early feedback from the 
community.

This patch attempts to fix a crash which happens when a variable template is 
initialized with a generic lambda expression. Please see the example in the 
email I sent to cfe-dev:

http://lists.llvm.org/pipermail/cfe-dev/2016-April/048391.html

This patch makes changes to ensure the instantiated lambda class (which is the 
lambda class for fn in the example) gets the right parent DeclContex 
(which is Decl::TranslationUnit in the example). After applying this patch, 
clang no longer crash compiling the example program. However, it still crashes 
when it compiles the following code:

$ cat test0.cpp
template  auto fn = [] {};
template  void fn1() { fn; }

$ clang -std=c++14 -c -o /dev/null  test0.cpp 

Assertion failed: (isDependentContext() && "cannot iterate dependent 
diagnostics of non-dependent context"), function ddiags, file 
include/clang/AST/DependentDiagnostic.h, line 176.
...
10 clang-3.80x00010b4afd18 
clang::Sema::PerformDependentDiagnostics(clang::DeclContext const*, 
clang::MultiLevelTemplateArgumentList const&) + 40
11 clang-3.80x00010b46ee1b (anonymous 
namespace)::TemplateInstantiator::transformedLocalDecl(clang::Decl*, 
clang::Decl*) + 251

It fails when DeclContext::ddiags() is called on the lambda class of the old 
lambda expression because it's not a dependent context.

http://reviews.llvm.org/D19175

Files:
  include/clang/Sema/Sema.h
  lib/Sema/SemaLambda.cpp
  lib/Sema/SemaTemplateInstantiate.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/TreeTransform.h

Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -118,9 +118,13 @@
   /// rather than in the subclass (e.g., lambda closure types).
   llvm::DenseMap TransformedLocalDecls;
 
+  /// If not null, this is the variable being initialized.
+  VarDecl *VarInit;
+
 public:
   /// \brief Initializes a new tree transformer.
-  TreeTransform(Sema &SemaRef) : SemaRef(SemaRef) { }
+  TreeTransform(Sema &SemaRef, VarDecl *Var = nullptr)
+  : SemaRef(SemaRef), VarInit(Var) {}
 
   /// \brief Retrieves a reference to the derived class.
   Derived &getDerived() { return static_cast(*this); }
@@ -10043,11 +10047,18 @@
   LSI->GLTemplateParameterList = TPL;
 
   // Create the local class that will describe the lambda.
+  // If the new lambda is used to initialize a variable template specialization,
+  // use the old lambda's DeclContext.
+  DeclContext *DC = nullptr;
+
+  if (VarInit && isa(VarInit))
+DC = E->getLambdaClass()->getParent();
+
   CXXRecordDecl *Class
 = getSema().createLambdaClosureType(E->getIntroducerRange(),
 NewCallOpTSI,
 /*KnownDependent=*/false,
-E->getCaptureDefault());
+E->getCaptureDefault(), DC);
   getDerived().transformedLocalDecl(E->getLambdaClass(), Class);
 
   // Build the call operator.
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -3898,7 +3898,7 @@
 // Instantiate the initializer.
 ExprResult Init =
 SubstInitializer(OldVar->getInit(), TemplateArgs,
- OldVar->getInitStyle() == VarDecl::CallInit);
+ OldVar->getInitStyle() == VarDecl::CallInit, Var);
 if (!Init.isInvalid()) {
   bool TypeMayContainAuto = true;
   Expr *InitExpr = Init.get();
Index: lib/Sema/SemaTemplateInstantiate.cpp
===
--- lib/Sema/SemaTemplateInstantiate.cpp
+++ lib/Sema/SemaTemplateInstantiate.cpp
@@ -633,8 +633,8 @@
 TemplateInstantiator(Sema &SemaRef,
  const MultiLevelTemplateArgumentList &TemplateArgs,
  SourceLocation Loc,
- DeclarationName Entity)
-  : inherited(SemaRef), TemplateArgs(TemplateArgs), Loc(Loc),
+ DeclarationName Entity, VarDecl *VarInit = nullptr)
+  : inherited(SemaRef, VarInit), TemplateArgs(TemplateArgs), Loc(Loc),
 Entity(Entity) { }
 
 /// \brief Determine whether the given type \p T has already been
@@ -2665,10 +2665,10 @@
 
 ExprResult Sema::SubstInitializer(Expr *Init,
   const MultiLevelTemplateArgumentList &TemplateArgs,
-  bool CXXDirectInit) {
+  bool CXXDirectInit, VarDecl *VarInit) {
   TemplateInstantiator Instantiator(*this, TemplateArgs,
 SourceLocation(),
-

Re: [PATCH] D19144: Handle TemplateArgument in DynTypedNode comparison operations.

[Samuel Benzaquen via cfe-commits]

sbenza added a comment.

To be more specific, the problem comes from the use of `hasAnscestor` (done by 
`isInTemplateInstantiation` ) while there is a `TemplateArgument` in the bound 
nodes.
This tries to put the node into the cache.
To trigger this easily you only need to have a hit in the cache.
I think you can trigger it by adding a second line 
`boost::lexical_cast(42);` in the `string_as_T` test. That second 
hit should get a cache hit and trigger the bug.


http://reviews.llvm.org/D19144



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

Re: [PATCH] D19170: [safestack] Link SafeStack runtime only when not using separate stack segment

[Evgeniy Stepanov via cfe-commits]

eugenis added a comment.

Test, please.
Where is this runtime support implemented? Some platform's libc, or an external 
library?


http://reviews.llvm.org/D19170



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

Re: [PATCH] D19144: Handle TemplateArgument in DynTypedNode comparison operations.

[Samuel Benzaquen via cfe-commits]

sbenza added a comment.

I think the bug is coming from `memoizedMatchesAncestorOfRecursively`.
`memoizedMatchesRecursively` has a special case at the top to skip the cache if 
the node is not sortable. The other function should do that too.
Although the check is stale also because it is only checking for 
memoizationData and not whether the node itself works for < and ==.

Note that adding TemplateArgument to the function is ok, but that won't fix the 
bug because we still have other nodes that are not comparable.



Comment at: include/clang/AST/ASTTypeTraits.h:269
@@ -268,3 +268,3 @@
   ///
   /// Supports comparison of nodes that support memoization.
   /// FIXME: Implement comparsion for other node types (currently

this comment is stale.


http://reviews.llvm.org/D19144



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

Re: [PATCH] D18876: NFC: unify clang / LLVM atomic ordering

[JF Bastien via cfe-commits]

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

- Use validity checks, reduce casting while still avoiding UB on out-of-range 
enum values.


http://reviews.llvm.org/D18876

Files:
  include/clang/AST/Expr.h
  lib/CodeGen/CGAtomic.cpp
  lib/Sema/SemaChecking.cpp

Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -1791,26 +1791,26 @@
 }
 
 static bool isValidOrderingForOp(int64_t Ordering, AtomicExpr::AtomicOp Op) {
-  if (Ordering < AtomicExpr::AO_ABI_memory_order_relaxed ||
-  Ordering > AtomicExpr::AO_ABI_memory_order_seq_cst)
+  if (!llvm::isValidAtomicOrderingCABI(Ordering))
 return false;
 
+  auto OrderingCABI = (llvm::AtomicOrderingCABI)Ordering;
   switch (Op) {
   case AtomicExpr::AO__c11_atomic_init:
 llvm_unreachable("There is no ordering argument for an init");
 
   case AtomicExpr::AO__c11_atomic_load:
   case AtomicExpr::AO__atomic_load_n:
   case AtomicExpr::AO__atomic_load:
-return Ordering != AtomicExpr::AO_ABI_memory_order_release &&
-   Ordering != AtomicExpr::AO_ABI_memory_order_acq_rel;
+return OrderingCABI != llvm::AtomicOrderingCABI::release &&
+   OrderingCABI != llvm::AtomicOrderingCABI::acq_rel;
 
   case AtomicExpr::AO__c11_atomic_store:
   case AtomicExpr::AO__atomic_store:
   case AtomicExpr::AO__atomic_store_n:
-return Ordering != AtomicExpr::AO_ABI_memory_order_consume &&
-   Ordering != AtomicExpr::AO_ABI_memory_order_acquire &&
-   Ordering != AtomicExpr::AO_ABI_memory_order_acq_rel;
+return OrderingCABI != llvm::AtomicOrderingCABI::consume &&
+   OrderingCABI != llvm::AtomicOrderingCABI::acquire &&
+   OrderingCABI != llvm::AtomicOrderingCABI::acq_rel;
 
   default:
 return true;
Index: lib/CodeGen/CGAtomic.cpp
===
--- lib/CodeGen/CGAtomic.cpp
+++ lib/CodeGen/CGAtomic.cpp
@@ -243,11 +243,6 @@
 /// Materialize an atomic r-value in atomic-layout memory.
 Address materializeRValue(RValue rvalue) const;
 
-/// \brief Translates LLVM atomic ordering to GNU atomic ordering for
-/// libcalls.
-static AtomicExpr::AtomicOrderingKind
-translateAtomicOrdering(const llvm::AtomicOrdering AO);
-
 /// \brief Creates temp alloca for intermediate operations on atomic value.
 Address CreateTempAlloca() const;
   private:
@@ -292,25 +287,6 @@
   };
 }
 
-AtomicExpr::AtomicOrderingKind
-AtomicInfo::translateAtomicOrdering(const llvm::AtomicOrdering AO) {
-  switch (AO) {
-  case llvm::AtomicOrdering::Unordered:
-  case llvm::AtomicOrdering::NotAtomic:
-  case llvm::AtomicOrdering::Monotonic:
-return AtomicExpr::AO_ABI_memory_order_relaxed;
-  case llvm::AtomicOrdering::Acquire:
-return AtomicExpr::AO_ABI_memory_order_acquire;
-  case llvm::AtomicOrdering::Release:
-return AtomicExpr::AO_ABI_memory_order_release;
-  case llvm::AtomicOrdering::AcquireRelease:
-return AtomicExpr::AO_ABI_memory_order_acq_rel;
-  case llvm::AtomicOrdering::SequentiallyConsistent:
-return AtomicExpr::AO_ABI_memory_order_seq_cst;
-  }
-  llvm_unreachable("Unhandled AtomicOrdering");
-}
-
 Address AtomicInfo::CreateTempAlloca() const {
   Address TempAlloca = CGF.CreateMemTemp(
   (LVal.isBitField() && ValueSizeInBits > AtomicSizeInBits) ? ValueTy
@@ -427,34 +403,39 @@
 /// instructions to cope with the provided (but possibly only dynamically known)
 /// FailureOrder.
 static void emitAtomicCmpXchgFailureSet(CodeGenFunction &CGF, AtomicExpr *E,
-bool IsWeak, Address Dest,
-Address Ptr, Address Val1,
-Address Val2,
+bool IsWeak, Address Dest, Address Ptr,
+Address Val1, Address Val2,
 llvm::Value *FailureOrderVal,
 uint64_t Size,
 llvm::AtomicOrdering SuccessOrder) {
   llvm::AtomicOrdering FailureOrder;
   if (llvm::ConstantInt *FO = dyn_cast(FailureOrderVal)) {
-switch (FO->getSExtValue()) {
-default:
+auto FOS = FO->getSExtValue();
+if (!llvm::isValidAtomicOrderingCABI(FOS))
   FailureOrder = llvm::AtomicOrdering::Monotonic;
-  break;
-case AtomicExpr::AO_ABI_memory_order_consume:
-case AtomicExpr::AO_ABI_memory_order_acquire:
-  FailureOrder = llvm::AtomicOrdering::Acquire;
-  break;
-case AtomicExpr::AO_ABI_memory_order_seq_cst:
-  FailureOrder = llvm::AtomicOrdering::SequentiallyConsistent;
-  break;
-}
+else
+  switch ((llvm::AtomicOrderingCABI)FOS) {
+  case llvm::AtomicOrderingCABI::relaxed:
+  case llvm::AtomicOrderingCABI::release:
+  case llvm::AtomicOrderingCABI::acq_rel:
+FailureOrder 

Buildbot numbers for the week of 4/03/2016 - 4/09/2016

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 4/03/2016 - 4/09/2016.

Thanks

Galina


"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green):

 buildername| builds |
changes | status change ratio
++-+-
 clang-ppc64le-linux-lnt| 72 |
40 |55.6
 perf-x86_64-penryn-O3-polly| 52 |
27 |51.9
 lldb-x86_64-darwin-13.4|102 |
30 |29.4
 clang-x64-ninja-win7   |153 |
32 |20.9
 clang-cmake-aarch64-full   | 48 |
10 |20.8
 clang-x86-win2008-selfhost |103 |
20 |19.4
 clang-cmake-mips   | 83 |
16 |19.3
 clang-cmake-thumbv7-a15-full-sh| 21
|   4 |19.0
 clang-cmake-armv7-a15-selfhost | 32
|   6 |18.8
 clang-cmake-aarch64-quick  |153 |
28 |18.3
 clang-cmake-armv7-a15  |134 |
22 |16.4
 clang-cmake-aarch64-42vma  |139 |
22 |15.8
 clang-ppc64be-linux-multistage |114 |
18 |15.8
 clang-cmake-thumbv7-a15|149 |
22 |14.8
 perf-x86_64-penryn-O3-polly-before-vectorizer  | 14
|   2 |14.3
 lldb-x86_64-ubuntu-14.04-cmake |249 |
34 |13.7
 llvm-mips-linux| 59
|   8 |13.6
 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only  | 15
|   2 |13.3
 lldb-windows7-android  | 77 |
10 |13.0
 clang-cmake-armv7-a15-full | 79 |
10 |12.7
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast   |308 |
39 |12.7
 clang-ppc64le-linux|173 |
22 |12.7
 clang-ppc64be-linux-lnt|208 |
26 |12.5
 sanitizer-x86_64-linux | 97 |
12 |12.4
 sanitizer-x86_64-linux-fast|157 |
17 |10.8
 clang-cmake-mipsel | 19
|   2 |10.5
 lldb-x86_64-ubuntu-14.04-android   | 98 |
10 |10.2
 clang-ppc64be-linux|258 |
26 |10.1
 clang-x86_64-debian-fast   |120 |
12 |10.0
 llvm-clang-lld-x86_64-debian-fast  |145 |
14 | 9.7
 clang-cmake-armv7-a15-selfhost-neon| 23
|   2 | 8.7
 clang-atom-d525-fedora-rel | 71
|   6 | 8.5
 clang-s390x-linux  |258 |
20 | 7.8
 lldb-x86_64-ubuntu-14.04-buildserver   |131
|   9 | 6.9
 sanitizer-ppc64be-linux| 90
|   6 | 6.7
 sanitizer-windows  |332 |
22 | 6.6
 sanitizer-ppc64le-linux| 46
|   3 | 6.5
 lld-x86_64-darwin13|284 |
18 | 6.3
 lldb-x86-windows-msvc2015  |163 |
10 | 6.1
 sanitizer-x86_64-linux-bootstrap   | 53
|   3 | 5.7
 clang-bpf-build|286 |
16 | 5.6
 clang-hexagon-elf  |293 |
16 | 5.5
 lld-x86_64-win7|321 |
17 | 5.3
 lldb-amd64-ninja-netbsd7   |133
|   6 | 4.5
 lld-x86_64-freebsd |181
|   8 | 4.4
 llvm-hexagon-elf   |244 |
10 | 4.1
 perf-x86_64-penryn-O3  | 

[clang-tools-extra] r266463 - [clang-tidy] Add more detection rules for redundant c_str calls.

[Etienne Bergeron via cfe-commits]

Author: etienneb
Date: Fri Apr 15 13:12:06 2016
New Revision: 266463

URL: http://llvm.org/viewvc/llvm-project?rev=266463&view=rev
Log:
[clang-tidy] Add more detection rules for redundant c_str calls.

Summary:
The string class contains methods which support receiving either a string 
literal or a string object.

For example, calls to append can receive either a char* or a string.
```
  string& append (const string& str);
  string& append (const char* s);
```

Which make these cases equivalent, and the .c_str() useless:
```
  std::string s = "123";
  str.append(s);
  str.append(s.c_str());
```

In these cases, removing .c_str()  doesn't provide any size or speed 
improvement.
It's only a readability issue.

If the string contains embedded NUL characters,  the string literal and the 
string
object won't produce the same semantic.

Reviewers: alexfh, sbenza

Subscribers: LegalizeAdulthood, aaron.ballman, chapuni, Eugene.Zelenko, 
cfe-commits

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

Modified:
clang-tools-extra/trunk/clang-tidy/readability/RedundantStringCStrCheck.cpp

clang-tools-extra/trunk/test/clang-tidy/readability-redundant-string-cstr.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/RedundantStringCStrCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/RedundantStringCStrCheck.cpp?rev=266463&r1=266462&r2=266463&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/RedundantStringCStrCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/RedundantStringCStrCheck.cpp 
Fri Apr 15 13:12:06 2016
@@ -103,11 +103,74 @@ void RedundantStringCStrCheck::registerM
 callee(cxxMethodDecl(hasName("c_str"
   .bind("call");
 
+  // Detect redundant 'c_str()' calls through a string constructor.
   Finder->addMatcher(
   cxxConstructExpr(StringConstructorExpr,
hasArgument(0, StringCStrCallExpr)),
   this);
 
+  // Detect: 's == str.c_str()'  ->  's == str'
+  Finder->addMatcher(
+  cxxOperatorCallExpr(
+  anyOf(hasOverloadedOperatorName("<"),
+hasOverloadedOperatorName(">"),
+hasOverloadedOperatorName(">="),
+hasOverloadedOperatorName("<="),
+hasOverloadedOperatorName("!="),
+hasOverloadedOperatorName("=="),
+hasOverloadedOperatorName("+")),
+  anyOf(allOf(hasArgument(0, StringExpr),
+  hasArgument(1, StringCStrCallExpr)),
+allOf(hasArgument(0, StringCStrCallExpr),
+  hasArgument(1, StringExpr,
+  this);
+
+  // Detect: 'dst += str.c_str()'  ->  'dst += str'
+  // Detect: 's = str.c_str()'  ->  's = str'
+  Finder->addMatcher(
+  cxxOperatorCallExpr(
+  anyOf(hasOverloadedOperatorName("="),
+hasOverloadedOperatorName("+=")),
+  hasArgument(0, StringExpr),
+  hasArgument(1, StringCStrCallExpr)),
+  this);
+
+  // Detect: 'dst.append(str.c_str())'  ->  'dst.append(str)'
+  Finder->addMatcher(
+  cxxMemberCallExpr(on(StringExpr),
+  callee(decl(cxxMethodDecl(
+  hasAnyName("append", "assign", "compare",
+  argumentCountIs(1),
+  hasArgument(0, StringCStrCallExpr)),
+  this);
+
+  // Detect: 'dst.compare(p, n, str.c_str())'  ->  'dst.compare(p, n, str)'
+  Finder->addMatcher(
+  cxxMemberCallExpr(on(StringExpr),
+  callee(decl(cxxMethodDecl(hasName("compare",
+  argumentCountIs(3),
+  hasArgument(2, StringCStrCallExpr)),
+  this);
+
+  // Detect: 'dst.find(str.c_str())'  ->  'dst.find(str)'
+  Finder->addMatcher(
+  cxxMemberCallExpr(on(StringExpr),
+  callee(decl(cxxMethodDecl(
+  hasAnyName("find", "find_first_not_of", "find_first_of",
+ "find_last_not_of", "find_last_of", "rfind",
+  anyOf(argumentCountIs(1), argumentCountIs(2)),
+  hasArgument(0, StringCStrCallExpr)),
+  this);
+
+  // Detect: 'dst.insert(pos, str.c_str())'  ->  'dst.insert(pos, str)'
+  Finder->addMatcher(
+  cxxMemberCallExpr(on(StringExpr),
+  callee(decl(cxxMethodDecl(hasName("insert",
+  argumentCountIs(2),
+  hasArgument(1, StringCStrCallExpr)),
+  this);
+
+  // Detect redundant 'c_str()' calls through a StringRef constructor.
   Finder->addMatcher(
   cxxConstructExpr(
   // Implicit constructors of these classes are overloaded
@@ -115,8 +178,8 @@ void RedundantStringCStrCheck::registerM
   // referring to the argument.  Passing a string directly to
   // them is preferred to passing a char pointer.
   hasDeclaration(
-  cxxMethodDecl(anyOf(hasName("::llvm::StringRef::StringRef"),
-  hasName("::llvm::Twine

Re: [PATCH] D12761: MPI-Checker patch for Clang Static Analyzer

[Alexander Droste via cfe-commits]

Alexander_Droste added inline comments.


Comment at: lib/StaticAnalyzer/Checkers/MPI-Checker/MPIBugReporter.cpp:96
@@ +95,3 @@
+if (const CallExpr *CE = clang::dyn_cast(SP->getStmt())) {
+
+  auto FuncIdentifier = CE->getDirectCallee()->getIdentifier();

zaks.anna wrote:
> The advantage of using the state is that it will be much more robust to any 
> further changes to the compiler/checker because you will not be pattern 
> matching the AST but instead will be checking the state, which the core 
> reasoning is based on. One example that comes to mind is indirect calls. You 
> will reduce the amount of code here as well, simplifying maintainability. 
> This is the pattern we use in other checkers as well, so there is a remote 
> chance we could introduce a new simplified API that will do the walk for the 
> checker writers.
> 
> With respect to your example. Does it come up in practice? Wouldn't you warn 
> on the second nonblocking request anyway? Could you add such an example to 
> the tests? (Would be good in any case. If you leave the code as is, you can 
> point to that example as the motivation.)
I'll change this to the pattern you suggested.

>With respect to your example. Does it come up in practice?
It's for sure a little contrived.
>Wouldn't you warn on the second nonblocking request anyway? 
Yes.
>Could you add such an example to the tests? 
Sure.


http://reviews.llvm.org/D12761



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

[libcxx] r266461 - Cleanup and guard tuple's constructor SFINAE. Fixes PR22806 and PR23256.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Fri Apr 15 13:05:59 2016
New Revision: 266461

URL: http://llvm.org/viewvc/llvm-project?rev=266461&view=rev
Log:
Cleanup and guard tuple's constructor SFINAE.  Fixes PR22806 and PR23256.

There are two main fixes in this patch.

First the constructor SFINAE was changed so that it's evaluated in two stages
where the first stage evaluates the "safe" SFINAE conditions and the second
evaluates the "dangerous" ones. The key is that the second stage is lazily
evaluated only if the first stage passes. This helps fix PR23256
(https://llvm.org/bugs/show_bug.cgi?id=23256).

The second fix is for PR22806 and LWG issue 2549. This fix applies
the suggested resolution to the LWG issue in order to prevent the construction
of dangling references. The SFINAE for this check is contained within
the _PreferTupleLikeConstructor alias template. The tuple-like constructors
are disabled whenever that trait returns false.

(https://llvm.org/bugs/show_bug.cgi?id=22806)
(http://cplusplus.github.io/LWG/lwg-active.html#2549)

Added:

libcxx/trunk/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/PR22806_constrain_tuple_like_ctor.pass.cpp

libcxx/trunk/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/PR23256_constrain_UTypes_ctor.pass.cpp
Modified:
libcxx/trunk/include/tuple
libcxx/trunk/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/move.pass.cpp

Modified: libcxx/trunk/include/tuple
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/tuple?rev=266461&r1=266460&r2=266461&view=diff
==
--- libcxx/trunk/include/tuple (original)
+++ libcxx/trunk/include/tuple Fri Apr 15 13:05:59 2016
@@ -502,6 +502,28 @@ struct __tuple_impl<__tuple_indices<_Ind
 }
 };
 
+template 
+struct __tuple_like_with_size_imp : false_type {};
+
+template 
+struct __tuple_like_with_size_imp
+: integral_constant {};
+
+template ::type>
+using __tuple_like_with_size = __tuple_like_with_size_imp<
+   __tuple_like<_RawTuple>::value,
+   tuple_size<_RawTuple>, _ExpectedSize
+  >;
+
+
+struct _LIBCPP_TYPE_VIS __check_tuple_constructor_fail {
+template 
+static constexpr bool __enable_explicit() { return false; }
+template 
+static constexpr bool __enable_implicit() { return false; }
+};
+
 template 
 class _LIBCPP_TYPE_VIS_ONLY tuple
 {
@@ -509,6 +531,118 @@ class _LIBCPP_TYPE_VIS_ONLY tuple
 
 base base_;
 
+template 
+struct _PackExpandsToThisTuple : false_type {};
+
+template 
+struct _PackExpandsToThisTuple<_Arg>
+: is_same::type, tuple> {};
+
+template 
+struct _CheckArgsConstructor : __check_tuple_constructor_fail {};
+
+template 
+struct _CheckArgsConstructor
+{
+template 
+static constexpr bool __enable_explicit() {
+return
+__tuple_constructible<
+tuple<_Args...>,
+typename __make_tuple_types::type
+>::value &&
+!__tuple_convertible<
+tuple<_Args...>,
+typename __make_tuple_types::type
+>::value &&
+__all_default_constructible<
+typename __make_tuple_types::type
+>::value;
+}
+
+template 
+static constexpr bool __enable_implicit() {
+return
+__tuple_convertible<
+tuple<_Args...>,
+typename __make_tuple_types::type
+>::value &&
+__all_default_constructible<
+typename __make_tuple_types::type
+>::value;
+}
+};
+
+template 
+struct _CheckTupleLikeConstructor : __check_tuple_constructor_fail {};
+
+template 
+struct _CheckTupleLikeConstructor
+{
+template 
+static constexpr bool __enable_implicit() {
+return __tuple_convertible<_Tuple, tuple>::value;
+}
+
+template 
+static constexpr bool __enable_explicit() {
+return __tuple_constructible<_Tuple, tuple>::value
+   && !__tuple_convertible<_Tuple, tuple>::value;
+}
+};
+
+template 
+struct _CheckTupleLikeConstructor
+{
+// This trait is used to disable the tuple-like constructor when
+// the UTypes... constructor should be selected instead.
+// See LWG issue #2549.
+template 
+using _PreferTupleLikeConstructor = __lazy_or<
+// Don't attempt the two checks below if the tuple we are given
+// has the same type as this tuple.
+is_same::type, tuple>,
+__lazy_and<
+__lazy_not>,
+__lazy_not>
+>
+>;
+
+template 
+static constexpr bool __enable_implicit() {
+return __lazy_

r266460 - Revert 266186 as it breaks anything that includes type_traits on some platforms

[Nemanja Ivanovic via cfe-commits]

Author: nemanjai
Date: Fri Apr 15 13:04:13 2016
New Revision: 266460

URL: http://llvm.org/viewvc/llvm-project?rev=266460&view=rev
Log:
Revert 266186 as it breaks anything that includes type_traits on some platforms

Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).

Removed:
cfe/trunk/test/CodeGenCXX/float128-declarations.cpp
cfe/trunk/test/Sema/float128-ld-incompatibility.cpp
Modified:
cfe/trunk/bindings/python/clang/cindex.py
cfe/trunk/include/clang-c/Index.h
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/AST/BuiltinTypes.def
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/AST/TypeLoc.h
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Basic/Specifiers.h
cfe/trunk/include/clang/Basic/TargetInfo.h
cfe/trunk/include/clang/Basic/TokenKinds.def
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Lex/LiteralSupport.h
cfe/trunk/include/clang/Sema/DeclSpec.h
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/lib/AST/NSAPI.cpp
cfe/trunk/lib/AST/StmtPrinter.cpp
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/AST/TypeLoc.cpp
cfe/trunk/lib/Analysis/PrintfFormatString.cpp
cfe/trunk/lib/Basic/TargetInfo.cpp
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGExprScalar.cpp
cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/lib/Format/FormatToken.cpp
cfe/trunk/lib/Index/USRGeneration.cpp
cfe/trunk/lib/Lex/LiteralSupport.cpp
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Parse/ParseExpr.cpp
cfe/trunk/lib/Parse/ParseExprCXX.cpp
cfe/trunk/lib/Parse/ParseTentative.cpp
cfe/trunk/lib/Sema/DeclSpec.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaLookup.cpp
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/lib/Sema/SemaTemplateVariadic.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/lib/Serialization/ASTCommon.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/test/Preprocessor/init.c
cfe/trunk/test/Sema/128bitfloat.cpp
cfe/trunk/test/SemaCXX/deleted-operator.cpp
cfe/trunk/test/SemaCXX/overloaded-builtin-operators.cpp
cfe/trunk/tools/libclang/CXType.cpp

Modified: cfe/trunk/bindings/python/clang/cindex.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/bindings/python/clang/cindex.py?rev=266460&r1=266459&r2=266460&view=diff
==
--- cfe/trunk/bindings/python/clang/cindex.py (original)
+++ cfe/trunk/bindings/python/clang/cindex.py Fri Apr 15 13:04:13 2016
@@ -1685,7 +1685,6 @@ TypeKind.DEPENDENT = TypeKind(26)
 TypeKind.OBJCID = TypeKind(27)
 TypeKind.OBJCCLASS = TypeKind(28)
 TypeKind.OBJCSEL = TypeKind(29)
-TypeKind.FLOAT128 = TypeKind(30)
 TypeKind.COMPLEX = TypeKind(100)
 TypeKind.POINTER = TypeKind(101)
 TypeKind.BLOCKPOINTER = TypeKind(102)

Modified: cfe/trunk/include/clang-c/Index.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang-c/Index.h?rev=266460&r1=266459&r2=266460&view=diff
==
--- cfe/trunk/include/clang-c/Index.h (original)
+++ cfe/trunk/include/clang-c/Index.h Fri Apr 15 13:04:13 2016
@@ -2929,7 +2929,6 @@ enum CXTypeKind {
   CXType_ObjCId = 27,
   CXType_ObjCClass = 28,
   CXType_ObjCSel = 29,
-  CXType_Float128 = 30,
   CXType_FirstBuiltin = CXType_Void,
   CXType_LastBuiltin  = CXType_ObjCSel,
 

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=266460&r1=266459&r2=266460&view=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Fri Apr 15 13:04:13 2016
@@ -893,10 +893,9 @@ public:
   CanQualType SignedCharTy, ShortTy, IntTy, LongTy, LongLongTy, Int128Ty;
   CanQualType UnsignedCharTy, UnsignedShortTy, UnsignedIntTy, UnsignedLongTy;
   CanQualType UnsignedLongLongTy, UnsignedInt128Ty;
-  CanQualType FloatTy, DoubleTy, LongDoubleTy, Float128Ty;
+  CanQualType FloatTy, DoubleTy, LongDoubleTy;
   CanQualType HalfTy; // [OpenCL 6.1.1.1], ARM NEON
   CanQualType FloatComplexTy, DoubleComplexTy, LongDoubleComplexTy;
-  CanQualType Float128ComplexTy;
   CanQualType VoidPtrTy, NullPtrTy;
   CanQualType DependentTy, OverloadTy, Boun

Re: [PATCH] D17092: [X86] Add -mseparate-stack-seg

[Michael LeMay via cfe-commits]

mlemay-intel updated this revision to Diff 53920.
mlemay-intel added a comment.

Revise patch to fix line alignment.


http://reviews.llvm.org/D17092

Files:
  include/clang/Driver/Options.td
  lib/CodeGen/TargetInfo.cpp
  test/CodeGen/varargs.c

Index: test/CodeGen/varargs.c
===
--- test/CodeGen/varargs.c
+++ test/CodeGen/varargs.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple i386-unknown-unknown -emit-llvm -o - %s | FileCheck 
%s
+// RUN: %clang_cc1 -triple i386-unknown-unknown -target-feature 
+separate-stack-seg -emit-llvm -o - %s | FileCheck -check-prefix=SEPARATE-SS %s
 
 // PR6433 - Don't crash on va_arg(typedef).
 typedef double gdouble;
@@ -20,4 +21,5 @@
   __builtin_va_list ap;
   void *p;
   p = __builtin_va_arg(ap, typeof (int (*)[++n])); // CHECK: add nsw i32 
{{.*}}, 1
+  // SEPARATE-SS: load i32*, i32* addrspace(258)* {{.*}}
 }
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -1690,9 +1690,26 @@
   TypeInfo.second = CharUnits::fromQuantity(
 getTypeStackAlignInBytes(Ty, TypeInfo.second.getQuantity()));
 
-  return emitVoidPtrVAArg(CGF, VAListAddr, Ty, /*Indirect*/ false,
-  TypeInfo, CharUnits::fromQuantity(4),
-  /*AllowHigherAlign*/ true);
+  const Address Addr = emitVoidPtrVAArg(CGF, VAListAddr, Ty, /*Indirect*/ 
false,
+TypeInfo, CharUnits::fromQuantity(4),
+/*AllowHigherAlign*/ true);
+
+  const std::vector &TargetFeatures =
+CGF.getTarget().getTargetOpts().Features;
+  if (std::find(TargetFeatures.begin(), TargetFeatures.end(),
+"+separate-stack-seg") != TargetFeatures.end()) {
+// Cast the pointer into the address space for the stack segment.
+// This is to help support multi-segment memory models in which DS and SS
+// may differ from each other.
+llvm::Type *DirectTy = CGF.ConvertTypeForMem(Ty);
+llvm::Value *PtrAsInt =
+  CGF.Builder.CreatePtrToInt(Addr.getPointer(), CGF.IntPtrTy);
+llvm::Value *PtrInStackSeg =
+  CGF.Builder.CreateIntToPtr(PtrAsInt, DirectTy->getPointerTo(258));
+return Address(PtrInStackSeg, Addr.getAlignment());
+  }
+
+  return Addr;
 }
 
 bool X86_32TargetCodeGenInfo::isStructReturnInRegABI(
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1407,6 +1407,7 @@
 def mno_xsavec : Flag<["-"], "mno-xsavec">, Group;
 def mno_xsaves : Flag<["-"], "mno-xsaves">, Group;
 def mno_pku : Flag<["-"], "mno-pku">, Group;
+def mseparate_stack_seg : Flag<["-"], "mseparate-stack-seg">, 
Group;
 
 def munaligned_access : Flag<["-"], "munaligned-access">, 
Group,
   HelpText<"Allow memory accesses to be unaligned (AArch32/AArch64 only)">;


Index: test/CodeGen/varargs.c
===
--- test/CodeGen/varargs.c
+++ test/CodeGen/varargs.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple i386-unknown-unknown -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple i386-unknown-unknown -target-feature +separate-stack-seg -emit-llvm -o - %s | FileCheck -check-prefix=SEPARATE-SS %s
 
 // PR6433 - Don't crash on va_arg(typedef).
 typedef double gdouble;
@@ -20,4 +21,5 @@
   __builtin_va_list ap;
   void *p;
   p = __builtin_va_arg(ap, typeof (int (*)[++n])); // CHECK: add nsw i32 {{.*}}, 1
+  // SEPARATE-SS: load i32*, i32* addrspace(258)* {{.*}}
 }
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -1690,9 +1690,26 @@
   TypeInfo.second = CharUnits::fromQuantity(
 getTypeStackAlignInBytes(Ty, TypeInfo.second.getQuantity()));
 
-  return emitVoidPtrVAArg(CGF, VAListAddr, Ty, /*Indirect*/ false,
-  TypeInfo, CharUnits::fromQuantity(4),
-  /*AllowHigherAlign*/ true);
+  const Address Addr = emitVoidPtrVAArg(CGF, VAListAddr, Ty, /*Indirect*/ false,
+TypeInfo, CharUnits::fromQuantity(4),
+/*AllowHigherAlign*/ true);
+
+  const std::vector &TargetFeatures =
+CGF.getTarget().getTargetOpts().Features;
+  if (std::find(TargetFeatures.begin(), TargetFeatures.end(),
+"+separate-stack-seg") != TargetFeatures.end()) {
+// Cast the pointer into the address space for the stack segment.
+// This is to help support multi-segment memory models in which DS and SS
+// may differ from each other.
+llvm::Type *DirectTy = CGF.ConvertTypeForMem(Ty);
+llvm::Value *PtrAsInt =
+  CGF.Builder.CreatePtrToInt(Addr.getPointer(), CGF.IntPtrTy);
+llvm::Value *

Re: [PATCH] D12761: MPI-Checker patch for Clang Static Analyzer

[Alexander Droste via cfe-commits]

Alexander_Droste added inline comments.


Comment at: test/Analysis/MPIChecker.cpp:99
@@ +98,3 @@
+  MPI_Wait(&req, MPI_STATUS_IGNORE);
+}
+

Alexander_Droste wrote:
> zaks.anna wrote:
> > This are explaining the path on which the problem occurs; the users will 
> > see them as well. There should not be a lot of those, you do not have a lot 
> > of conditions. Would it be reasonable to change the tests to incorporate 
> > those. Other alternative is to have another tests file that tests the notes 
> > in that mode.
> > 
> > What do you think?
> I'm fine with adding the notes to this test file.
I had a look once more how much output this actually produces. If 
`-analyzer-output=text` is passed, 42 notes are missing. I'll add another test 
file which will test for these notes.


http://reviews.llvm.org/D12761



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

Re: r266186 - Enable support for __float128 in Clang

[Nemanja Ivanovic via cfe-commits]

It was not supported before but there was a workaround in Clang. As far as
I recall, it basically "secretly" provided a typedef for __float128
(presumably to long double on most targets). This workaround was in place
precisely to allow these headers to compile.

On Fri, Apr 15, 2016 at 7:58 PM, James Y Knight  wrote:

> I'm confused: why does it break targets if __float128 wasn't supported
> before, and still isn't supported?
>
> Surely enabling float128 support on some targets, and leaving it disabled
> on linux/x86 shouldn't actually *break* linux/x86?
>
> On Fri, Apr 15, 2016 at 11:53 AM, Nemanja Ivanovic via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> I have just pinged the patch to see if I can get it approved today. Can I
>> give it a few hours and if it isn't approved by tonight, I'll revert the
>> other patch?
>>
>> BTW. a temporary workaround for this issue if absolutely required in the
>> next few hours is to comment out the following define in bits/config.h:
>>
>> /* Define if __float128 is supported on this host. */
>> #define _GLIBCXX_USE_FLOAT128 1
>>
>>
>> On Fri, Apr 15, 2016 at 4:14 PM, Nico Weber  wrote:
>>
>>> On Fri, Apr 15, 2016 at 12:27 AM, Hal Finkel  wrote:
>>>
 - Original Message -
 > From: "Hans Wennborg via cfe-commits" 
 > To: "Nemanja Ivanovic" , "Nico Weber" <
 tha...@chromium.org>
 > Cc: "cfe-commits" 
 > Sent: Thursday, April 14, 2016 8:07:58 PM
 > Subject: Re: r266186 - Enable support for __float128 in Clang
 >
 > On Wed, Apr 13, 2016 at 2:49 AM, Nemanja Ivanovic via cfe-commits
 >  wrote:
 > > Author: nemanjai
 > > Date: Wed Apr 13 04:49:45 2016
 > > New Revision: 266186
 > >
 > > URL: http://llvm.org/viewvc/llvm-project?rev=266186&view=rev
 > > Log:
 > > Enable support for __float128 in Clang
 > >
 > > This patch corresponds to review:
 > > http://reviews.llvm.org/D15120
 > >
 > > It adds support for the __float128 keyword, literals and a target
 > > feature to
 > > enable it. This support is disabled by default on all targets and
 > > any target
 > > that has support for this type is free to add it.
 > >
 > > Based on feedback that I've received from target maintainers, this
 > > appears to
 > > be the right thing for most targets. I have not heard from the
 > > maintainers of
 > > X86 which I believe supports this type. I will subsequently
 > > investigate the
 > > impact of enabling this on X86.
 >
 > We're seeing build errors when targeting Android, which I think may
 > be
 > caused by this:
 >
 > [...]
 > In file included from ../../v8/src/base/functional.cc:11:
 > In file included from ../../v8/src/base/functional.h:13:
 > In file included from
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/functional:55:
 > In file included from
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/tuple:38:
 > In file included from
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/utility:70:
 > In file included from
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_pair.h:59:
 > In file included from
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/move.h:57:
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:269:39:
 > error: __float128 is not supported on this target
 > struct __is_floating_point_helper<__float128>
 >   ^
 >
 > (From
 >
 https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng/builds/54128/steps/compile%20%28with%20patch%29/logs/stdio
 )
 >
 > Any idea what might be breaking here?

 Yep, see: http://reviews.llvm.org/D19125
>>>
>>>
>>> Since this is breaking real-world code, is it possible to revert this
>>> until http://reviews.llvm.org/D19125 is ready?
>>>
>>>


  -Hal

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

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

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

Re: r266186 - Enable support for __float128 in Clang

[James Y Knight via cfe-commits]

I'm confused: why does it break targets if __float128 wasn't supported
before, and still isn't supported?

Surely enabling float128 support on some targets, and leaving it disabled
on linux/x86 shouldn't actually *break* linux/x86?

On Fri, Apr 15, 2016 at 11:53 AM, Nemanja Ivanovic via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> I have just pinged the patch to see if I can get it approved today. Can I
> give it a few hours and if it isn't approved by tonight, I'll revert the
> other patch?
>
> BTW. a temporary workaround for this issue if absolutely required in the
> next few hours is to comment out the following define in bits/config.h:
>
> /* Define if __float128 is supported on this host. */
> #define _GLIBCXX_USE_FLOAT128 1
>
>
> On Fri, Apr 15, 2016 at 4:14 PM, Nico Weber  wrote:
>
>> On Fri, Apr 15, 2016 at 12:27 AM, Hal Finkel  wrote:
>>
>>> - Original Message -
>>> > From: "Hans Wennborg via cfe-commits" 
>>> > To: "Nemanja Ivanovic" , "Nico Weber" <
>>> tha...@chromium.org>
>>> > Cc: "cfe-commits" 
>>> > Sent: Thursday, April 14, 2016 8:07:58 PM
>>> > Subject: Re: r266186 - Enable support for __float128 in Clang
>>> >
>>> > On Wed, Apr 13, 2016 at 2:49 AM, Nemanja Ivanovic via cfe-commits
>>> >  wrote:
>>> > > Author: nemanjai
>>> > > Date: Wed Apr 13 04:49:45 2016
>>> > > New Revision: 266186
>>> > >
>>> > > URL: http://llvm.org/viewvc/llvm-project?rev=266186&view=rev
>>> > > Log:
>>> > > Enable support for __float128 in Clang
>>> > >
>>> > > This patch corresponds to review:
>>> > > http://reviews.llvm.org/D15120
>>> > >
>>> > > It adds support for the __float128 keyword, literals and a target
>>> > > feature to
>>> > > enable it. This support is disabled by default on all targets and
>>> > > any target
>>> > > that has support for this type is free to add it.
>>> > >
>>> > > Based on feedback that I've received from target maintainers, this
>>> > > appears to
>>> > > be the right thing for most targets. I have not heard from the
>>> > > maintainers of
>>> > > X86 which I believe supports this type. I will subsequently
>>> > > investigate the
>>> > > impact of enabling this on X86.
>>> >
>>> > We're seeing build errors when targeting Android, which I think may
>>> > be
>>> > caused by this:
>>> >
>>> > [...]
>>> > In file included from ../../v8/src/base/functional.cc:11:
>>> > In file included from ../../v8/src/base/functional.h:13:
>>> > In file included from
>>> >
>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/functional:55:
>>> > In file included from
>>> > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/tuple:38:
>>> > In file included from
>>> >
>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/utility:70:
>>> > In file included from
>>> >
>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_pair.h:59:
>>> > In file included from
>>> >
>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/move.h:57:
>>> >
>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:269:39:
>>> > error: __float128 is not supported on this target
>>> > struct __is_floating_point_helper<__float128>
>>> >   ^
>>> >
>>> > (From
>>> >
>>> https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng/builds/54128/steps/compile%20%28with%20patch%29/logs/stdio
>>> )
>>> >
>>> > Any idea what might be breaking here?
>>>
>>> Yep, see: http://reviews.llvm.org/D19125
>>
>>
>> Since this is breaking real-world code, is it possible to revert this
>> until http://reviews.llvm.org/D19125 is ready?
>>
>>
>>>
>>>
>>>  -Hal
>>>
>>> >
>>> > Thanks,
>>> > Hans
>>> > ___
>>> > cfe-commits mailing list
>>> > cfe-commits@lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>> >
>>>
>>> --
>>> Hal Finkel
>>> Assistant Computational Scientist
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>>>
>>
>>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r266455 - [Release Notes] mention Clang-tidy misc-multiple-statement-macro check.

[Eugene Zelenko via cfe-commits]

Author: eugenezelenko
Date: Fri Apr 15 12:32:19 2016
New Revision: 266455

URL: http://llvm.org/viewvc/llvm-project?rev=266455&view=rev
Log:
[Release Notes] mention Clang-tidy misc-multiple-statement-macro check.

Modified:
clang-tools-extra/trunk/docs/ReleaseNotes.rst

Modified: clang-tools-extra/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/ReleaseNotes.rst?rev=266455&r1=266454&r2=266455&view=diff
==
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst (original)
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst Fri Apr 15 12:32:19 2016
@@ -103,6 +103,11 @@ identified.  The improvements since the
   Warns when there is a explicit redundant cast of a calculation result to a
   bigger type.
 
+- New `misc-multiple-statement-macro
+  
`_
 check
+
+  Detect multiple statement macros that are used in unbraced conditionals.
+
 - New `misc-pointer-and-integral-operation
   
`_
 check
 
@@ -128,7 +133,7 @@ identified.  The improvements since the
   
`_
 check
 
   Finds most instances of stray semicolons that unexpectedly alter the meaning
-  of the code.  
+  of the code.
 
 - New `modernize-deprecated-headers
   
`_
 check


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

Re: [PATCH] D18821: Add modernize-bool-to-integer-conversion

[Piotr Padlewski via cfe-commits]

Prazek added a comment.

In http://reviews.llvm.org/D18821#398843, @alexfh wrote:

> BTW, why is the check in the 'modernize' module? It doesn't seem to make 
> anything more modern. I would guess, the pattern it detects is most likely to 
> result from a programming error. Also, the fix, though it retains the 
> behavior, has a high chance to be incorrect. Can you share the results of 
> running this check on LLVM? At least, how many problems it found and how many 
> times the suggested fix was correct.
>
> I'd suggest to move the check to `misc` or maybe it's time to create a 
> separate directory for checks targeting various bug-prone patterns.


Do you have any thought about the name for such a module? I belive that misc is 
overloaded.

So for this we are looking for something that is probably not a bug, but it 
makes code a little bit inaccurate
Maybe something like:

- accuracy,
- correctness,
- certainity,
- safety,
- maybebugmaybenothardtosay


http://reviews.llvm.org/D18821



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

Re: r266186 - Enable support for __float128 in Clang

[Nemanja Ivanovic via cfe-commits]

OK, I'm reverting now. I've done an svn merge but I'm just re-running all
the tests to make sure something weird didn't happen that would cause
buildbot failures.


Perhaps I should have posted D19125 before committing D15120 rather than
sending an email to cfe-dev and asking which targets need the support
enabled. Well, I'll know for next time :).

Nemanja

On Fri, Apr 15, 2016 at 6:51 PM, Nico Weber  wrote:

> I've looked into this a bit, and this breaks compiling programs like
> `#include ` on linux, without passing any special flags (other than
> `-std=gnu++11`). That seems like a very big regression :-) I think this
> should be reverted, so that there's no rush for getting your other patch in.
>
> LLVM tries to keep trunk shippable at all times, and not being able to
> compile  on linux seems bad :-) We're trying to actually ship clang
> trunk every week or two, and this is already somewhat hard if things that
> break the world are reverted and fixed asynchronously.
>
> Can you revert, please?
>
> On Fri, Apr 15, 2016 at 11:53 AM, Nemanja Ivanovic <
> nemanja.i@gmail.com> wrote:
>
>> I have just pinged the patch to see if I can get it approved today. Can I
>> give it a few hours and if it isn't approved by tonight, I'll revert the
>> other patch?
>>
>> BTW. a temporary workaround for this issue if absolutely required in the
>> next few hours is to comment out the following define in bits/config.h:
>>
>> /* Define if __float128 is supported on this host. */
>> #define _GLIBCXX_USE_FLOAT128 1
>>
>>
>> On Fri, Apr 15, 2016 at 4:14 PM, Nico Weber  wrote:
>>
>>> On Fri, Apr 15, 2016 at 12:27 AM, Hal Finkel  wrote:
>>>
 - Original Message -
 > From: "Hans Wennborg via cfe-commits" 
 > To: "Nemanja Ivanovic" , "Nico Weber" <
 tha...@chromium.org>
 > Cc: "cfe-commits" 
 > Sent: Thursday, April 14, 2016 8:07:58 PM
 > Subject: Re: r266186 - Enable support for __float128 in Clang
 >
 > On Wed, Apr 13, 2016 at 2:49 AM, Nemanja Ivanovic via cfe-commits
 >  wrote:
 > > Author: nemanjai
 > > Date: Wed Apr 13 04:49:45 2016
 > > New Revision: 266186
 > >
 > > URL: http://llvm.org/viewvc/llvm-project?rev=266186&view=rev
 > > Log:
 > > Enable support for __float128 in Clang
 > >
 > > This patch corresponds to review:
 > > http://reviews.llvm.org/D15120
 > >
 > > It adds support for the __float128 keyword, literals and a target
 > > feature to
 > > enable it. This support is disabled by default on all targets and
 > > any target
 > > that has support for this type is free to add it.
 > >
 > > Based on feedback that I've received from target maintainers, this
 > > appears to
 > > be the right thing for most targets. I have not heard from the
 > > maintainers of
 > > X86 which I believe supports this type. I will subsequently
 > > investigate the
 > > impact of enabling this on X86.
 >
 > We're seeing build errors when targeting Android, which I think may
 > be
 > caused by this:
 >
 > [...]
 > In file included from ../../v8/src/base/functional.cc:11:
 > In file included from ../../v8/src/base/functional.h:13:
 > In file included from
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/functional:55:
 > In file included from
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/tuple:38:
 > In file included from
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/utility:70:
 > In file included from
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_pair.h:59:
 > In file included from
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/move.h:57:
 >
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:269:39:
 > error: __float128 is not supported on this target
 > struct __is_floating_point_helper<__float128>
 >   ^
 >
 > (From
 >
 https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng/builds/54128/steps/compile%20%28with%20patch%29/logs/stdio
 )
 >
 > Any idea what might be breaking here?

 Yep, see: http://reviews.llvm.org/D19125
>>>
>>>
>>> Since this is breaking real-world code, is it possible to revert this
>>> until http://reviews.llvm.org/D19125 is ready?
>>>
>>>


  -Hal

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

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

>>>
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.

Re: [PATCH] D18624: [PGO] PGOFuncName meta data if PGOFuncName is different from function's raw name.

[David Li via cfe-commits]

davidxl added inline comments.


Comment at: lib/CodeGen/CodeGenPGO.cpp:791
@@ +790,3 @@
+// Create PGOFuncName meta data.
+llvm::Function *F = ValueSite->getFunction();
+if (!llvm::getPGOFuncNameMetadata(*F))

This may not be the best place do set the data. Better to call it in setFuncName


http://reviews.llvm.org/D18624



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

Re: [PATCH] D18821: Add modernize-bool-to-integer-conversion

[Piotr Padlewski via cfe-commits]

Prazek updated the summary for this revision.
Prazek updated this revision to Diff 53909.
Prazek marked an inline comment as done.
Prazek added a comment.

I will think name for new module that would have all the checks like this.
I added ingnoring of bitfields of size 1


http://reviews.llvm.org/D18821

Files:
  clang-tidy/modernize/BoolToIntegerConversionCheck.cpp
  clang-tidy/modernize/BoolToIntegerConversionCheck.h
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-bool-to-integer-conversion.rst
  test/clang-tidy/modernize-bool-to-integer-conversion.cpp

Index: test/clang-tidy/modernize-bool-to-integer-conversion.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-bool-to-integer-conversion.cpp
@@ -0,0 +1,78 @@
+// RUN: %check_clang_tidy %s modernize-bool-to-integer-conversion %t
+
+const int is42Answer = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:24: warning: implicitly converting bool literal to 'int'; use integer literal instead [modernize-bool-to-integer-conversion]
+// CHECK-FIXES: const int is42Answer = 1;{{$}}
+
+volatile int noItsNot = false;
+// CHECK-MESSAGES: :[[@LINE-1]]:25: warning: implicitly converting bool literal to 'int'; {{..}}
+// CHECK-FIXES: volatile int noItsNot = 0;{{$}}
+int a = 42;
+int az = a;
+
+long long ll = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: implicitly converting bool literal to 'long long';{{..}}
+// CHECK-FIXES: long long ll = 1;{{$}}
+
+void fun(int) {}
+#define ONE true
+
+// No fixup for macros.
+int one = ONE;
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: implicitly converting bool literal to 'int' inside a macro; use integer literal instead [modernize-bool-to-integer-conversion]
+
+void test() {
+  fun(ONE);
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: implicitly converting bool{{..}}
+
+  fun(42);
+  fun(true);
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: implicitly {{..}}
+// CHECK-FIXES: fun(1);{{$}}
+}
+
+char c = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: implicitly {{..}}
+// CHECK-FIXES: char c = 1;
+
+float f = false;
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: implicitly converting bool literal to 'float';{{..}}
+// CHECK-FIXES: float f = 0;
+
+struct Blah {
+  Blah(int blah) { }
+};
+
+const int &ref = false;
+// CHECK-MESSAGES: :[[@LINE-1]]:18: warning: implicitly converting bool literal to 'int'{{..}}
+// CHECK-FIXES: const int &ref = 0;
+
+Blah bla = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: implicitly converting bool literal to 'int'{{..}}
+// CHECK-FIXES: Blah bla = 1;
+
+Blah bla2 = 1;
+
+char c2 = 1;
+char c3 = '0';
+bool b = true;
+
+struct BitFields {
+  unsigned a : 3;
+  unsigned flag : 1;
+};
+
+void testBitFields() {
+  BitFields b;
+
+  b.a = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: implicitly converting
+// CHECK-FIXES: b.a = 1;
+
+  // Don't warn of bitfields of size 1. Unfortunately we can't just
+  // change type of flag to bool, because some compilers like MSVC doesn't
+  // pack bitfields of different types.
+  b.flag = true;
+
+
+}
Index: docs/clang-tidy/checks/modernize-bool-to-integer-conversion.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/modernize-bool-to-integer-conversion.rst
@@ -0,0 +1,17 @@
+.. title:: clang-tidy - modernize-bool-to-integer-conversion
+
+modernize-bool-to-integer-conversion
+
+
+This check looks for implicit conversion from bool literals to integer types
+
+.. code-block:: C++
+
+  int a = false;
+  vector v(true); // Makes vector of one element
+
+  // Changes it to
+  int a = 0;
+  vector v(1); // Makes vector of one element
+
+
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -31,9 +31,9 @@
google-build-using-namespace
google-explicit-constructor
google-global-names-in-headers
-   google-readability-braces-around-statements (redirects to readability-braces-around-statements) 
+   google-readability-braces-around-statements (redirects to readability-braces-around-statements) 
google-readability-casting
-   google-readability-function-size (redirects to readability-function-size) 
+   google-readability-function-size (redirects to readability-function-size) 
google-readability-namespace-comments
google-readability-redundant-smartptr-get
google-readability-todo
@@ -76,6 +76,7 @@
misc-unused-parameters
misc-unused-raii
misc-virtual-near-miss
+   modernize-bool-to-integer-conversion
modernize-deprecated-headers
modernize-loop-convert
modernize-make-unique
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.

[PATCH] D19165: [clang-tidy] Add modernize-increment-bool check.

[Marek Sokołowski via cfe-commits]

mnbvmar created this revision.
mnbvmar added reviewers: alexfh, Prazek, staronj, krystyna.
mnbvmar added a subscriber: cfe-commits.

http://reviews.llvm.org/D19165

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/IncrementBoolCheck.cpp
  clang-tidy/modernize/IncrementBoolCheck.h
  clang-tidy/modernize/ModernizeTidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-increment-bool.rst
  test/clang-tidy/modernize-increment-bool.cpp

Index: test/clang-tidy/modernize-increment-bool.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-increment-bool.cpp
@@ -0,0 +1,55 @@
+// RUN: %check_clang_tidy %s modernize-increment-bool %t
+
+template
+T& f(T &x) { return x; }
+
+template
+void g() {
+  T x;
+  x++;
+
+  bool y;
+  y++;
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: bool incrementation is deprecated, use assignment
+// CHECK-FIXES: y = true;
+}
+
+int main() {
+  bool b1 = false, b2 = false, b3 = false;
+
+  b1++;
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: bool incrementation is deprecated, use assignment
+// CHECK-FIXES: b1 = true;
+
+  bool b4 = f(b1)++;
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: bool incrementation is deprecated, use assignment
+
+  bool b5 = ++f(b1);
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: bool incrementation is deprecated, use assignment
+// CHECK-FIXES: bool b5 = (f(b1) = true);
+
+  (b1 = false)++;
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: bool incrementation is deprecated, use assignment
+// CHECK-FIXES: (b1 = false) = true;
+
+  (b1 = b2 = false)++;
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: bool incrementation is deprecated, use assignment
+// CHECK-FIXES: (b1 = b2 = false) = true;
+
+  ++(b1 = b2 = false);
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: bool incrementation is deprecated, use assignment
+// CHECK-FIXES: (b1 = b2 = false) = true;
+
+  b3 = b1++ && b2;
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: bool incrementation is deprecated, use assignment
+
+  b3 = ++(b1 |= b4) && b3;
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: bool incrementation is deprecated, use assignment
+// CHECK-FIXES: b3 = ((b1 |= b4) = true) && b3;
+
+  int x = 8;
+  x++;
+
+  g();
+  g();
+}
Index: docs/clang-tidy/checks/modernize-increment-bool.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/modernize-increment-bool.rst
@@ -0,0 +1,57 @@
+.. title:: clang-tidy - modernize-increment-bool
+
+modernize-increment-bool
+
+
+This check detects the deprecated boolean type incrementation, and wherever possible,
+converts it into truth assignment.
+
+C++17 forbids this behavior. Before C++17 this was equivalent to setting the variable
+to true.
+
+
+Example
+---
+
+Original:
+
+.. code-block:: c++
+
+  bool variable = false;
+  variable++;
+  ++variable;
+
+  bool another = ++variable;
+  bool third = ++variable && another;
+
+After applying the check:
+
+.. code-block:: c++
+
+  bool variable = false;
+  variable = true;
+  variable = true;  /* Both postfix and prefix incrementations are supported. */
+
+  bool another = (variable = true);
+  bool third = (variable = true) && another;
+
+
+Limitations
+---
+
+When postfix boolean incrementation is not the outermost operation done in the instruction,
+tool will not repair the problem (the fix would have to append some instructions after the
+statement). For example:
+
+.. code-block:: c++
+
+  bool first = false, second;
+
+  /* Equivalent to:
+if (!first) {
+  second = false;
+  first = true;
+}
+  */
+  if (!first) second = first++;
+
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -77,6 +77,7 @@
misc-unused-raii
misc-virtual-near-miss
modernize-deprecated-headers
+   modernize-increment-bool
modernize-loop-convert
modernize-make-unique
modernize-pass-by-value
Index: clang-tidy/modernize/ModernizeTidyModule.cpp
===
--- clang-tidy/modernize/ModernizeTidyModule.cpp
+++ clang-tidy/modernize/ModernizeTidyModule.cpp
@@ -11,6 +11,7 @@
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
 #include "DeprecatedHeadersCheck.h"
+#include "IncrementBoolCheck.h"
 #include "LoopConvertCheck.h"
 #include "MakeUniqueCheck.h"
 #include "PassByValueCheck.h"
@@ -34,6 +35,8 @@
   void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
 CheckFactories.registerCheck(
 "modernize-deprecated-headers");
+CheckFactories.registerCheck(
+"modernize-increment-bool");
 CheckFactories.registerCheck("modernize-loop-convert");
 CheckFactories.registerCheck("modernize-make-unique");
 CheckFactories.registerCheck("modernize-pass-by-value");
Index: clang-tidy/mod

Re: [PATCH] D19165: [clang-tidy] Add modernize-increment-bool check.

[Aaron Ballman via cfe-commits]

aaron.ballman added a subscriber: aaron.ballman.
aaron.ballman added a comment.

This strikes me as something the compiler should diagnose instead of a 
clang-tidy check. Incrementing a bool has been deprecated for some time, but it 
is outright removed in C++17, so I think giving users a migration path as part 
of the compiler would be far more beneficial. What do you think?


http://reviews.llvm.org/D19165



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

Re: [PATCH] D19014: [clang-tidy] Add new checker for suspicious sizeof expressions

[Etienne Bergeron via cfe-commits]

etienneb updated this revision to Diff 53905.
etienneb added a comment.

rebased


http://reviews.llvm.org/D19014

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/SizeofExpressionCheck.cpp
  clang-tidy/misc/SizeofExpressionCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-sizeof-expression.rst
  test/clang-tidy/misc-sizeof-expression.cpp

Index: test/clang-tidy/misc-sizeof-expression.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-sizeof-expression.cpp
@@ -0,0 +1,186 @@
+// RUN: %check_clang_tidy %s misc-sizeof-expression %t
+
+class C {
+  int size() { return sizeof(this); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: suspicious usage of 'sizeof(this)'
+};
+
+#define LEN 8
+
+int X;
+extern int A[10];
+extern short B[10];
+
+#pragma pack(1)
+struct  S { char a, b, c; };
+
+int Test1(const char* ptr) {
+  int sum = 0;
+  sum += sizeof(LEN);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(K)'
+  sum += sizeof(LEN + 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(K)'
+  sum += sizeof(sum, LEN);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(..., ...)'
+  sum += sizeof(sizeof(X));
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(sizeof(...))'
+  sum += sizeof(LEN + sizeof(X));
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(sizeof(...))'
+  sum += sizeof(LEN + LEN + sizeof(X));
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(sizeof(...))'
+  sum += sizeof(LEN + (LEN + sizeof(X)));
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(sizeof(...))'
+  sum += sizeof(LEN + -sizeof(X));
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(sizeof(...))'
+  sum += sizeof(LEN + - + -sizeof(X));
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(sizeof(...))'
+  sum += sizeof(char) / sizeof(char);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of sizeof pointer 'sizeof(T)/sizeof(T)'
+  sum += sizeof(A) / sizeof(S);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(...)/sizeof(...)'; numerator is not a multiple of denominator
+  sum += sizeof(char) / sizeof(int);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(...)/sizeof(...)'; numerator is not a multiple of denominator
+  sum += sizeof(char) / sizeof(A);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(...)/sizeof(...)'; numerator is not a multiple of denominator
+  sum += sizeof(B[0]) / sizeof(A);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of 'sizeof(...)/sizeof(...)'; numerator is not a multiple of denominator
+  sum += sizeof(ptr) / sizeof(char);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of sizeof pointer 'sizeof(T*)/sizeof(T)'
+  sum += sizeof(ptr) / sizeof(ptr[0]);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of sizeof pointer 'sizeof(T*)/sizeof(T)'
+  sum += sizeof(ptr) / sizeof(char*);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of sizeof pointer 'sizeof(P*)/sizeof(Q*)'
+  sum += sizeof(ptr) / sizeof(void*);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of sizeof pointer 'sizeof(P*)/sizeof(Q*)'
+  sum += sizeof(ptr) / sizeof(const void volatile*);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of sizeof pointer 'sizeof(P*)/sizeof(Q*)'
+  sum += sizeof(ptr) / sizeof(char);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of sizeof pointer 'sizeof(T*)/sizeof(T)'
+  sum += sizeof(ptr) / sizeof(ptr[0]);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious usage of sizeof pointer 'sizeof(T*)/sizeof(T)'
+  sum += sizeof(int) * sizeof(char);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious 'sizeof' by 'sizeof' multiplication
+  sum += sizeof(ptr) * sizeof(ptr[0]);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious 'sizeof' by 'sizeof' multiplication
+  sum += sizeof(int) * (2 * sizeof(char));
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious 'sizeof' by 'sizeof' multiplication
+  sum += (2 * sizeof(char)) * sizeof(int);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious 'sizeof' by 'sizeof' multiplication
+  if (sizeof(A) < 0x10) sum += 42;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: suspicious comparison of 'sizeof(expr)' to a constant 
+  if (sizeof(A) <= 0xFFFEU) sum += 42;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: suspicious comparison of 'sizeof(expr)' to a constant 
+  return sum;
+}
+
+typedef char MyChar;
+typedef const MyChar MyConstChar;
+
+int CE0 = sizeof sizeof(char);
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: suspicious usage of 'sizeof(sizeof(...))'
+int CE1 = size

Re: r266186 - Enable support for __float128 in Clang

[Nico Weber via cfe-commits]

I've looked into this a bit, and this breaks compiling programs like
`#include ` on linux, without passing any special flags (other than
`-std=gnu++11`). That seems like a very big regression :-) I think this
should be reverted, so that there's no rush for getting your other patch in.

LLVM tries to keep trunk shippable at all times, and not being able to
compile  on linux seems bad :-) We're trying to actually ship clang
trunk every week or two, and this is already somewhat hard if things that
break the world are reverted and fixed asynchronously.

Can you revert, please?

On Fri, Apr 15, 2016 at 11:53 AM, Nemanja Ivanovic 
wrote:

> I have just pinged the patch to see if I can get it approved today. Can I
> give it a few hours and if it isn't approved by tonight, I'll revert the
> other patch?
>
> BTW. a temporary workaround for this issue if absolutely required in the
> next few hours is to comment out the following define in bits/config.h:
>
> /* Define if __float128 is supported on this host. */
> #define _GLIBCXX_USE_FLOAT128 1
>
>
> On Fri, Apr 15, 2016 at 4:14 PM, Nico Weber  wrote:
>
>> On Fri, Apr 15, 2016 at 12:27 AM, Hal Finkel  wrote:
>>
>>> - Original Message -
>>> > From: "Hans Wennborg via cfe-commits" 
>>> > To: "Nemanja Ivanovic" , "Nico Weber" <
>>> tha...@chromium.org>
>>> > Cc: "cfe-commits" 
>>> > Sent: Thursday, April 14, 2016 8:07:58 PM
>>> > Subject: Re: r266186 - Enable support for __float128 in Clang
>>> >
>>> > On Wed, Apr 13, 2016 at 2:49 AM, Nemanja Ivanovic via cfe-commits
>>> >  wrote:
>>> > > Author: nemanjai
>>> > > Date: Wed Apr 13 04:49:45 2016
>>> > > New Revision: 266186
>>> > >
>>> > > URL: http://llvm.org/viewvc/llvm-project?rev=266186&view=rev
>>> > > Log:
>>> > > Enable support for __float128 in Clang
>>> > >
>>> > > This patch corresponds to review:
>>> > > http://reviews.llvm.org/D15120
>>> > >
>>> > > It adds support for the __float128 keyword, literals and a target
>>> > > feature to
>>> > > enable it. This support is disabled by default on all targets and
>>> > > any target
>>> > > that has support for this type is free to add it.
>>> > >
>>> > > Based on feedback that I've received from target maintainers, this
>>> > > appears to
>>> > > be the right thing for most targets. I have not heard from the
>>> > > maintainers of
>>> > > X86 which I believe supports this type. I will subsequently
>>> > > investigate the
>>> > > impact of enabling this on X86.
>>> >
>>> > We're seeing build errors when targeting Android, which I think may
>>> > be
>>> > caused by this:
>>> >
>>> > [...]
>>> > In file included from ../../v8/src/base/functional.cc:11:
>>> > In file included from ../../v8/src/base/functional.h:13:
>>> > In file included from
>>> >
>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/functional:55:
>>> > In file included from
>>> > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/tuple:38:
>>> > In file included from
>>> >
>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/utility:70:
>>> > In file included from
>>> >
>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_pair.h:59:
>>> > In file included from
>>> >
>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/move.h:57:
>>> >
>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:269:39:
>>> > error: __float128 is not supported on this target
>>> > struct __is_floating_point_helper<__float128>
>>> >   ^
>>> >
>>> > (From
>>> >
>>> https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng/builds/54128/steps/compile%20%28with%20patch%29/logs/stdio
>>> )
>>> >
>>> > Any idea what might be breaking here?
>>>
>>> Yep, see: http://reviews.llvm.org/D19125
>>
>>
>> Since this is breaking real-world code, is it possible to revert this
>> until http://reviews.llvm.org/D19125 is ready?
>>
>>
>>>
>>>
>>>  -Hal
>>>
>>> >
>>> > Thanks,
>>> > Hans
>>> > ___
>>> > cfe-commits mailing list
>>> > cfe-commits@lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>> >
>>>
>>> --
>>> Hal Finkel
>>> Assistant Computational Scientist
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r266451 - [clang-tidy] Add new checker for suspicious sizeof expressions

[Etienne Bergeron via cfe-commits]

Author: etienneb
Date: Fri Apr 15 11:36:00 2016
New Revision: 266451

URL: http://llvm.org/viewvc/llvm-project?rev=266451&view=rev
Log:
[clang-tidy] Add new checker for suspicious sizeof expressions

Summary:
This check is finding suspicious cases of sizeof expression.

Sizeof expression is returning the size (in bytes) of a type or an
expression. Programmers often abuse or misuse this expression.

This checker is adding common set of patterns to detect some
of these bad constructs.


Some examples found by this checker:

R/packages/ifultools/ifultools/src/fra_neig.c
```
/* free buffer memory */
(void) mutil_free( dist_buff, sizeof( ctr * sizeof( double ) ) );
(void) mutil_free( nidx_buff, sizeof( ctr * sizeof( sint32 ) ) );
```


graphviz/v2_20_2/lib/common/utils.c
```
static Dtdisc_t mapDisc = {
offsetof(item, p),
sizeof(2 * sizeof(void *)),
offsetof(item, link),
(Dtmake_f) newItem,
(Dtfree_f) freeItem,
(Dtcompar_f) cmpItem,
NIL(Dthash_f),
NIL(Dtmemory_f),
NIL(Dtevent_f)
};
```


mDNSResponder/mDNSShared/dnsextd.c
```
context = ( TCPContext* ) malloc( sizeof( TCPContext ) );
require_action( context, exit, err = mStatus_NoMemoryErr; LogErr( 
"AcceptTCPConnection", "malloc" ) );
mDNSPlatformMemZero( context, sizeof( sizeof( TCPContext ) ) );
context->d   = self;
```

Reviewers: alexfh

Subscribers: malcolm.parsons, Eugene.Zelenko, cfe-commits

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

Added:
clang-tools-extra/trunk/clang-tidy/misc/SizeofExpressionCheck.cpp
clang-tools-extra/trunk/clang-tidy/misc/SizeofExpressionCheck.h
clang-tools-extra/trunk/docs/clang-tidy/checks/misc-sizeof-expression.rst
clang-tools-extra/trunk/test/clang-tidy/misc-sizeof-expression.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt?rev=266451&r1=266450&r2=266451&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt Fri Apr 15 11:36:00 
2016
@@ -23,6 +23,7 @@ add_clang_library(clangTidyMiscModule
   NonCopyableObjects.cpp
   PointerAndIntegralOperationCheck.cpp
   SizeofContainerCheck.cpp
+  SizeofExpressionCheck.cpp
   StaticAssertCheck.cpp
   StringIntegerAssignmentCheck.cpp
   StringLiteralWithEmbeddedNulCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp?rev=266451&r1=266450&r2=266451&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp Fri Apr 15 
11:36:00 2016
@@ -31,6 +31,7 @@
 #include "NonCopyableObjects.h"
 #include "PointerAndIntegralOperationCheck.h"
 #include "SizeofContainerCheck.h"
+#include "SizeofExpressionCheck.h"
 #include "StaticAssertCheck.h"
 #include "StringIntegerAssignmentCheck.h"
 #include "StringLiteralWithEmbeddedNulCheck.h"
@@ -92,6 +93,8 @@ public:
 CheckFactories.registerCheck(
 "misc-pointer-and-integral-operation");
 
CheckFactories.registerCheck("misc-sizeof-container");
+CheckFactories.registerCheck(
+"misc-sizeof-expression");
 CheckFactories.registerCheck(
 "misc-static-assert");
 CheckFactories.registerCheck(

Added: clang-tools-extra/trunk/clang-tidy/misc/SizeofExpressionCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/SizeofExpressionCheck.cpp?rev=266451&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/misc/SizeofExpressionCheck.cpp (added)
+++ clang-tools-extra/trunk/clang-tidy/misc/SizeofExpressionCheck.cpp Fri Apr 
15 11:36:00 2016
@@ -0,0 +1,265 @@
+//===--- SizeofExpressionCheck.cpp - 
clang-tidy===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "SizeofExpressionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+namespace {
+
+AST_MATCHER(BinaryOperator, isRelationalOperator) {
+  return Node.isR

[clang-tools-extra] r266450 - [clang-tidy] Add checker for operations between integrals and pointers

[Etienne Bergeron via cfe-commits]

Author: etienneb
Date: Fri Apr 15 11:31:15 2016
New Revision: 266450

URL: http://llvm.org/viewvc/llvm-project?rev=266450&view=rev
Log:
[clang-tidy] Add checker for operations between integrals and pointers

Summary:
This check is finding suspicious operations involving pointers and integral 
types; which are most likely bugs.

Examples:
subversion/v1_6/subversion/libsvn_subr/utf.c
```
static const char *
fuzzy_escape(const char *src, apr_size_t len, apr_pool_t *pool)
{
  [...]
   while (src_orig < src_end)
{
  if (! svn_ctype_isascii(*src_orig) || src_orig == '\0')   // Should be 
*src_orig
{
```

apache2/v2_2_23/modules/metadata/mod_headers.c
```
static char *parse_format_tag(apr_pool_t *p, format_tag *tag, const char **sa)
{
  [...]
tag->arg = '\0';   // ERROR: tag->arg has type char*

/* grab the argument if there is one */
if (*s == '{') {
++s;
tag->arg = ap_getword(p,&s,'}');
}
```

Reviewers: alexfh

Subscribers: Eugene.Zelenko, cfe-commits

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

Added:
clang-tools-extra/trunk/clang-tidy/misc/PointerAndIntegralOperationCheck.cpp
clang-tools-extra/trunk/clang-tidy/misc/PointerAndIntegralOperationCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-pointer-and-integral-operation.rst

clang-tools-extra/trunk/test/clang-tidy/misc-pointer-and-integral-operation-cxx98.cpp

clang-tools-extra/trunk/test/clang-tidy/misc-pointer-and-integral-operation.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt?rev=266450&r1=266449&r2=266450&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt Fri Apr 15 11:31:15 
2016
@@ -21,6 +21,7 @@ add_clang_library(clangTidyMiscModule
   NewDeleteOverloadsCheck.cpp
   NoexceptMoveConstructorCheck.cpp
   NonCopyableObjects.cpp
+  PointerAndIntegralOperationCheck.cpp
   SizeofContainerCheck.cpp
   StaticAssertCheck.cpp
   StringIntegerAssignmentCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp?rev=266450&r1=266449&r2=266450&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp Fri Apr 15 
11:31:15 2016
@@ -29,6 +29,7 @@
 #include "NewDeleteOverloadsCheck.h"
 #include "NoexceptMoveConstructorCheck.h"
 #include "NonCopyableObjects.h"
+#include "PointerAndIntegralOperationCheck.h"
 #include "SizeofContainerCheck.h"
 #include "StaticAssertCheck.h"
 #include "StringIntegerAssignmentCheck.h"
@@ -88,6 +89,8 @@ public:
 "misc-noexcept-move-constructor");
 CheckFactories.registerCheck(
 "misc-non-copyable-objects");
+CheckFactories.registerCheck(
+"misc-pointer-and-integral-operation");
 
CheckFactories.registerCheck("misc-sizeof-container");
 CheckFactories.registerCheck(
 "misc-static-assert");

Added: 
clang-tools-extra/trunk/clang-tidy/misc/PointerAndIntegralOperationCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/PointerAndIntegralOperationCheck.cpp?rev=266450&view=auto
==
--- 
clang-tools-extra/trunk/clang-tidy/misc/PointerAndIntegralOperationCheck.cpp 
(added)
+++ 
clang-tools-extra/trunk/clang-tidy/misc/PointerAndIntegralOperationCheck.cpp 
Fri Apr 15 11:31:15 2016
@@ -0,0 +1,104 @@
+//===--- PointerAndIntegralOperationCheck.cpp - 
clang-tidy-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "PointerAndIntegralOperationCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+void PointerAndIntegralOperationCheck::registerMatchers(MatchFinder *Finder) {
+  const auto PointerExpr = expr(hasType(pointerType()));
+  const auto BoolExpr = ignoringParenImpCasts(hasType(booleanType()));
+  const auto CharExpr = ignoringParenImpCasts(hasType(isAnyCharacter()));
+
+  const auto BinOpWithPointerExpr =
+  binaryOp

Re: [PATCH] D19118: [clang-tidy] Add checker for operations between integrals and pointers

[Etienne Bergeron via cfe-commits]

etienneb updated this revision to Diff 53903.
etienneb marked 3 inline comments as done.
etienneb added a comment.

comments.


http://reviews.llvm.org/D19118

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/PointerAndIntegralOperationCheck.cpp
  clang-tidy/misc/PointerAndIntegralOperationCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-pointer-and-integral-operation.rst
  test/clang-tidy/misc-pointer-and-integral-operation-cxx98.cpp
  test/clang-tidy/misc-pointer-and-integral-operation.cpp

Index: test/clang-tidy/misc-pointer-and-integral-operation.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-pointer-and-integral-operation.cpp
@@ -0,0 +1,30 @@
+// RUN: %check_clang_tidy %s misc-pointer-and-integral-operation %t
+
+bool* pb;
+char* pc;
+int* pi;
+
+int Test() {
+  if (pi < 0) return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious comparison of pointer with zero [misc-pointer-and-integral-operation]
+  if (pi <= 0) return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious comparison of pointer with zero
+
+  if (nullptr <= pb) return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: suspicious comparison of pointer with null
+  if (pc < nullptr) return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious comparison of pointer with null
+  if (pi > nullptr) return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious comparison of pointer with null
+
+  return 1;
+}
+
+int Valid() {
+  *pb = false;
+  *pc = '\0';
+
+  pi += (pi != nullptr);
+  pi -= (pi == nullptr);
+  pc += (pb != nullptr);
+}
Index: test/clang-tidy/misc-pointer-and-integral-operation-cxx98.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-pointer-and-integral-operation-cxx98.cpp
@@ -0,0 +1,45 @@
+// RUN: %check_clang_tidy %s misc-pointer-and-integral-operation %t -- -- -std=c++98
+
+bool* pb;
+char* pc;
+int* pi;
+
+int Test() {
+  pb = false;
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: suspicious assignment from bool to pointer [misc-pointer-and-integral-operation]
+  pc = '\0';
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: suspicious assignment from char to pointer
+
+  pb = (false?false:false);
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: suspicious assignment from bool to pointer
+  pb = (4 != 5?false:false);
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: suspicious assignment from bool to pointer
+
+  if (pb < false) return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious operation between pointer and bool literal
+  if (pb != false) return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious operation between pointer and bool literal
+  if (pc < '\0') return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious operation between pointer and character literal
+  if (pc != '\0') return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious operation between pointer and character literal
+  if (pi < '\0') return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious operation between pointer and character literal
+  if (pi != '\0') return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious operation between pointer and character literal
+
+  return 1;
+}
+
+int Valid() {
+  *pb = false;
+  *pc = '\0';
+
+  pb += 0;
+  pc += 0;
+  pi += 0;
+
+  pb += (pb != 0);
+  pc += (pc != 0);
+  pi += (pi != 0);
+}
Index: docs/clang-tidy/checks/misc-pointer-and-integral-operation.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-pointer-and-integral-operation.rst
@@ -0,0 +1,24 @@
+.. title:: clang-tidy - misc-pointer-and-integral-operation
+
+misc-pointer-and-integral-operation
+===
+
+Looks for operation involving pointers and integral types. A common mistake is
+to forget to dereference a pointer. These errors may be detected when a pointer
+object is compare to an object with integral type.
+
+Examples:
+
+.. code:: c++
+
+  char* ptr;
+  if ((ptr = malloc(...)) < nullptr)   // Pointer comparison with operator '<'
+...// Should probably be '!='
+
+  if (ptr == '\0')   // Should probably be *ptr
+... 
+
+  void Process(std::string path, bool* error) {
+[...]
+if (error != false)  // Should probably be *error
+  ...
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -65,6 +65,7 @@
misc-new-delete-overloads
misc-noexcept-move-constructor
misc-non-copyable-objects
+   misc-pointer-and-integral-operation
misc-sizeof-container
misc-static-assert
misc-string-integer-assignment
Index: docs/ReleaseNotes.rst
=

Re: [PATCH] D19118: [clang-tidy] Add checker for operations between integrals and pointers

[Etienne Bergeron via cfe-commits]

etienneb added inline comments.


Comment at: docs/clang-tidy/checks/misc-pointer-and-integral-operation.rst:22
@@ +21,3 @@
+
+  void Prcess(std::string path, bool* error) {
+[...]

Eugene.Zelenko wrote:
> Process?
tpo. oups.. typo :)


http://reviews.llvm.org/D19118



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

Re: [PATCH] D18271: Avoid -Wshadow warnings about constructor parameters named after fields

[Reid Kleckner via cfe-commits]

rnk added inline comments.


Comment at: lib/Sema/SemaDecl.cpp:6417-6425
@@ +6416,11 @@
+if (isa(NewDC) && isa(D)) {
+  if (Diags.isIgnored(diag::warn_ctor_parm_shadows_field, R.getNameLoc())) 
{
+D = D->getCanonicalDecl();
+ShadowingDecls.insert({D, FD});
+  } else {
+Diag(R.getNameLoc(), diag::warn_ctor_parm_shadows_field)
+<< D << FD << FD->getParent();
+Diag(FD->getLocation(), diag::note_previous_declaration);
+  }
+  return;
+}

rsmith wrote:
> I would prefer for us to produce the -Wshadow "modifying shadowed" warning 
> where it applies, even when -Wshadow-all is enabled. The usual model is to 
> act as if -W* flags are just a filter over the diagnostic output, and this 
> diverges from that.
> 
> Is the goal to ensure that -Wshadow-field-in-constructor diagnoses all 
> constructor parameter / field shadowing, even if -Wshadow is not enabled?
Well, if we do that we'll get two warnings about the shadowed field: one on the 
site of the parameter declaration and another on the modification. That felt a 
bit redundant.

I can remove the if/else and we'll get the behavior you're asking for. Most 
users will not use -Wshadow-all, and even if they do they'll only see the 
double diagnostic in very rare cases.


http://reviews.llvm.org/D18271



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

r266449 - Fix testcase for MSVC targets where the output ordering is different.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Apr 15 11:21:23 2016
New Revision: 266449

URL: http://llvm.org/viewvc/llvm-project?rev=266449&view=rev
Log:
Fix testcase for MSVC targets where the output ordering is different.

Modified:
cfe/trunk/test/CodeGenCXX/debug-info-limited.cpp

Modified: cfe/trunk/test/CodeGenCXX/debug-info-limited.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-limited.cpp?rev=266449&r1=266448&r2=266449&view=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-limited.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-limited.cpp Fri Apr 15 11:21:23 2016
@@ -1,4 +1,5 @@
 // RUN: %clang -flimit-debug-info -emit-llvm -g -S %s -o - | FileCheck %s
+// RUN: %clang -flimit-debug-info -emit-llvm -g -S %s -o - | FileCheck 
--check-prefix=CHECK-C %s
 
 // CHECK: !DICompositeType(tag: DW_TAG_class_type, name: "A"
 // CHECK-NOT:  DIFlagFwdDecl
@@ -27,8 +28,8 @@ int baz(B *b) {
 }
 
 
-// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "C"
-// CHECK-SAME: flags: DIFlagFwdDecl
+// CHECK-C: !DICompositeType(tag: DW_TAG_structure_type, name: "C"
+// CHECK-C-SAME: flags: DIFlagFwdDecl
 
 struct C {
 };


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

r266447 - Update testcase to new debug info metadata format.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Apr 15 11:05:13 2016
New Revision: 266447

URL: http://llvm.org/viewvc/llvm-project?rev=266447&view=rev
Log:
Update testcase to new debug info metadata format.

Modified:
cfe/trunk/test/CodeGen/backend-unsupported-error.ll

Modified: cfe/trunk/test/CodeGen/backend-unsupported-error.ll
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/backend-unsupported-error.ll?rev=266447&r1=266446&r2=266447&view=diff
==
--- cfe/trunk/test/CodeGen/backend-unsupported-error.ll (original)
+++ cfe/trunk/test/CodeGen/backend-unsupported-error.ll Fri Apr 15 11:05:13 2016
@@ -27,15 +27,14 @@ attributes #0 = { nounwind uwtable "disa
 !llvm.module.flags = !{!9, !10}
 !llvm.ident = !{!11}
 
-!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang 
version 3.9.0", isOptimized: false, runtimeVersion: 0, emissionKind: 1, enums: 
!2, subprograms: !3)
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang 
version 3.9.0", isOptimized: false, runtimeVersion: 0, emissionKind: 1, enums: 
!2)
 !1 = !DIFile(filename: "test.c", directory: "")
 !2 = !{}
-!3 = !{!4, !8}
-!4 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type: 
!5, isLocal: false, isDefinition: true, scopeLine: 2, isOptimized: false, 
variables: !2)
+!4 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type: 
!5, isLocal: false, isDefinition: true, scopeLine: 2, isOptimized: false, unit: 
!0, variables: !2)
 !5 = !DISubroutineType(types: !6)
 !6 = !{!7}
 !7 = !DIBasicType(name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
-!8 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 3, type: 
!5, isLocal: false, isDefinition: true, scopeLine: 3, flags: DIFlagPrototyped, 
isOptimized: false, variables: !2)
+!8 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 3, type: 
!5, isLocal: false, isDefinition: true, scopeLine: 3, flags: DIFlagPrototyped, 
isOptimized: false, unit: !0, variables: !2)
 !9 = !{i32 2, !"Dwarf Version", i32 4}
 !10 = !{i32 2, !"Debug Info Version", i32 3}
 !11 = !{!"clang version 3.9.0"}


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

Re: [PATCH] D16044: getDescriptiveName() for MemRegion

[Gábor Horváth via cfe-commits]

xazax.hun added a comment.

In http://reviews.llvm.org/D16044#401130, @Alexander_Droste wrote:

> Might the problem be in the va_list checker?
>  Obviously the va_list variable is identified as an ElementRegion what seems 
> not to be correct. 
>  Only if the passed region is an ElementRegion indices get appended.


The memory region for the va_list that was obtained from the analyzer in same 
case was indeed an element region in the va_list checker. I fixed this issue, 
and now it works properly.


http://reviews.llvm.org/D16044



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

r266445 - Update to match LLVM changes for PR27284.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Apr 15 10:55:45 2016
New Revision: 266445

URL: http://llvm.org/viewvc/llvm-project?rev=266445&view=rev
Log:
Update to match LLVM changes for PR27284.
(Reverse the ownership between DICompileUnit and DISubprogram.)

http://reviews.llvm.org/D19034


Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/CodeGen/debug-info-scope-file.c
cfe/trunk/test/CodeGen/debug-info.c
cfe/trunk/test/CodeGenCXX/PR20038.cpp
cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp
cfe/trunk/test/CodeGenCXX/debug-info-function-context.cpp
cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp
cfe/trunk/test/CodeGenCXX/debug-info-ptr-to-member-function.cpp
cfe/trunk/test/CodeGenCXX/debug-info-template-member.cpp
cfe/trunk/test/CodeGenCXX/debug-info.cpp
cfe/trunk/test/CodeGenCXX/debug-lambda-expressions.cpp
cfe/trunk/test/CodeGenCXX/debug-lambda-this.cpp
cfe/trunk/test/CodeGenCXX/linetable-virtual-variadic.cpp
cfe/trunk/test/CodeGenObjC/debug-info-block-type.m
cfe/trunk/test/CodeGenObjC/debug-property-synth.m
cfe/trunk/test/Modules/ExtDebugInfo.m
cfe/trunk/test/Modules/ModuleDebugInfo.cpp
cfe/trunk/test/Modules/ModuleDebugInfo.m

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=266445&r1=266444&r2=266445&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Apr 15 10:55:45 2016
@@ -2793,11 +2793,11 @@ void CGDebugInfo::EmitFunctionDecl(Globa
   unsigned LineNo = getLineNumber(Loc);
   unsigned ScopeLine = 0;
 
-  DBuilder.createFunction(FDContext, Name, LinkageName, Unit, LineNo,
-  getOrCreateFunctionType(D, FnType, Unit),
-  false /*internalLinkage*/, true /*definition*/,
-  ScopeLine, Flags, CGM.getLangOpts().Optimize,
-  TParamsArray.get(), getFunctionDeclaration(D));
+  DBuilder.retainType(DBuilder.createFunction(
+  FDContext, Name, LinkageName, Unit, LineNo,
+  getOrCreateFunctionType(D, FnType, Unit), false /*internalLinkage*/,
+  false /*definition*/, ScopeLine, Flags, CGM.getLangOpts().Optimize,
+  TParamsArray.get(), getFunctionDeclaration(D)));
 }
 
 void CGDebugInfo::EmitLocation(CGBuilderTy &Builder, SourceLocation Loc) {

Modified: cfe/trunk/test/CodeGen/debug-info-scope-file.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/debug-info-scope-file.c?rev=266445&r1=266444&r2=266445&view=diff
==
--- cfe/trunk/test/CodeGen/debug-info-scope-file.c (original)
+++ cfe/trunk/test/CodeGen/debug-info-scope-file.c Fri Apr 15 10:55:45 2016
@@ -6,8 +6,8 @@
 // CHECK: ret void, !dbg [[F1_LINE:![0-9]*]]
 // CHECK: ret void, !dbg [[F2_LINE:![0-9]*]]
 // CHECK: [[F1:![0-9]*]] = distinct !DISubprogram(name: "f1",{{.*}} 
isDefinition: true
-// CHECK: [[F2:![0-9]*]] = distinct !DISubprogram(name: "f2",{{.*}} 
isDefinition: true
 // CHECK: [[F1_LINE]] = !DILocation({{.*}}, scope: [[F1]])
+// CHECK: [[F2:![0-9]*]] = distinct !DISubprogram(name: "f2",{{.*}} 
isDefinition: true
 // CHECK: [[F2_LINE]] = !DILocation({{.*}}, scope: [[F2]])
 
 void f1() {

Modified: cfe/trunk/test/CodeGen/debug-info.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/debug-info.c?rev=266445&r1=266444&r2=266445&view=diff
==
--- cfe/trunk/test/CodeGen/debug-info.c (original)
+++ cfe/trunk/test/CodeGen/debug-info.c Fri Apr 15 10:55:45 2016
@@ -7,7 +7,7 @@ void convert(void) {
 
 
 // PR2784
-struct OPAQUE; // CHECK: DW_TAG_structure_type
+struct OPAQUE; // CHECK-DAG: DW_TAG_structure_type, name: "OPAQUE"
 typedef struct OPAQUE *PTR;
 PTR p;
 
@@ -42,19 +42,19 @@ struct foo2 foo2;
 
 
 // Radar 7325611
-// CHECK: !DIDerivedType(tag: DW_TAG_typedef, name: "barfoo"
+// CHECK-DAG: !DIDerivedType(tag: DW_TAG_typedef, name: "barfoo"
 typedef int barfoo;
 barfoo foo() {
 }
 
-// CHECK: __uint128_t
+// CHECK-DAG: __uint128_t
 __uint128_t foo128 ()
 {
   __uint128_t int128 = 44;
   return int128;
 }
 
-// CHECK: uint64x2_t
+// CHECK-DAG: uint64x2_t
 typedef unsigned long long uint64_t;
 typedef uint64_t uint64x2_t __attribute__((ext_vector_type(2)));
 uint64x2_t extvectbar[4];

Modified: cfe/trunk/test/CodeGenCXX/PR20038.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/PR20038.cpp?rev=266445&r1=266444&r2=266445&view=diff
==
--- cfe/trunk/test/CodeGenCXX/PR20038.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/PR20038.cpp Fri Apr 15 10:55:45 2016
@@ -7,8 +7,8 @@ extern bool b;
 // CHECK: call {{.*}}, !dbg [[DTOR_CALL1_LOC:![0-9]*]]
 // CHECK: call {{.*}}, !dbg [[DTOR_CALL2_LO

Re: [PATCH] D18369: [OpenCL] Upstreaming khronos OpenCL header file.

[Alexey Bader via cfe-commits]

bader added a comment.

Sam, could you also add declarations of samplerless read_image and write_image 
built-in functions with read_write qualified images, please?


http://reviews.llvm.org/D18369



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

Re: r266186 - Enable support for __float128 in Clang

[Nemanja Ivanovic via cfe-commits]

I have just pinged the patch to see if I can get it approved today. Can I
give it a few hours and if it isn't approved by tonight, I'll revert the
other patch?

BTW. a temporary workaround for this issue if absolutely required in the
next few hours is to comment out the following define in bits/config.h:

/* Define if __float128 is supported on this host. */
#define _GLIBCXX_USE_FLOAT128 1


On Fri, Apr 15, 2016 at 4:14 PM, Nico Weber  wrote:

> On Fri, Apr 15, 2016 at 12:27 AM, Hal Finkel  wrote:
>
>> - Original Message -
>> > From: "Hans Wennborg via cfe-commits" 
>> > To: "Nemanja Ivanovic" , "Nico Weber" <
>> tha...@chromium.org>
>> > Cc: "cfe-commits" 
>> > Sent: Thursday, April 14, 2016 8:07:58 PM
>> > Subject: Re: r266186 - Enable support for __float128 in Clang
>> >
>> > On Wed, Apr 13, 2016 at 2:49 AM, Nemanja Ivanovic via cfe-commits
>> >  wrote:
>> > > Author: nemanjai
>> > > Date: Wed Apr 13 04:49:45 2016
>> > > New Revision: 266186
>> > >
>> > > URL: http://llvm.org/viewvc/llvm-project?rev=266186&view=rev
>> > > Log:
>> > > Enable support for __float128 in Clang
>> > >
>> > > This patch corresponds to review:
>> > > http://reviews.llvm.org/D15120
>> > >
>> > > It adds support for the __float128 keyword, literals and a target
>> > > feature to
>> > > enable it. This support is disabled by default on all targets and
>> > > any target
>> > > that has support for this type is free to add it.
>> > >
>> > > Based on feedback that I've received from target maintainers, this
>> > > appears to
>> > > be the right thing for most targets. I have not heard from the
>> > > maintainers of
>> > > X86 which I believe supports this type. I will subsequently
>> > > investigate the
>> > > impact of enabling this on X86.
>> >
>> > We're seeing build errors when targeting Android, which I think may
>> > be
>> > caused by this:
>> >
>> > [...]
>> > In file included from ../../v8/src/base/functional.cc:11:
>> > In file included from ../../v8/src/base/functional.h:13:
>> > In file included from
>> >
>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/functional:55:
>> > In file included from
>> > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/tuple:38:
>> > In file included from
>> >
>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/utility:70:
>> > In file included from
>> >
>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_pair.h:59:
>> > In file included from
>> >
>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/move.h:57:
>> >
>> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:269:39:
>> > error: __float128 is not supported on this target
>> > struct __is_floating_point_helper<__float128>
>> >   ^
>> >
>> > (From
>> >
>> https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng/builds/54128/steps/compile%20%28with%20patch%29/logs/stdio
>> )
>> >
>> > Any idea what might be breaking here?
>>
>> Yep, see: http://reviews.llvm.org/D19125
>
>
> Since this is breaking real-world code, is it possible to revert this
> until http://reviews.llvm.org/D19125 is ready?
>
>
>>
>>
>>  -Hal
>>
>> >
>> > Thanks,
>> > Hans
>> > ___
>> > cfe-commits mailing list
>> > cfe-commits@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>> >
>>
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r266444 - ASTMatchers.h: Fix formatting. [-Wdocumentation]

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Fri Apr 15 10:42:27 2016
New Revision: 266444

URL: http://llvm.org/viewvc/llvm-project?rev=266444&view=rev
Log:
ASTMatchers.h: Fix formatting. [-Wdocumentation]

Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=266444&r1=266443&r2=266444&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Fri Apr 15 10:42:27 2016
@@ -163,7 +163,7 @@ const internal::VariadicDynCastAllOfMatc
 /// Given
 /// \code
 ///   typedef int X;
-//using Y = int;
+///   using Y = int;
 /// \endcode
 /// typedefDecl()
 ///   matches "typedef int X", but not "using Y = int"
@@ -174,7 +174,7 @@ const internal::VariadicDynCastAllOfMatc
 /// Given
 /// \code
 ///   typedef int X;
-//using Y = int;
+///   using Y = int;
 /// \endcode
 /// typedefNameDecl()
 ///   matches "typedef int X" and "using Y = int"
@@ -186,7 +186,7 @@ const internal::VariadicDynCastAllOfMatc
 /// Given
 /// \code
 ///   typedef int X;
-//using Y = int;
+///   using Y = int;
 /// \endcode
 /// typeAliasDecl()
 ///   matches "using Y = int", but not "typedef int X"


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

Re: [PATCH] D19146: [clang-tidy] New checker to detect suspicious string constructor.

[Etienne Bergeron via cfe-commits]

etienneb updated this revision to Diff 53895.
etienneb added a comment.

add missing unittest for large length parameter


http://reviews.llvm.org/D19146

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/StringConstructorCheck.cpp
  clang-tidy/misc/StringConstructorCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-string-constructor.rst
  test/clang-tidy/misc-string-constructor.cpp

Index: test/clang-tidy/misc-string-constructor.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-string-constructor.cpp
@@ -0,0 +1,54 @@
+// RUN: %check_clang_tidy %s misc-string-constructor %t
+
+namespace std {
+template 
+class allocator {};
+template 
+class char_traits {};
+template , typename A = std::allocator >
+struct basic_string {
+  basic_string();
+  basic_string(const C*, unsigned int size);
+  basic_string(unsigned int size, C c);
+};
+typedef basic_string string;
+typedef basic_string wstring;
+}
+
+const char* kText = "";
+const char kText2[] = "";
+extern const char kText3[];
+
+void Test() {
+  std::string str('x', 4);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor parameters are probably swapped [misc-string-constructor]
+  std::wstring wstr(L'x', 4);
+  // CHECK-MESSAGES: [[@LINE-1]]:16: warning: constructor parameters are probably swapped
+  std::string s0(0, 'x');
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor creating an empty string
+  std::string s1(-4, 'x');
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: negative value used as length parameter
+  std::string s2(0x100, 'x');
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: suspicious large length parameter
+  
+  std::string q0("test", 0);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor creating an empty string
+  std::string q1(kText, -4);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: negative value used as length parameter
+  std::string q2("test", 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+  std::string q3(kText, 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+  std::string q4(kText2, 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+  std::string q5(kText3,  0x100);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: suspicious large length parameter
+}
+
+void Valid() {
+  std::string empty();
+  std::string str(4, 'x');
+  std::wstring wstr(4, L'x');
+  std::string s1("test", 4);
+  std::string s2("test", 3);
+}
Index: docs/clang-tidy/checks/misc-string-constructor.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-string-constructor.rst
@@ -0,0 +1,36 @@
+.. title:: clang-tidy - misc-string-constructor
+
+misc-string-constructor
+===
+
+Finds string constructors that are suspicious and probably errors.
+
+
+A common mistake is to swap parameters to the 'fill' string-constructor.
+
+Examples:
+
+.. code:: c++
+
+  std::string('x', 50) str; // should be std::string(50, 'x') 
+
+
+Calling the string-literal constructor with a length bigger than the literal is
+suspicious and adds extra random characters to the string.
+
+Examples:
+
+.. code:: c++
+
+  std::string("test", 200);   // Will include random characters after "test".
+
+
+Creating an empty string from constructors with parameters is considered
+suspicious. The programmer should use the empty constructor instead.
+
+Examples:
+
+.. code:: c++
+
+  std::string("test", 0);   // Creation of an empty string.
+
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -67,6 +67,7 @@
misc-non-copyable-objects
misc-sizeof-container
misc-static-assert
+   misc-string-constructor
misc-string-integer-assignment
misc-string-literal-with-embedded-nul
misc-suspicious-missing-comma
Index: clang-tidy/misc/StringConstructorCheck.h
===
--- /dev/null
+++ clang-tidy/misc/StringConstructorCheck.h
@@ -0,0 +1,39 @@
+//===--- StringConstructorCheck.h - clang-tidy---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_STRING_CONSTRUCTOR_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_STRING_CONSTRUCTOR_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+/// Finds suspicious string constructor and check their parameters.
+///
+/// For the user-facing documentation see:
+/// http://cla

Re: [PATCH] D19146: [clang-tidy] New checker to detect suspicious string constructor.

[Etienne Bergeron via cfe-commits]

etienneb updated this revision to Diff 53894.
etienneb added a comment.

fix unittests


http://reviews.llvm.org/D19146

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/StringConstructorCheck.cpp
  clang-tidy/misc/StringConstructorCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-string-constructor.rst
  test/clang-tidy/misc-string-constructor.cpp

Index: test/clang-tidy/misc-string-constructor.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-string-constructor.cpp
@@ -0,0 +1,50 @@
+// RUN: %check_clang_tidy %s misc-string-constructor %t
+
+namespace std {
+template 
+class allocator {};
+template 
+class char_traits {};
+template , typename A = std::allocator >
+struct basic_string {
+  basic_string();
+  basic_string(const C*, unsigned int size);
+  basic_string(unsigned int size, C c);
+};
+typedef basic_string string;
+typedef basic_string wstring;
+}
+
+const char* kText = "";
+const char kText2[] = "";
+extern const char kText3[];
+
+void Test() {
+  std::string str('x', 4);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor parameters are probably swapped [misc-string-constructor]
+  std::wstring wstr(L'x', 4);
+  // CHECK-MESSAGES: [[@LINE-1]]:16: warning: constructor parameters are probably swapped
+  std::string s0(0, 'x');
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor creating an empty string
+  std::string s1(-4, 'x');
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: negative value used as length parameter
+  
+  std::string q0("test", 0);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor creating an empty string
+  std::string q1(kText, -4);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: negative value used as length parameter
+  std::string q2("test", 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+  std::string q3(kText, 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+  std::string q4(kText2, 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+}
+
+void Valid() {
+  std::string empty();
+  std::string str(4, 'x');
+  std::wstring wstr(4, L'x');
+  std::string s1("test", 4);
+  std::string s2("test", 3);
+}
Index: docs/clang-tidy/checks/misc-string-constructor.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-string-constructor.rst
@@ -0,0 +1,36 @@
+.. title:: clang-tidy - misc-string-constructor
+
+misc-string-constructor
+===
+
+Finds string constructors that are suspicious and probably errors.
+
+
+A common mistake is to swap parameters to the 'fill' string-constructor.
+
+Examples:
+
+.. code:: c++
+
+  std::string('x', 50) str; // should be std::string(50, 'x') 
+
+
+Calling the string-literal constructor with a length bigger than the literal is
+suspicious and adds extra random characters to the string.
+
+Examples:
+
+.. code:: c++
+
+  std::string("test", 200);   // Will include random characters after "test".
+
+
+Creating an empty string from constructors with parameters is considered
+suspicious. The programmer should use the empty constructor instead.
+
+Examples:
+
+.. code:: c++
+
+  std::string("test", 0);   // Creation of an empty string.
+
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -67,6 +67,7 @@
misc-non-copyable-objects
misc-sizeof-container
misc-static-assert
+   misc-string-constructor
misc-string-integer-assignment
misc-string-literal-with-embedded-nul
misc-suspicious-missing-comma
Index: clang-tidy/misc/StringConstructorCheck.h
===
--- /dev/null
+++ clang-tidy/misc/StringConstructorCheck.h
@@ -0,0 +1,39 @@
+//===--- StringConstructorCheck.h - clang-tidy---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_STRING_CONSTRUCTOR_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_STRING_CONSTRUCTOR_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+/// Finds suspicious string constructor and check their parameters.
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/misc-string-constructor.html
+class StringConstructorCheck : public ClangTidyCheck {
+public:
+  StringConstructorCheck(StringRef Name, ClangTidyContext *Context);
+  void storeOptions(ClangTidyOptions::OptionMap &Opts);
+  void regis

Re: [PATCH] D18136: boost-use-to-string check

[Piotr Padlewski via cfe-commits]

Prazek updated the summary for this revision.
Prazek updated this revision to Diff 53891.
Prazek added a comment.

Small tests update. Ping me when your patch will be in trunk


http://reviews.llvm.org/D18136

Files:
  clang-tidy/boost/BoostTidyModule.cpp
  clang-tidy/boost/CMakeLists.txt
  clang-tidy/boost/UseToStringCheck.cpp
  clang-tidy/boost/UseToStringCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/boost-use-to-string.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/boost-use-to-string.cpp

Index: test/clang-tidy/boost-use-to-string.cpp
===
--- /dev/null
+++ test/clang-tidy/boost-use-to-string.cpp
@@ -0,0 +1,154 @@
+// RUN: %check_clang_tidy %s boost-use-to-string %t
+
+
+namespace std {
+
+template  class basic_string {};
+
+using string = basic_string;
+using wstring = basic_string;
+}
+
+namespace boost {
+template 
+T lexical_cast(const V&) {
+  return T();
+};
+}
+
+struct my_weird_type {};
+
+std::string fun(const std::string &) {}
+
+void test_to_string1() {
+
+  auto xa = boost::lexical_cast(5);
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use std::to_string instead of boost::lexical_cast [boost-use-to-string]
+// CHECK-FIXES: auto xa = std::to_string(5);
+
+ auto z = boost::lexical_cast(42LL);
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: use std::to_string {{..}}
+// CHECK-FIXES: auto z = std::to_string(42LL);
+
+  // this should not trigger
+  fun(boost::lexical_cast(42.0));
+  auto non = boost::lexical_cast(42);
+  boost::lexical_cast("12");
+}
+
+void test_to_string2() {
+  int a;
+  long b;
+  long long c;
+  unsigned d;
+  unsigned long e;
+  unsigned long long f;
+  float g;
+  double h;
+  long double i;
+  bool j;
+
+  fun(boost::lexical_cast(a));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_string {{..}}
+// CHECK-FIXES: fun(std::to_string(a));
+  fun(boost::lexical_cast(b));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_string {{..}}
+// CHECK-FIXES: fun(std::to_string(b));
+  fun(boost::lexical_cast(c));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_string {{..}}
+// CHECK-FIXES: fun(std::to_string(c));
+  fun(boost::lexical_cast(d));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_string {{..}}
+// CHECK-FIXES: fun(std::to_string(d));
+  fun(boost::lexical_cast(e));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_string {{..}}
+// CHECK-FIXES: fun(std::to_string(e));
+  fun(boost::lexical_cast(f));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_string {{..}}
+// CHECK-FIXES: fun(std::to_string(f));
+
+  // No change for floating numbers.
+  fun(boost::lexical_cast(g));
+  fun(boost::lexical_cast(h));
+  fun(boost::lexical_cast(i));
+  // And bool.
+  fun(boost::lexical_cast(j));
+}
+
+std::string fun(const std::wstring &) {}
+
+void test_to_wstring() {
+  int a;
+  long b;
+  long long c;
+  unsigned d;
+  unsigned long e;
+  unsigned long long f;
+  float g;
+  double h;
+  long double i;
+  bool j;
+
+  fun(boost::lexical_cast(a));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_wstring instead of boost::lexical_cast [boost-use-to-string]
+// CHECK-FIXES: fun(std::to_wstring(a));
+  fun(boost::lexical_cast(b));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_wstring {{..}}
+// CHECK-FIXES: fun(std::to_wstring(b));
+  fun(boost::lexical_cast(c));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_wstring {{..}}
+// CHECK-FIXES: fun(std::to_wstring(c));
+  fun(boost::lexical_cast(d));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_wstring {{..}}
+// CHECK-FIXES: fun(std::to_wstring(d));
+  fun(boost::lexical_cast(e));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_wstring {{..}}
+// CHECK-FIXES: fun(std::to_wstring(e));
+  fun(boost::lexical_cast(f));
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::to_wstring {{..}}
+// CHECK-FIXES: fun(std::to_wstring(f));
+
+  // No change for floating numbers
+  fun(boost::lexical_cast(g));
+  fun(boost::lexical_cast(h));
+  fun(boost::lexical_cast(i));
+  // and bool.
+  fun(boost::lexical_cast(j));
+}
+
+const auto glob = boost::lexical_cast(42);
+// CHECK-MESSAGES: :[[@LINE-1]]:19: warning: use std::to_string{{..}}
+// CHECK-FIXES: const auto glob = std::to_string(42);
+
+template 
+void string_as_T(T t = T()) {
+  boost::lexical_cast(42);
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: use std::to_string{{..}}
+// CHECK-FIXES: std::to_string(42);
+
+  boost::lexical_cast(42);
+  string_as_T(boost::lexical_cast(42));
+  auto p = boost::lexical_cast(42);
+  auto p2 = (T)boost::lexical_cast(42);
+  auto p3 = static_cast(boost::lexical_cast(42));
+}
+
+#define my_to_string boost::lexical_cast
+
+void no_fixup_inside_macro() {
+  my_to_string(12);
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: use std::to_string{{..}}
+
+}
+
+void no_warnings() {
+  fun(boost::lexical_cast("abc"));
+  fun(boost::lexical_cast("abc"));
+  fun(boost::lexical_cast(my_weird_type{}

Re: [PATCH] D19146: [clang-tidy] New checker to detect suspicious string constructor.

[Etienne Bergeron via cfe-commits]

etienneb updated this revision to Diff 53892.
etienneb marked 2 inline comments as done.
etienneb added a comment.

alexfh comments.


http://reviews.llvm.org/D19146

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/StringConstructorCheck.cpp
  clang-tidy/misc/StringConstructorCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-string-constructor.rst
  test/clang-tidy/misc-string-constructor.cpp

Index: test/clang-tidy/misc-string-constructor.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-string-constructor.cpp
@@ -0,0 +1,50 @@
+// RUN: %check_clang_tidy %s misc-string-constructor %t
+
+namespace std {
+template 
+class allocator {};
+template 
+class char_traits {};
+template , typename A = std::allocator >
+struct basic_string {
+  basic_string();
+  basic_string(const C*, unsigned int size);
+  basic_string(unsigned int size, C c);
+};
+typedef basic_string string;
+typedef basic_string wstring;
+}
+
+const char* kText = "";
+const char kText2[] = "";
+extern const char kText3[];
+
+void Test() {
+  std::string str('x', 4);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor parameters are probably swapped [misc-string-constructor]
+  std::wstring wstr(L'x', 4);
+  // CHECK-MESSAGES: [[@LINE-1]]:16: warning: constructor parameters are probably swapped
+  std::string s0(0, 'x');
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor creating an empty string
+  std::string s1(-4, 'x');
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: negative value used as length parameter
+  
+  std::string q0("test", 0);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor creating an empty string
+  std::string q1(kText, -4);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: negative value used as length parameter
+  std::string q2("test", 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+  std::string q3(kText, 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+  std::string q4(kText2, 200);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: length is bigger then string literal size
+}
+
+void Valid() {
+  std::string empty();
+  std::string str(4, 'x');
+  std::wstring wstr(4, L'x');
+  std::string s1("test", 4);
+  std::string s2("test", 3);
+}
Index: docs/clang-tidy/checks/misc-string-constructor.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-string-constructor.rst
@@ -0,0 +1,36 @@
+.. title:: clang-tidy - misc-string-constructor
+
+misc-string-constructor
+===
+
+Finds string constructors that are suspicious and probably errors.
+
+
+A common mistake is to swap parameters to the 'fill' string-constructor.
+
+Examples:
+
+.. code:: c++
+
+  std::string('x', 50) str; // should be std::string(50, 'x') 
+
+
+Calling the string-literal constructor with a length bigger than the literal is
+suspicious and adds extra random characters to the string.
+
+Examples:
+
+.. code:: c++
+
+  std::string("test", 200);   // Will include random characters after "test".
+
+
+Creating an empty string from constructors with parameters is considered
+suspicious. The programmer should use the empty constructor instead.
+
+Examples:
+
+.. code:: c++
+
+  std::string("test", 0);   // Creation of an empty string.
+
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -67,6 +67,7 @@
misc-non-copyable-objects
misc-sizeof-container
misc-static-assert
+   misc-string-constructor
misc-string-integer-assignment
misc-string-literal-with-embedded-nul
misc-suspicious-missing-comma
Index: clang-tidy/misc/StringConstructorCheck.h
===
--- /dev/null
+++ clang-tidy/misc/StringConstructorCheck.h
@@ -0,0 +1,39 @@
+//===--- StringConstructorCheck.h - clang-tidy---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_STRING_CONSTRUCTOR_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_STRING_CONSTRUCTOR_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+/// Finds suspicious string constructor and check their parameters.
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/misc-string-constructor.html
+class StringConstructorCheck : public ClangTidyCheck {
+public:
+  StringConstructorCheck(StringRef Name, ClangTidyContext *Context);
+  void storeOptions(Cla

r266431 - Revert r266415, it broke parsing SDK headers (PR27367).

[Nico Weber via cfe-commits]

Author: nico
Date: Fri Apr 15 09:35:06 2016
New Revision: 266431

URL: http://llvm.org/viewvc/llvm-project?rev=266431&view=rev
Log:
Revert r266415, it broke parsing SDK headers (PR27367).

Modified:
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/Basic/AddressSpaces.h
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Sema/DeclSpec.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/lib/AST/TypePrinter.cpp
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Parse/ParseTentative.cpp
cfe/trunk/lib/Sema/DeclSpec.cpp
cfe/trunk/lib/Sema/SemaCodeComplete.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaDeclObjC.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp
cfe/trunk/test/Sema/MicrosoftExtensions.c
cfe/trunk/test/Sema/address_spaces.c
cfe/trunk/test/Sema/invalid-assignment-constant-address-space.c
cfe/trunk/test/SemaCXX/MicrosoftExtensions.cpp

Modified: cfe/trunk/include/clang/AST/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=266431&r1=266430&r2=266431&view=diff
==
--- cfe/trunk/include/clang/AST/Type.h (original)
+++ cfe/trunk/include/clang/AST/Type.h Fri Apr 15 09:35:06 2016
@@ -152,8 +152,8 @@ public:
 
   enum {
 /// The maximum supported address space number.
-/// 23 bits should be enough for anyone.
-MaxAddressSpace = 0x7fu,
+/// 24 bits should be enough for anyone.
+MaxAddressSpace = 0xffu,
 
 /// The width of the "fast" qualifier mask.
 FastWidth = 3,
@@ -265,13 +265,6 @@ public:
 Mask |= mask;
   }
 
-  bool hasUnaligned() const { return Mask & UMask; }
-  void setUnaligned(bool flag) {
-Mask = (Mask & ~UMask) | (flag ? UMask : 0);
-  }
-  void removeUnaligned() { Mask &= ~UMask; }
-  void addUnaligned() { Mask |= UMask; }
-
   bool hasObjCGCAttr() const { return Mask & GCAttrMask; }
   GC getObjCGCAttr() const { return GC((Mask & GCAttrMask) >> GCAttrShift); }
   void setObjCGCAttr(GC type) {
@@ -440,9 +433,7 @@ public:
// ObjC lifetime qualifiers must match exactly.
getObjCLifetime() == other.getObjCLifetime() &&
// CVR qualifiers may subset.
-   (((Mask & CVRMask) | (other.Mask & CVRMask)) == (Mask & CVRMask)) &&
-   // U qualifier may superset.
-   (!(other.Mask & UMask) || (Mask & UMask));
+   (((Mask & CVRMask) | (other.Mask & CVRMask)) == (Mask & CVRMask));
   }
 
   /// \brief Determines if these qualifiers compatibly include another set of
@@ -510,19 +501,16 @@ public:
 
 private:
 
-  // bits: |0 1 2|3|4 .. 5|6  ..  8|9   ...   31|
-  //   |C R V|U|GCAttr|Lifetime|AddressSpace|
+  // bits: |0 1 2|3 .. 4|5  ..  7|8   ...   31|
+  //   |C R V|GCAttr|Lifetime|AddressSpace|
   uint32_t Mask;
 
-  static const uint32_t UMask = 0x8;
-  static const uint32_t UShift = 3;
-  static const uint32_t GCAttrMask = 0x30;
-  static const uint32_t GCAttrShift = 4;
-  static const uint32_t LifetimeMask = 0x1C0;
-  static const uint32_t LifetimeShift = 6;
-  static const uint32_t AddressSpaceMask =
-  ~(CVRMask | UMask | GCAttrMask | LifetimeMask);
-  static const uint32_t AddressSpaceShift = 9;
+  static const uint32_t GCAttrMask = 0x18;
+  static const uint32_t GCAttrShift = 3;
+  static const uint32_t LifetimeMask = 0xE0;
+  static const uint32_t LifetimeShift = 5;
+  static const uint32_t AddressSpaceMask = ~(CVRMask|GCAttrMask|LifetimeMask);
+  static const uint32_t AddressSpaceShift = 8;
 };
 
 /// A std::pair-like structure for storing a qualified type split

Modified: cfe/trunk/include/clang/Basic/AddressSpaces.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AddressSpaces.h?rev=266431&r1=266430&r2=266431&view=diff
==
--- cfe/trunk/include/clang/Basic/AddressSpaces.h (original)
+++ cfe/trunk/include/clang/Basic/AddressSpaces.h Fri Apr 15 09:35:06 2016
@@ -25,7 +25,7 @@ namespace LangAS {
 /// This uses a high starting offset so as not to conflict with any address
 /// space used by a target.
 enum ID {
-  Offset = 0x7FFF00,
+  Offset = 0x00,
 
   opencl_global = Offset,
   opencl_local,

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=266431&r1=266430&r2=266431&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Fri Apr 15 09:35:06 2016
@@ -2149,6 +2149,10 @@ def InitSeg : Attr {
   }];
 }
 
+def Unaligned : IgnoredAttr {
+  let Spellings = [Keyword<"__unaligned">];
+}
+
 def LoopHint : Attr {
   /// #pragma clang loop  directive

Re: [PATCH] D19071: [OpenCL] Add predefined macros.

[Yaxun Liu via cfe-commits]

yaxunl marked 6 inline comments as done.


Comment at: lib/Frontend/InitPreprocessor.cpp:426
@@ +425,3 @@
+case 110:
+  Builder.defineMacro("__CLANG_OPENCL_C_VERSION__", "110");
+  break;

Anastasia wrote:
> So why we can't use unified __OPENCL_C_VERSION__?
`__OPENCL_C_VERSION__` is not defined in OpenCL spec v1.0 and 1.1.


Comment at: lib/Frontend/InitPreprocessor.cpp:438
@@ +437,3 @@
+Builder.defineMacro("CL_VERSION_1_0", "100");
+if (LangOpts.OpenCLVersion >= 110)
+  Builder.defineMacro("CL_VERSION_1_1", "110");

Anastasia wrote:
> I am not sure we should add this conditionally though. If you want to compile 
> CL code like this (forcing pointer to point to private AS for all CL versions 
> the code is compiled for):
> 
>   #if __OPENCL_C_VERSION__ >= CL_VERSION_2_0
>   private void* priv_ptr;
>   #else
>   void* priv_ptr;
>   #endif
> 
> This code would fail with -cl-sdt=CL1.1 (because CL_VERSION_2_0 is no longer 
> defined), but the purpose of having version macros is to be able to condition 
> on the passed CL version in the particular compilation run to avoid the 
> compiler failure/miscompilation. This way we provide a way to select the 
> right CL code for all versions the code is being compiled (if such selection 
> is needed) to allow portability of CL code among OpenCL version.
CL_VERSION_x_y is only defined in OpenCL spec version equal or above x.y.

We can use macros like

  #if defined(__OPENCL_C_VERSION__) && defined(CL_VERSION_2_0) && 
__OPENCL_C_VERSION__ >= CL_VERSION_2_0
  #define _CL20_AND_ABOVE 1
  #endif



Comment at: lib/Frontend/InitPreprocessor.cpp:439
@@ +438,3 @@
+if (LangOpts.OpenCLVersion >= 110)
+  Builder.defineMacro("CL_VERSION_1_1", "110");
+if (LangOpts.OpenCLVersion >= 120)

yaxunl wrote:
> pxli168 wrote:
> > These macros maybe need for all cl version, and in the header we should 
> > compare  __OPENCL_C_VERSION__ with CL_VERSION_2_0 instead of the integer 
> > 200 in the header of  http://reviews.llvm.org/D18369? 
> Each OpenCL version only defines some of these macros by spec.
> 
> In the header file `__OPENCL_C_VERSION__` can compare with 200 since the spec 
> defines the integer value for `__OPENCL_C_VERSION__`. Comparing with 
> CL_VERSION_2_0 requires checking CL_VERSION_2_0 is available first. I think 
> probably I can define a macro 
> 
>   #define _OPENCL20_AND_ABOVE defined(__OPENCL_C_VERSION__) and 
> defined(CL_VERSION_2_0) and __OPENCL_C_VERSION__ >= 200
> 
> and then use this macro for conditioning 2.0 specific functions.
should be

  #if defined(__OPENCL_C_VERSION__) && defined(CL_VERSION_2_0) && 
__OPENCL_C_VERSION__ >= CL_VERSION_2_0
  #define _CL20_AND_ABOVE 1
  #endif



http://reviews.llvm.org/D19071



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

[libclc] r266430 - prepare-builtins: Remove call to getGlobalContext()

[Tom Stellard via cfe-commits]

Author: tstellar
Date: Fri Apr 15 09:18:58 2016
New Revision: 266430

URL: http://llvm.org/viewvc/llvm-project?rev=266430&view=rev
Log:
prepare-builtins: Remove call to getGlobalContext()

This function has been removed from LLVM.

Patch By: Laurent Carlier

Modified:
libclc/trunk/utils/prepare-builtins.cpp

Modified: libclc/trunk/utils/prepare-builtins.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/utils/prepare-builtins.cpp?rev=266430&r1=266429&r2=266430&view=diff
==
--- libclc/trunk/utils/prepare-builtins.cpp (original)
+++ libclc/trunk/utils/prepare-builtins.cpp Fri Apr 15 09:18:58 2016
@@ -24,7 +24,7 @@ OutputFilename("o", cl::desc("Output fil
cl::value_desc("filename"));
 
 int main(int argc, char **argv) {
-  LLVMContext &Context = getGlobalContext();
+  LLVMContext Context;
   llvm_shutdown_obj Y;  // Call llvm_shutdown() on exit.
 
   cl::ParseCommandLineOptions(argc, argv, "libclc builtin preparation tool\n");


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

Re: r266186 - Enable support for __float128 in Clang

[Nico Weber via cfe-commits]

On Fri, Apr 15, 2016 at 12:27 AM, Hal Finkel  wrote:

> - Original Message -
> > From: "Hans Wennborg via cfe-commits" 
> > To: "Nemanja Ivanovic" , "Nico Weber" <
> tha...@chromium.org>
> > Cc: "cfe-commits" 
> > Sent: Thursday, April 14, 2016 8:07:58 PM
> > Subject: Re: r266186 - Enable support for __float128 in Clang
> >
> > On Wed, Apr 13, 2016 at 2:49 AM, Nemanja Ivanovic via cfe-commits
> >  wrote:
> > > Author: nemanjai
> > > Date: Wed Apr 13 04:49:45 2016
> > > New Revision: 266186
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=266186&view=rev
> > > Log:
> > > Enable support for __float128 in Clang
> > >
> > > This patch corresponds to review:
> > > http://reviews.llvm.org/D15120
> > >
> > > It adds support for the __float128 keyword, literals and a target
> > > feature to
> > > enable it. This support is disabled by default on all targets and
> > > any target
> > > that has support for this type is free to add it.
> > >
> > > Based on feedback that I've received from target maintainers, this
> > > appears to
> > > be the right thing for most targets. I have not heard from the
> > > maintainers of
> > > X86 which I believe supports this type. I will subsequently
> > > investigate the
> > > impact of enabling this on X86.
> >
> > We're seeing build errors when targeting Android, which I think may
> > be
> > caused by this:
> >
> > [...]
> > In file included from ../../v8/src/base/functional.cc:11:
> > In file included from ../../v8/src/base/functional.h:13:
> > In file included from
> >
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/functional:55:
> > In file included from
> > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/tuple:38:
> > In file included from
> > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/utility:70:
> > In file included from
> >
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_pair.h:59:
> > In file included from
> >
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/move.h:57:
> >
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:269:39:
> > error: __float128 is not supported on this target
> > struct __is_floating_point_helper<__float128>
> >   ^
> >
> > (From
> >
> https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng/builds/54128/steps/compile%20%28with%20patch%29/logs/stdio
> )
> >
> > Any idea what might be breaking here?
>
> Yep, see: http://reviews.llvm.org/D19125


Since this is breaking real-world code, is it possible to revert this until
http://reviews.llvm.org/D19125 is ready?


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

Re: [PATCH] D19146: [clang-tidy] New checker to detect suspicious string constructor.

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

In http://reviews.llvm.org/D19146#402410, @alexfh wrote:

> I wonder whether `misc-swapped-arguments` can be tuned to handle these cases 
> in a more generic way? The only missing part so far seems to be the lack of 
> `cxxConstructExpr` support.


And by "these cases" I mean the swapped arguments mistake, not the more 
string-specific ones.


http://reviews.llvm.org/D19146



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

Re: [PATCH] D19146: [clang-tidy] New checker to detect suspicious string constructor.

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

I wonder whether `misc-swapped-arguments` can be tuned to handle these cases in 
a more generic way? The only missing part so far seems to be the lack of 
`cxxConstructExpr` support.



Comment at: clang-tidy/misc/StringConstructorCheck.cpp:104
@@ +103,3 @@
+  Finder->addMatcher(
+  cxxConstructExpr(LiteralStringConstructor, hasArgument(1, ZeroExpr))
+  .bind("empty-string"),

It seems to be wasteful to have several matchers sharing a bunch checks (the 
`LiteralStringConstructor` part). I'd suggest to merge the matchers and use 
anyOf to handle different sub-cases:
  cxxConstructExpr(hasDeclaration(cxxMethodDecl(hasName("basic_string"))),
   hasArgument(0, hasType(CharPtrType)),
   hasArgument(1, hasType(isInteger())),
   anyOf(cxxConstructExpr(hasArgument(1, 
ZeroExpr)).bind("empty-string"),
 cxxConstructExpr(...).bind("case2"), ...)


Comment at: docs/clang-tidy/checks/misc-string-constructor.rst:15
@@ +14,3 @@
+
+  std::string('x', 50) str // should be std::string(50, 'x') 
+

nit: add a semicolon


http://reviews.llvm.org/D19146



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

Re: r266415 - [MSVC Compat] Implementation of __unaligned (MS extension) as a type qualifier

[Nico Weber via cfe-commits]

This very likely caused https://llvm.org/bugs/show_bug.cgi?id=27367

On Fri, Apr 15, 2016 at 4:03 AM, Andrey Bokhanko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: asbokhan
> Date: Fri Apr 15 03:03:51 2016
> New Revision: 266415
>
> URL: http://llvm.org/viewvc/llvm-project?rev=266415&view=rev
> Log:
> [MSVC Compat] Implementation of __unaligned (MS extension) as a type
> qualifier
>
> This patch implements __unaligned as a type qualifier; before that, it was
> modeled as an attribute. Proper mangling of __unaligned is implemented as
> well.
> Some OpenCL code/tests are tangenially affected, as they relied on existing
> number and sizes of type qualifiers.
>
> Differential Revision: http://reviews.llvm.org/D18596
>
> Modified:
> cfe/trunk/include/clang/AST/Type.h
> cfe/trunk/include/clang/Basic/AddressSpaces.h
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Sema/DeclSpec.h
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/AST/MicrosoftMangle.cpp
> cfe/trunk/lib/AST/TypePrinter.cpp
> cfe/trunk/lib/Parse/ParseDecl.cpp
> cfe/trunk/lib/Parse/ParseTentative.cpp
> cfe/trunk/lib/Sema/DeclSpec.cpp
> cfe/trunk/lib/Sema/SemaCodeComplete.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaDeclObjC.cpp
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/lib/Sema/SemaType.cpp
> cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp
> cfe/trunk/test/Sema/MicrosoftExtensions.c
> cfe/trunk/test/Sema/address_spaces.c
> cfe/trunk/test/Sema/invalid-assignment-constant-address-space.c
> cfe/trunk/test/SemaCXX/MicrosoftExtensions.cpp
>
> Modified: cfe/trunk/include/clang/AST/Type.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=266415&r1=266414&r2=266415&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/Type.h (original)
> +++ cfe/trunk/include/clang/AST/Type.h Fri Apr 15 03:03:51 2016
> @@ -152,8 +152,8 @@ public:
>
>enum {
>  /// The maximum supported address space number.
> -/// 24 bits should be enough for anyone.
> -MaxAddressSpace = 0xffu,
> +/// 23 bits should be enough for anyone.
> +MaxAddressSpace = 0x7fu,
>
>  /// The width of the "fast" qualifier mask.
>  FastWidth = 3,
> @@ -265,6 +265,13 @@ public:
>  Mask |= mask;
>}
>
> +  bool hasUnaligned() const { return Mask & UMask; }
> +  void setUnaligned(bool flag) {
> +Mask = (Mask & ~UMask) | (flag ? UMask : 0);
> +  }
> +  void removeUnaligned() { Mask &= ~UMask; }
> +  void addUnaligned() { Mask |= UMask; }
> +
>bool hasObjCGCAttr() const { return Mask & GCAttrMask; }
>GC getObjCGCAttr() const { return GC((Mask & GCAttrMask) >>
> GCAttrShift); }
>void setObjCGCAttr(GC type) {
> @@ -433,7 +440,9 @@ public:
> // ObjC lifetime qualifiers must match exactly.
> getObjCLifetime() == other.getObjCLifetime() &&
> // CVR qualifiers may subset.
> -   (((Mask & CVRMask) | (other.Mask & CVRMask)) == (Mask &
> CVRMask));
> +   (((Mask & CVRMask) | (other.Mask & CVRMask)) == (Mask &
> CVRMask)) &&
> +   // U qualifier may superset.
> +   (!(other.Mask & UMask) || (Mask & UMask));
>}
>
>/// \brief Determines if these qualifiers compatibly include another
> set of
> @@ -501,16 +510,19 @@ public:
>
>  private:
>
> -  // bits: |0 1 2|3 .. 4|5  ..  7|8   ...   31|
> -  //   |C R V|GCAttr|Lifetime|AddressSpace|
> +  // bits: |0 1 2|3|4 .. 5|6  ..  8|9   ...   31|
> +  //   |C R V|U|GCAttr|Lifetime|AddressSpace|
>uint32_t Mask;
>
> -  static const uint32_t GCAttrMask = 0x18;
> -  static const uint32_t GCAttrShift = 3;
> -  static const uint32_t LifetimeMask = 0xE0;
> -  static const uint32_t LifetimeShift = 5;
> -  static const uint32_t AddressSpaceMask =
> ~(CVRMask|GCAttrMask|LifetimeMask);
> -  static const uint32_t AddressSpaceShift = 8;
> +  static const uint32_t UMask = 0x8;
> +  static const uint32_t UShift = 3;
> +  static const uint32_t GCAttrMask = 0x30;
> +  static const uint32_t GCAttrShift = 4;
> +  static const uint32_t LifetimeMask = 0x1C0;
> +  static const uint32_t LifetimeShift = 6;
> +  static const uint32_t AddressSpaceMask =
> +  ~(CVRMask | UMask | GCAttrMask | LifetimeMask);
> +  static const uint32_t AddressSpaceShift = 9;
>  };
>
>  /// A std::pair-like structure for storing a qualified type split
>
> Modified: cfe/trunk/include/clang/Basic/AddressSpaces.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AddressSpaces.h?rev=266415&r1=266414&r2=266415&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/AddressSpaces.h (original)
> +++ cfe/trunk/include/clang/Basic/AddressSpaces.h Fri Apr 15 03:03:51 2016
> @@ -25,7 +25,7 @@ namespace LangAS {
>  /// This uses a high st

r266428 - Remove include duplicate. NFC.

[Alexey Bader via cfe-commits]

Author: bader
Date: Fri Apr 15 08:23:26 2016
New Revision: 266428

URL: http://llvm.org/viewvc/llvm-project?rev=266428&view=rev
Log:
Remove include duplicate. NFC.

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

Modified: cfe/trunk/lib/Sema/SemaType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaType.cpp?rev=266428&r1=266427&r2=266428&view=diff
==
--- cfe/trunk/lib/Sema/SemaType.cpp (original)
+++ cfe/trunk/lib/Sema/SemaType.cpp Fri Apr 15 08:23:26 2016
@@ -24,7 +24,6 @@
 #include "clang/Basic/PartialDiagnostic.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Lex/Preprocessor.h"
-#include "clang/Lex/Preprocessor.h"
 #include "clang/Sema/DeclSpec.h"
 #include "clang/Sema/DelayedDiagnostic.h"
 #include "clang/Sema/Lookup.h"


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

Re: [PATCH] D18369: [OpenCL] Upstreaming khronos OpenCL header file.

[Alexey Bader via cfe-commits]

bader added a comment.

To clarify my last comment: I don't think we should define Image Query built-in 
functions only for 'read_only' access qualifier in OpenCL 1.x.
It's just bug in OpenCL 1.x specifications. I think the intention was to 
provide these built-in functions for both 'read_only' and 'write_only' images. 
OpenCL 2.0 also provides 'read_write' flavors.


http://reviews.llvm.org/D18369



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

Re: [PATCH] D18369: [OpenCL] Upstreaming khronos OpenCL header file.

[Alexey Bader via cfe-commits]

bader added inline comments.


Comment at: lib/Headers/opencl.h:15372-15373
@@ +15371,4 @@
+ */
+int __const_func __attribute__((overloadable)) get_image_width(image1d_t 
image);
+int __const_func __attribute__((overloadable)) 
get_image_width(image1d_buffer_t image);
+int __const_func __attribute__((overloadable)) get_image_width(image2d_t 
image);

Please, add image access qualifier to Built-in Image Query Functions 
declarations. It's required by OpenCL 2.0 specification.
OpenCL 1.x spec. defines built-in functions w/o access qualifiers (i.e. 
'read_only' is applied).


http://reviews.llvm.org/D18369



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

Re: [PATCH] D19146: [clang-tidy] New checker to detect suspicious string constructor.

[Aaron Ballman via cfe-commits]

On Thu, Apr 14, 2016 at 11:29 PM, Etienne Bergeron via cfe-commits
 wrote:
> etienneb created this revision.
> etienneb added a reviewer: alexfh.
> etienneb added a subscriber: cfe-commits.
>
> Checker to validate string constructor parameters.
>
> A common mistake is to swap parameter for the fill-constructor.
> ```
>   std::string str('x', 4);
>   std::string str('4', x);
> ```

Could this check be generalized to any function call expression
(including constructor calls, etc)? It seems to me that this pattern
is "one param is a char and an adjacent param is an integral type
other than char" that are conflated between the declaration and the
call, but in some regards, I kind of wonder if this could even be
applied to any two types that have an implicit conversion path between
them.

~Aaron

>
> http://reviews.llvm.org/D19146
>
> Files:
>   clang-tidy/misc/CMakeLists.txt
>   clang-tidy/misc/MiscTidyModule.cpp
>   clang-tidy/misc/StringConstructorCheck.cpp
>   clang-tidy/misc/StringConstructorCheck.h
>   docs/clang-tidy/checks/list.rst
>   docs/clang-tidy/checks/misc-string-constructor.rst
>   test/clang-tidy/misc-string-constructor.cpp
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D18953: [ms][dll] #26935 Defining a dllimport function should cause it to be exported

[Andrew V. Tischenko via cfe-commits]

avt77 changed the visibility of this Differential Revision from "All Users" to 
"Public (No Login Required)".
avt77 updated this revision to Diff 53870.
avt77 added a comment.

I fixed all issues discovered by Richard and Reid. As result the tests were 
updated as well. Please, review again.


http://reviews.llvm.org/D18953

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDecl.cpp
  test/CodeGen/dllimport.c
  test/CodeGenCXX/dllimport-members.cpp
  test/CodeGenCXX/dllimport.cpp
  test/Sema/dllimport.c
  test/SemaCXX/dllimport.cpp

Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -5505,9 +5505,13 @@
 
 static void checkDLLAttributeRedeclaration(Sema &S, NamedDecl *OldDecl,
NamedDecl *NewDecl,
-   bool IsSpecialization) {
-  if (TemplateDecl *OldTD = dyn_cast(OldDecl))
+   bool IsSpecialization,
+   bool IsDefinition) {
+  if (TemplateDecl *OldTD = dyn_cast(OldDecl)) {
 OldDecl = OldTD->getTemplatedDecl();
+if (!IsSpecialization)
+  IsDefinition = false;
+  }
   if (TemplateDecl *NewTD = dyn_cast(NewDecl))
 NewDecl = NewTD->getTemplatedDecl();
 
@@ -5563,30 +5567,43 @@
 
   // A redeclaration is not allowed to drop a dllimport attribute, the only
   // exceptions being inline function definitions, local extern declarations,
-  // and qualified friend declarations.
-  // NB: MSVC converts such a declaration to dllexport.
+  // qualified friend declarations or special MSVC extension: in the last case,
+  // the declaration is treated as if it were marked dllexport.
   bool IsInline = false, IsStaticDataMember = false, IsQualifiedFriend = false;
-  if (const auto *VD = dyn_cast(NewDecl))
+  bool IsMicrosoft = S.Context.getTargetInfo().getCXXABI().isMicrosoft();
+  if (const auto *VD = dyn_cast(NewDecl)) {
 // Ignore static data because out-of-line definitions are diagnosed
 // separately.
 IsStaticDataMember = VD->isStaticDataMember();
-  else if (const auto *FD = dyn_cast(NewDecl)) {
+IsDefinition = !VD->isThisDeclarationADefinition(S.Context) ==
+   VarDecl::DeclarationOnly;
+  } else if (const auto *FD = dyn_cast(NewDecl)) {
 IsInline = FD->isInlined();
 IsQualifiedFriend = FD->getQualifier() &&
 FD->getFriendObjectKind() == Decl::FOK_Declared;
   }
 
   if (OldImportAttr && !HasNewAttr && !IsInline && !IsStaticDataMember &&
   !NewDecl->isLocalExternDecl() && !IsQualifiedFriend) {
-S.Diag(NewDecl->getLocation(),
-   diag::warn_redeclaration_without_attribute_prev_attribute_ignored)
-  << NewDecl << OldImportAttr;
-S.Diag(OldDecl->getLocation(), diag::note_previous_declaration);
-S.Diag(OldImportAttr->getLocation(), diag::note_previous_attribute);
-OldDecl->dropAttr();
-NewDecl->dropAttr();
-  } else if (IsInline && OldImportAttr &&
- !S.Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+if (IsMicrosoft && IsDefinition) {
+  S.Diag(NewDecl->getLocation(),
+ diag::warn_redeclaration_without_import_attribute)
+  << NewDecl;
+  S.Diag(OldDecl->getLocation(), diag::note_previous_declaration);
+  NewDecl->dropAttr();
+  NewDecl->addAttr(::new (S.Context) DLLExportAttr(
+  NewImportAttr->getRange(), S.Context,
+  NewImportAttr->getSpellingListIndex()));
+} else {
+  S.Diag(NewDecl->getLocation(),
+ diag::warn_redeclaration_without_attribute_prev_attribute_ignored)
+  << NewDecl << OldImportAttr;
+  S.Diag(OldDecl->getLocation(), diag::note_previous_declaration);
+  S.Diag(OldImportAttr->getLocation(), diag::note_previous_attribute);
+  OldDecl->dropAttr();
+  NewDecl->dropAttr();
+}
+  } else if (IsInline && OldImportAttr && !IsMicrosoft) {
 // In MinGW, seeing a function declared inline drops the dllimport attribute.
 OldDecl->dropAttr();
 NewDecl->dropAttr();
@@ -6370,7 +6387,7 @@
   if (D.isRedeclaration() && !Previous.empty()) {
 checkDLLAttributeRedeclaration(
 *this, dyn_cast(Previous.getRepresentativeDecl()), NewVD,
-IsExplicitSpecialization);
+IsExplicitSpecialization, D.isFunctionDefinition());
   }
 
   if (NewTemplate) {
@@ -8369,7 +8386,8 @@
   if (D.isRedeclaration() && !Previous.empty()) {
 checkDLLAttributeRedeclaration(
 *this, dyn_cast(Previous.getRepresentativeDecl()), NewFD,
-isExplicitSpecialization || isFunctionTemplateSpecialization);
+isExplicitSpecialization || isFunctionTemplateSpecialization,
+D.isFunctionDefinition());
   }
 
   if (getLangOpts().CUDA) {
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/Diagnost