[PATCH] D40072: [libclang] Support querying whether a declaration is invalid

[Nikolai Kosjar via Phabricator via cfe-commits]

nik updated this revision to Diff 128491.
nik added a comment.

Had to rebase.


Repository:
  rC Clang

https://reviews.llvm.org/D40072

Files:
  include/clang-c/Index.h
  test/Index/print-type-size.cpp
  tools/c-index-test/c-index-test.c
  tools/libclang/CIndex.cpp
  tools/libclang/libclang.exports


Index: tools/libclang/libclang.exports
===
--- tools/libclang/libclang.exports
+++ tools/libclang/libclang.exports
@@ -290,6 +290,7 @@
 clang_isConstQualifiedType
 clang_isCursorDefinition
 clang_isDeclaration
+clang_isInvalidDeclaration
 clang_isExpression
 clang_isFileMultipleIncludeGuarded
 clang_isFunctionTypeVariadic
Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -5421,6 +5421,15 @@
  (K >= CXCursor_FirstExtraDecl && K <= CXCursor_LastExtraDecl);
 }
 
+unsigned clang_isInvalidDeclaration(CXCursor C) {
+  if (clang_isDeclaration(C.kind)) {
+if (const Decl *D = getCursorDecl(C))
+  return D->isInvalidDecl();
+  }
+
+  return 0;
+}
+
 unsigned clang_isReference(enum CXCursorKind K) {
   return K >= CXCursor_FirstRef && K <= CXCursor_LastRef;
 }
Index: tools/c-index-test/c-index-test.c
===
--- tools/c-index-test/c-index-test.c
+++ tools/c-index-test/c-index-test.c
@@ -812,6 +812,8 @@
   printf(" (variadic)");
 if (clang_Cursor_isObjCOptional(Cursor))
   printf(" (@optional)");
+if (clang_isInvalidDeclaration(Cursor))
+  printf(" (invalid)");
 
 switch (clang_getCursorExceptionSpecificationType(Cursor))
 {
Index: test/Index/print-type-size.cpp
===
--- test/Index/print-type-size.cpp
+++ test/Index/print-type-size.cpp
@@ -4,8 +4,8 @@
 
 namespace basic {
 
-// CHECK64: VarDecl=v:[[@LINE+2]]:6 (Definition) [type=void] [typekind=Void]
-// CHECK32: VarDecl=v:[[@LINE+1]]:6 (Definition) [type=void] [typekind=Void]
+// CHECK64: VarDecl=v:[[@LINE+2]]:6 (Definition) (invalid) [type=void] 
[typekind=Void]
+// CHECK32: VarDecl=v:[[@LINE+1]]:6 (Definition) (invalid) [type=void] 
[typekind=Void]
 void v;
 
 // CHECK64: VarDecl=v1:[[@LINE+2]]:7 (Definition) [type=void *] 
[typekind=Pointer] [sizeof=8] [alignof=8]
Index: include/clang-c/Index.h
===
--- include/clang-c/Index.h
+++ include/clang-c/Index.h
@@ -32,7 +32,7 @@
  * compatible, thus CINDEX_VERSION_MAJOR is expected to remain stable.
  */
 #define CINDEX_VERSION_MAJOR 0
-#define CINDEX_VERSION_MINOR 45
+#define CINDEX_VERSION_MINOR 46
 
 #define CINDEX_VERSION_ENCODE(major, minor) ( \
   ((major) * 1)   \
@@ -2641,6 +2641,16 @@
  */
 CINDEX_LINKAGE unsigned clang_isDeclaration(enum CXCursorKind);
 
+/**
+ * \brief Determine whether the given declaration is invalid.
+ *
+ * A declaration is invalid if it could not be parsed successfully.
+ *
+ * \returns non-zero if the cursor represents a declaration and it is
+ * invalid, otherwise NULL.
+ */
+CINDEX_LINKAGE unsigned clang_isInvalidDeclaration(CXCursor);
+
 /**
  * \brief Determine whether the given cursor kind represents a simple
  * reference.


Index: tools/libclang/libclang.exports
===
--- tools/libclang/libclang.exports
+++ tools/libclang/libclang.exports
@@ -290,6 +290,7 @@
 clang_isConstQualifiedType
 clang_isCursorDefinition
 clang_isDeclaration
+clang_isInvalidDeclaration
 clang_isExpression
 clang_isFileMultipleIncludeGuarded
 clang_isFunctionTypeVariadic
Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -5421,6 +5421,15 @@
  (K >= CXCursor_FirstExtraDecl && K <= CXCursor_LastExtraDecl);
 }
 
+unsigned clang_isInvalidDeclaration(CXCursor C) {
+  if (clang_isDeclaration(C.kind)) {
+if (const Decl *D = getCursorDecl(C))
+  return D->isInvalidDecl();
+  }
+
+  return 0;
+}
+
 unsigned clang_isReference(enum CXCursorKind K) {
   return K >= CXCursor_FirstRef && K <= CXCursor_LastRef;
 }
Index: tools/c-index-test/c-index-test.c
===
--- tools/c-index-test/c-index-test.c
+++ tools/c-index-test/c-index-test.c
@@ -812,6 +812,8 @@
   printf(" (variadic)");
 if (clang_Cursor_isObjCOptional(Cursor))
   printf(" (@optional)");
+if (clang_isInvalidDeclaration(Cursor))
+  printf(" (invalid)");
 
 switch (clang_getCursorExceptionSpecificationType(Cursor))
 {
Index: test/Index/print-type-size.cpp
===
--- test/Index/print-type-size.cpp
+++ test/Index/print-type-size.cpp
@@ -4,8 +4,8 @@
 
 namespace basic {
 
-// CHECK64: 

[PATCH] D40481: [libclang] Fix cursors for arguments of Subscript and Call operators

[Nikolai Kosjar via Phabricator via cfe-commits]

nik added a comment.

New year, new hope - ping :)


https://reviews.llvm.org/D40481



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

Re: trivial_abi

[John McCall via cfe-commits]

> On Jan 2, 2018, at 10:43 PM, Richard Smith  wrote:
> 
> On 2 January 2018 at 19:02, John McCall via cfe-commits 
> > wrote:
> 
>> On Jan 2, 2018, at 9:15 PM, Akira Hatanaka > > wrote:
>> 
>> 
>> 
>>> On Jan 2, 2018, at 4:56 PM, Richard Smith via cfe-commits 
>>> > wrote:
>>> 
>>> On 2 January 2018 at 15:33, John McCall via cfe-commits 
>>> > wrote:
>>> Hey, Richard et al.  Akira and I were talking about the right ABI rule for 
>>> deciding can-pass-in-registers-ness for structs in the presence of 
>>> trivial_abi, and I think I like Akira's approach but wanted to get your 
>>> input.
>>> 
>>> The current definition in Itanium is:
>>> 
>>>   non-trivial for the purposes of calls <>
>>>  <>
>>> A type is considered non-trivial for the purposes of calls if:
>>> 
>>> it has a non-trivial copy constructor, move constructor, or destructor, or
>>>  <>
>>> I'm assuming we're implicitly excluding deleted functions here. (I'd prefer 
>>> to make that explicit; this has been the source of a number of ABI 
>>> mismatches.)
>>> all of its copy and move constructors are deleted.
>>>  <>
>>> 
>>> I'd suggest modifying this to:
>>> 
>>> A type is considered non-trivial for the purposes of calls if:
>>> - if has a copy constructor, move constructor, or destructor 
>>> which is non-trivial for the purposes of calls, or
>>> - all of its copy and move constructors are deleted and it does 
>>> not have the trivial_abi attribute.
>>> 
>>> A copy/move constructor is considered trivial for the purposes of calls 
>>> if:
>>> - it is user-provided and
>>> - the class has the trivial_abi attribute and
>>> - a defaulted definition of the constructor would be 
>>> trivial for the purposes of calls; or
>>> 
>>> We'd need to say what happens if the function in question cannot validly be 
>>> defaulted for any of the reasons in [dcl.fct.def.default]. Do we try to 
>>> infer whether it's a copy or move constructor, and use the rules for a 
>>> defaulted copy or move constructor? Or do we just say that's never trivial 
>>> for the purposes of calls? Or something else? Eg:
>>> 
>>> struct [[clang::trivial_abi]] A {
>>>   A(A && = make());
>>> };
>>> 
>>> Here, A::A(A&&) cannot validly be defaulted. Is A trivial for the purpose 
>>> of calls? Likewise:
>>> 
>>> struct [[clang::trivial_abi]] B {
>>>   B(...);
>>> };
>>> struct C {
>>>   volatile B b;
>>> };
>>> 
>>> Here, C's copy constructor calls B::B(...). Is C trivial for the purpose of 
>>> calls? (OK, Clang crashes on that example today. But still...)
>>> 
>>> I'd be uncomfortable making the rules in [dcl.fct.def.default] part of the 
>>> ABI; they seem to be changing relatively frequently. Perhaps we could say 
>>> "if the function is a copy constructor ([class.copy.ctor]/1), then consider 
>>> what an implicitly-declared defaulted copy constructor would do; if it's a 
>>> move constructor ([class.copy.ctor]/2), then consider what an 
>>> implicitly-declared defaulted move constructor would do; otherwise, it's 
>>> not trivial for the purpose of calls". That'd mean A is trivial for the 
>>> purpose of calls and C is not, which I think is probably the right answer.
>>> 
>>> - it is not user-provided and
>>> - the class has no virtual functions and no virtual 
>>> base classes, and
>>> - the constructor used to copy/move each direct base 
>>> class subobject is trivial for the purposes of calls, and
>>> - for each non-static data member that is of class type 
>>> (or array thereof), the constructor selected to copy/move that member is 
>>> trivial for the purposes of calls.
>>> 
>>> A destructor is considered trivial for the purposes of calls if:
>>> - it is not user-provided or the class has the trivial_abi 
>>> attribute, and
>>> - the destructor is not virtual, and
>>> - all of the direct base classes of its class have destructors 
>>> that are trivial for the purposes of calls, and
>>> - for all of the non-static data members of its class that are 
>>> of class type (or array thereof), each such class is trivial for the 
>>> purposes of calls.
>>> 
>>> These definitions are intended to follow [class.copy.ctor]p11 and 
>>> [class.dtor]p6 except for the special rules applicable to trivial_abi 
>>> classes.
>>> 
>>> If I could rephrase: a *tor is considered trivial for for the purposes of 
>>> calls if it is either defaulted or the class has the trivial_abi attribute, 
>>> and the defaulted definition would satisfy the language rule for being 
>>> trivial but with the word "trivial" replaced by "trivial for the 

[libcxx] r321689 - Mark LWG2824 as complete. We already did it, but I added a test to be sure

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Jan  2 20:37:30 2018
New Revision: 321689

URL: http://llvm.org/viewvc/llvm-project?rev=321689=rev
Log:
Mark LWG2824 as complete. We already did it, but I added a test to be sure

Modified:
libcxx/trunk/test/std/containers/sequences/list/list.ops/sort_comp.pass.cpp
libcxx/trunk/www/cxx1z_status.html

Modified: 
libcxx/trunk/test/std/containers/sequences/list/list.ops/sort_comp.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/list/list.ops/sort_comp.pass.cpp?rev=321689=321688=321689=diff
==
--- libcxx/trunk/test/std/containers/sequences/list/list.ops/sort_comp.pass.cpp 
(original)
+++ libcxx/trunk/test/std/containers/sequences/list/list.ops/sort_comp.pass.cpp 
Tue Jan  2 20:37:30 2018
@@ -13,10 +13,29 @@
 
 #include 
 #include 
+#include   // for is_permutation
 #include 
 
 #include "min_allocator.h"
 
+
+#ifndef TEST_HAS_NO_EXCEPTIONS
+template 
+struct throwingLess {
+throwingLess() : num_(1) {}
+throwingLess(int num) : num_(num) {}
+
+bool operator() (const T& lhs, const T& rhs) const
+{
+if ( --num_ == 0) throw 1;
+return lhs < rhs;
+}
+
+mutable int num_;
+};
+#endif
+
+
 int main()
 {
 {
@@ -26,6 +45,28 @@ int main()
 c1.sort(std::greater());
 assert(c1 == std::list(a2, a2+sizeof(a2)/sizeof(a2[0])));
 }
+
+//  Test with throwing comparison; make sure that nothing is lost.
+//  This is (sort of) LWG #2824
+#ifndef TEST_HAS_NO_EXCEPTIONS
+{
+int a1[] = {4, 8, 1, 0, 5, 7, 2, 3, 6, 11, 10, 9};
+const int sz = sizeof(a1)/sizeof(a1[0]);
+for (int i = 0; i < 10; ++i)
+{
+std::list c1(a1, a1 + sz);
+try
+{
+throwingLess comp(i);
+c1.sort(std::cref(comp));
+}
+catch (int) {}
+assert((c1.size() == sz));
+assert((std::is_permutation(c1.begin(), c1.end(), a1)));
+}
+}
+#endif
+
 #if TEST_STD_VER >= 11
 {
 int a1[] = {4, 8, 1, 0, 5, 7, 2, 3, 6, 11, 10, 9};

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=321689=321688=321689=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Tue Jan  2 20:37:30 2018
@@ -454,7 +454,7 @@
https://wg21.link/LWG2788;>2788basic_string range mutators 
unintentionally require a default constructible 
allocatorKonaComplete
https://wg21.link/LWG2789;>2789Equivalence of contained 
objectsKonaComplete
https://wg21.link/LWG2790;>2790Missing 
specification of 
istreambuf_iterator::operator-KonaComplete
-   https://wg21.link/LWG2794;>2794Missing 
requirements for allocator pointersKona
+   https://wg21.link/LWG2794;>2794Missing 
requirements for allocator pointersKonaNothing to 
do
https://wg21.link/LWG2795;>2795[global.functions] 
provides incorrect example of ADL useKonaComplete
https://wg21.link/LWG2796;>2796tuple 
should be a literal typeKonaComplete
https://wg21.link/LWG2801;>2801Default-constructibility of 
unique_ptrKonaComplete
@@ -463,7 +463,7 @@
https://wg21.link/LWG2806;>2806Base class 
of bad_optional_accessKonaComplete
https://wg21.link/LWG2807;>2807std::invoke should use 
std::is_nothrow_callableKona
https://wg21.link/LWG2812;>2812Range 
access is available with 
string_viewKonaComplete
-   https://wg21.link/LWG2824;>2824list::sort 
should say that the order of elements is unspecified if an exception is 
thrownKona
+   https://wg21.link/LWG2824;>2824list::sort 
should say that the order of elements is unspecified if an exception is 
thrownKonaComplete
https://wg21.link/LWG2826;>2826string_view iterators use old 
wordingKonaComplete
https://wg21.link/LWG2834;>2834Resolution 
LWG 2223 is missing wording about end 
iteratorsKonaComplete
https://wg21.link/LWG2835;>2835LWG 2536 
seems to misspecify tgmath.hKona


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

[libcxx] r321687 - Mark issue #2866 as "nothing to do"

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Jan  2 19:43:32 2018
New Revision: 321687

URL: http://llvm.org/viewvc/llvm-project?rev=321687=rev
Log:
Mark issue #2866 as "nothing to do"


Modified:
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=321687=321686=321687=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Tue Jan  2 19:43:32 2018
@@ -475,7 +475,7 @@
https://wg21.link/LWG2855;>2855std::throw_with_nested("string_literal")KonaComplete
https://wg21.link/LWG2857;>2857{variant,optional,any}::emplace
 should return the constructed valueKonaComplete
https://wg21.link/LWG2861;>2861basic_string should require 
that charT match traits::char_typeKonaComplete
-   https://wg21.link/LWG2866;>2866Incorrect 
derived classes constraintsKona
+   https://wg21.link/LWG2866;>2866Incorrect 
derived classes constraintsKonaNothing to do
https://wg21.link/LWG2868;>2868Missing 
specification of bad_any_cast::what()KonaComplete
https://wg21.link/LWG2872;>2872Add 
definition for 
direct-non-list-initializationKonaComplete
https://wg21.link/LWG2873;>2873Add 
noexcept to several shared_ptr related 
functionsKonaComplete
@@ -503,7 +503,7 @@
 
   
 
-  Last Updated: 27-Jul-2017
+  Last Updated: 2-Jan-2018
 
 
 


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

Re: trivial_abi

[Richard Smith via cfe-commits]

On 2 January 2018 at 19:02, John McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> On Jan 2, 2018, at 9:15 PM, Akira Hatanaka  wrote:
>
>
>
> On Jan 2, 2018, at 4:56 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> On 2 January 2018 at 15:33, John McCall via cfe-commits  lists.llvm.org> wrote:
>
>> Hey, Richard et al.  Akira and I were talking about the right ABI rule
>> for deciding can-pass-in-registers-ness for structs in the presence of
>> trivial_abi, and I think I like Akira's approach but wanted to get your
>> input.
>>
>> The current definition in Itanium is:
>>
>>   *non-trivial for the purposes of calls*
>>
>> A type is considered non-trivial for the purposes of calls if:
>>
>>- it has a non-trivial copy constructor, move constructor, or
>>destructor, or
>>
>> I'm assuming we're implicitly excluding deleted functions here. (I'd
> prefer to make that explicit; this has been the source of a number of ABI
> mismatches.)
>
>>
>>- all of its copy and move constructors are deleted.
>>
>>
>> I'd suggest modifying this to:
>>
>> A type is considered non-trivial for the purposes of calls if:
>> - if has a copy constructor, move constructor, or destructor which is
>> non-trivial for the purposes of calls, or
>> - all of its copy and move constructors are deleted and it does not have
>> the trivial_abi attribute.
>>
>> A copy/move constructor is considered trivial for the purposes of calls
>> if:
>> - it is user-provided and
>> - the class has the trivial_abi attribute and
>> - a defaulted definition of the constructor would be trivial for the
>> purposes of calls; or
>>
>
> We'd need to say what happens if the function in question cannot validly
> be defaulted for any of the reasons in [dcl.fct.def.default]. Do we try to
> infer whether it's a copy or move constructor, and use the rules for a
> defaulted copy or move constructor? Or do we just say that's never trivial
> for the purposes of calls? Or something else? Eg:
>
> struct [[clang::trivial_abi]] A {
>   A(A && = make());
> };
>
> Here, A::A(A&&) cannot validly be defaulted. Is A trivial for the purpose
> of calls? Likewise:
>
> struct [[clang::trivial_abi]] B {
>   B(...);
> };
> struct C {
>   volatile B b;
> };
>
> Here, C's copy constructor calls B::B(...). Is C trivial for the purpose
> of calls? (OK, Clang crashes on that example today. But still...)
>
> I'd be uncomfortable making the rules in [dcl.fct.def.default] part of the
> ABI; they seem to be changing relatively frequently. Perhaps we could say
> "if the function is a copy constructor ([class.copy.ctor]/1), then
> consider what an implicitly-declared defaulted copy constructor would do;
> if it's a move constructor ([class.copy.ctor]/2), then consider what an
> implicitly-declared defaulted move constructor would do; otherwise, it's
> not trivial for the purpose of calls". That'd mean A is trivial for the
> purpose of calls and C is not, which I think is probably the right answer.
>
> - it is not user-provided and
>> - the class has no virtual functions and no virtual base classes, and
>> - the constructor used to copy/move each direct base class subobject is
>> trivial for the purposes of calls, and
>> - for each non-static data member that is of class type (or array
>> thereof), the constructor selected to copy/move that member is trivial for
>> the purposes of calls.
>>
>> A destructor is considered trivial for the purposes of calls if:
>> - it is not user-provided or the class has the trivial_abi attribute, and
>> - the destructor is not virtual, and
>> - all of the direct base classes of its class have destructors that are
>> trivial for the purposes of calls, and
>> - for all of the non-static data members of its class that are of class
>> type (or array thereof), each such class is trivial for the purposes of
>> calls.
>>
>> These definitions are intended to follow [class.copy.ctor]p11 and
>> [class.dtor]p6 except for the special rules applicable to trivial_abi
>> classes.
>>
>
> If I could rephrase: a *tor is considered trivial for for the purposes of
> calls if it is either defaulted or the class has the trivial_abi attribute,
> and the defaulted definition would satisfy the language rule for being
> trivial but with the word "trivial" replaced by "trivial for the purposes
> of calls". So only effect of the trivial_abi attribute is to "undo" the
> non-triviality implied by a user-provided *tor when computing triviality
> for the purpose of calls.
>
> I think that's a reasonable rule, if we have a satisfactory notion of
> "defaulted definition".
>
> I'm not sure about the "defaulted definition" rule for copy/move
>> constructors in trivial_abi classes.  The intent is to allow class
>> temploids with trivial_abi that are instantiated to contain non-trivial
>> classes to just silently become non-trivial.  I was thinking at first that
>> it would be nice to have a general rule that 

[PATCH] D41512: [Sema] -Wtautological-constant-compare is too good. Cripple it.

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

FWIW we build with -Wall -Wextra and we disable this warning since it's in our 
(chromium's) opinion not useful on large real-world code. So I'm not sure it 
should be in -Wextra. (Also, I believe clang has historically tried to keep 
-Wall and -Wextra pretty similar?)


Repository:
  rC Clang

https://reviews.llvm.org/D41512



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

[PATCH] D41553: Support parsing double square-bracket attributes in ObjC

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: include/clang/Basic/Attr.td:239
+  bit IncludeC = includeC;
+}
 

I have no objection to allowing ObjC attributes to be spelled in 
[[clang::objc_whatever]] style.  We can debate giving them a more appropriate 
standard name in the objc namespace at a later time — or even the primary 
namespace, if we really want to flex our Somewhat Major Language muscles.

I feel like this IncludeC is not the best name for this tablegen property.  
Perhaps AllowInC?

Also, a random positional 1 argument is pretty obscure TableGen design.  Do we 
really expect to be making very many attributes that intentionally disallow 
C2x?  What would these be, just C++-specific attributes without C analogues?  
It doesn't seem important to prohibit those at the parsing level rather than at 
the semantic level, since, after all, we are still allowing the GNU-style 
spelling, and these would still qualified with ``clang::``.

I would suggest standardizing in the opposite direction:  instead of forcing 
attributes to opt in to being allowed in C, we should make attributes that we 
really don't want to allow in the C2x [[clang::]] namespace be explicit about 
it.  If there are a lot of C++-specific attributes like that, we can make a 
ClangCXXOnly subclass.


https://reviews.llvm.org/D41553



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

Re: trivial_abi

[John McCall via cfe-commits]

> On Jan 2, 2018, at 9:15 PM, Akira Hatanaka  wrote:
> 
> 
> 
>> On Jan 2, 2018, at 4:56 PM, Richard Smith via cfe-commits 
>> > wrote:
>> 
>> On 2 January 2018 at 15:33, John McCall via cfe-commits 
>> > wrote:
>> Hey, Richard et al.  Akira and I were talking about the right ABI rule for 
>> deciding can-pass-in-registers-ness for structs in the presence of 
>> trivial_abi, and I think I like Akira's approach but wanted to get your 
>> input.
>> 
>> The current definition in Itanium is:
>> 
>>   non-trivial for the purposes of calls <>
>>  <>
>> A type is considered non-trivial for the purposes of calls if:
>> 
>> it has a non-trivial copy constructor, move constructor, or destructor, or
>>  <>
>> I'm assuming we're implicitly excluding deleted functions here. (I'd prefer 
>> to make that explicit; this has been the source of a number of ABI 
>> mismatches.)
>> all of its copy and move constructors are deleted.
>>  <>
>> 
>> I'd suggest modifying this to:
>> 
>>  A type is considered non-trivial for the purposes of calls if:
>>  - if has a copy constructor, move constructor, or destructor 
>> which is non-trivial for the purposes of calls, or
>>  - all of its copy and move constructors are deleted and it does 
>> not have the trivial_abi attribute.
>> 
>>  A copy/move constructor is considered trivial for the purposes of calls 
>> if:
>>  - it is user-provided and
>>  - the class has the trivial_abi attribute and
>>  - a defaulted definition of the constructor would be 
>> trivial for the purposes of calls; or
>> 
>> We'd need to say what happens if the function in question cannot validly be 
>> defaulted for any of the reasons in [dcl.fct.def.default]. Do we try to 
>> infer whether it's a copy or move constructor, and use the rules for a 
>> defaulted copy or move constructor? Or do we just say that's never trivial 
>> for the purposes of calls? Or something else? Eg:
>> 
>> struct [[clang::trivial_abi]] A {
>>   A(A && = make());
>> };
>> 
>> Here, A::A(A&&) cannot validly be defaulted. Is A trivial for the purpose of 
>> calls? Likewise:
>> 
>> struct [[clang::trivial_abi]] B {
>>   B(...);
>> };
>> struct C {
>>   volatile B b;
>> };
>> 
>> Here, C's copy constructor calls B::B(...). Is C trivial for the purpose of 
>> calls? (OK, Clang crashes on that example today. But still...)
>> 
>> I'd be uncomfortable making the rules in [dcl.fct.def.default] part of the 
>> ABI; they seem to be changing relatively frequently. Perhaps we could say 
>> "if the function is a copy constructor ([class.copy.ctor]/1), then consider 
>> what an implicitly-declared defaulted copy constructor would do; if it's a 
>> move constructor ([class.copy.ctor]/2), then consider what an 
>> implicitly-declared defaulted move constructor would do; otherwise, it's not 
>> trivial for the purpose of calls". That'd mean A is trivial for the purpose 
>> of calls and C is not, which I think is probably the right answer.
>> 
>>  - it is not user-provided and
>>  - the class has no virtual functions and no virtual 
>> base classes, and
>>  - the constructor used to copy/move each direct base 
>> class subobject is trivial for the purposes of calls, and
>>  - for each non-static data member that is of class type 
>> (or array thereof), the constructor selected to copy/move that member is 
>> trivial for the purposes of calls.
>> 
>>  A destructor is considered trivial for the purposes of calls if:
>>  - it is not user-provided or the class has the trivial_abi 
>> attribute, and
>>  - the destructor is not virtual, and
>>  - all of the direct base classes of its class have destructors 
>> that are trivial for the purposes of calls, and
>>  - for all of the non-static data members of its class that are 
>> of class type (or array thereof), each such class is trivial for the 
>> purposes of calls.
>> 
>>  These definitions are intended to follow [class.copy.ctor]p11 and 
>> [class.dtor]p6 except for the special rules applicable to trivial_abi 
>> classes.
>> 
>> If I could rephrase: a *tor is considered trivial for for the purposes of 
>> calls if it is either defaulted or the class has the trivial_abi attribute, 
>> and the defaulted definition would satisfy the language rule for being 
>> trivial but with the word "trivial" replaced by "trivial for the purposes of 
>> calls". So only effect of the trivial_abi attribute is to "undo" the 
>> non-triviality implied by a user-provided *tor when computing triviality for 
>> the purpose of calls.
>> 
>> I think that's a reasonable rule, if we have a satisfactory notion of 
>> "defaulted definition".
>> 
>> I'm not sure about the "defaulted 

[PATCH] D41545: Replace cp -a in various Clang tests

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added a comment.

I'll commit with `cp -R` tomorrow then; thanks.


Repository:
  rC Clang

https://reviews.llvm.org/D41545



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

r321686 - PR35697: look at the first declaration when determining whether a function or

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Jan  2 18:34:35 2018
New Revision: 321686

URL: http://llvm.org/viewvc/llvm-project?rev=321686=rev
Log:
PR35697: look at the first declaration when determining whether a function or
variable is extern "C" in linkage calculations.

Modified:
cfe/trunk/lib/AST/Decl.cpp
cfe/trunk/test/SemaCXX/extern-c.cpp

Modified: cfe/trunk/lib/AST/Decl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=321686=321685=321686=diff
==
--- cfe/trunk/lib/AST/Decl.cpp (original)
+++ cfe/trunk/lib/AST/Decl.cpp Tue Jan  2 18:34:35 2018
@@ -779,7 +779,7 @@ LinkageComputer::getLVForNamespaceScopeD
 // unique-external linkage, it's not legally usable from outside
 // this translation unit.  However, we should use the C linkage
 // rules instead for extern "C" declarations.
-if (Context.getLangOpts().CPlusPlus && !Function->isInExternCContext()) {
+if (Context.getLangOpts().CPlusPlus && !isFirstInExternCContext(Function)) 
{
   // Only look at the type-as-written. Otherwise, deducing the return type
   // of a function could change its linkage.
   QualType TypeAsWritten = Function->getType();
@@ -1165,7 +1165,7 @@ LinkageInfo LinkageComputer::getLVForLoc
LVComputationKind computation) {
   if (const auto *Function = dyn_cast(D)) {
 if (Function->isInAnonymousNamespace() &&
-!Function->isInExternCContext())
+!isFirstInExternCContext(Function))
   return getInternalLinkageFor(Function);
 
 // This is a "void f();" which got merged with a file static.
@@ -1188,7 +1188,7 @@ LinkageInfo LinkageComputer::getLVForLoc
 
   if (const auto *Var = dyn_cast(D)) {
 if (Var->hasExternalStorage()) {
-  if (Var->isInAnonymousNamespace() && !Var->isInExternCContext())
+  if (Var->isInAnonymousNamespace() && !isFirstInExternCContext(Var))
 return getInternalLinkageFor(Var);
 
   LinkageInfo LV;

Modified: cfe/trunk/test/SemaCXX/extern-c.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/extern-c.cpp?rev=321686=321685=321686=diff
==
--- cfe/trunk/test/SemaCXX/extern-c.cpp (original)
+++ cfe/trunk/test/SemaCXX/extern-c.cpp Tue Jan  2 18:34:35 2018
@@ -242,3 +242,20 @@ namespace tag_hiding {
   ExternCStruct3 *q3 = p3;
   ExternCStruct4 *q4 = p4; // expected-error {{ambiguous}}
 }
+
+namespace PR35697 {
+  typedef struct {} *ReturnStruct;
+  extern "C" ReturnStruct PR35697_f();
+  extern "C" ReturnStruct PR35697_v;
+  ReturnStruct PR35697_f();
+  ReturnStruct PR35697_v;
+
+  namespace {
+extern "C" ReturnStruct PR35697_f();
+extern "C" ReturnStruct PR35697_v;
+void q() {
+  extern ReturnStruct PR35697_f();
+  extern ReturnStruct PR35697_v;
+}
+  }
+}


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

[libcxx] r321685 - Implement p0258r2: has_unique_object_representations

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Jan  2 18:32:28 2018
New Revision: 321685

URL: http://llvm.org/viewvc/llvm-project?rev=321685=rev
Log:
Implement p0258r2: has_unique_object_representations

Added:

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/has_unique_object_representations.pass.cpp
Modified:
libcxx/trunk/include/__config
libcxx/trunk/include/type_traits
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=321685=321684=321685=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Tue Jan  2 18:32:28 2018
@@ -461,7 +461,11 @@ namespace std {
 #endif 
 
 #if __has_builtin(__builtin_launder)
-#define_LIBCPP_COMPILER_HAS_BUILTIN_LAUNDER
+#define _LIBCPP_COMPILER_HAS_BUILTIN_LAUNDER
+#endif
+
+#if !__is_identifier(__has_unique_object_representations)
+#define _LIBCPP_HAS_UNIQUE_OBJECT_REPRESENTATIONS
 #endif
 
 #elif defined(_LIBCPP_COMPILER_GCC)
@@ -547,7 +551,11 @@ namespace std {
 #endif
 
 #if _GNUC_VER >= 700
-#define_LIBCPP_COMPILER_HAS_BUILTIN_LAUNDER
+#define _LIBCPP_COMPILER_HAS_BUILTIN_LAUNDER
+#endif
+
+#if _GNUC_VER >= 700
+#define _LIBCPP_HAS_UNIQUE_OBJECT_REPRESENTATIONS
 #endif
 
 #elif defined(_LIBCPP_COMPILER_MSVC)

Modified: libcxx/trunk/include/type_traits
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/type_traits?rev=321685=321684=321685=diff
==
--- libcxx/trunk/include/type_traits (original)
+++ libcxx/trunk/include/type_traits Tue Jan  2 18:32:28 2018
@@ -132,6 +132,8 @@ namespace std
 
 template  struct has_virtual_destructor;
 
+template struct has_unique_object_representations; // 
C++17
+
 // Relationships between types:
 template  struct is_same;
 template  struct is_base_of;
@@ -355,6 +357,8 @@ namespace std
 = is_nothrow_destructible::value; // 
C++17
   template  inline constexpr bool has_virtual_destructor_v
 = has_virtual_destructor::value;  // 
C++17
+  template inline constexpr bool 
has_unique_object_representations_v // C++17
+= has_unique_object_representations::value;
 
   // See C++14 20.10.5, type property queries
   template  inline constexpr size_t alignment_of_v
@@ -1617,6 +1621,22 @@ _LIBCPP_INLINE_VAR _LIBCPP_CONSTEXPR boo
 = has_virtual_destructor<_Tp>::value;
 #endif
 
+// has_unique_object_representations
+
+#if _LIBCPP_STD_VER > 14 && defined(_LIBCPP_HAS_UNIQUE_OBJECT_REPRESENTATIONS)
+
+template  struct _LIBCPP_TEMPLATE_VIS 
has_unique_object_representations
+: public integral_constant>)> {};
+
+#if !defined(_LIBCPP_HAS_NO_VARIABLE_TEMPLATES)
+template 
+_LIBCPP_INLINE_VAR _LIBCPP_CONSTEXPR bool has_unique_object_representations_v
+= has_unique_object_representations<_Tp>::value;
+#endif
+
+#endif
+
 // alignment_of
 
 template  struct _LIBCPP_TEMPLATE_VIS alignment_of

Added: 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/has_unique_object_representations.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/has_unique_object_representations.pass.cpp?rev=321685=auto
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/has_unique_object_representations.pass.cpp
 (added)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/has_unique_object_representations.pass.cpp
 Tue Jan  2 18:32:28 2018
@@ -0,0 +1,104 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// UNSUPPORTED: c++98, c++03, c++11, c++14
+// UNSUPPORTED: clang-3, clang-4, clang-5, apple-clang, gcc-4, gcc-5, gcc-6
+
+// type_traits
+
+// has_unique_object_representations
+
+#include 
+
+#include "test_macros.h"
+
+template 
+void test_has_unique_object_representations()
+{
+static_assert( std::has_unique_object_representations::value, "");
+static_assert( std::has_unique_object_representations::value, "");
+static_assert( std::has_unique_object_representations::value, 
"");
+static_assert( std::has_unique_object_representations::value, "");
+
+static_assert( std::has_unique_object_representations_v, "");
+static_assert( std::has_unique_object_representations_v, "");
+static_assert( 

Re: trivial_abi

[Akira Hatanaka via cfe-commits]

> On Jan 2, 2018, at 4:56 PM, Richard Smith via cfe-commits 
>  wrote:
> 
> On 2 January 2018 at 15:33, John McCall via cfe-commits 
> > wrote:
> Hey, Richard et al.  Akira and I were talking about the right ABI rule for 
> deciding can-pass-in-registers-ness for structs in the presence of 
> trivial_abi, and I think I like Akira's approach but wanted to get your input.
> 
> The current definition in Itanium is:
> 
>   non-trivial for the purposes of calls <>
>  <>
> A type is considered non-trivial for the purposes of calls if:
> 
> it has a non-trivial copy constructor, move constructor, or destructor, or
>  <>
> I'm assuming we're implicitly excluding deleted functions here. (I'd prefer 
> to make that explicit; this has been the source of a number of ABI 
> mismatches.)
> all of its copy and move constructors are deleted.
>  <>
> 
> I'd suggest modifying this to:
> 
>   A type is considered non-trivial for the purposes of calls if:
>   - if has a copy constructor, move constructor, or destructor 
> which is non-trivial for the purposes of calls, or
>   - all of its copy and move constructors are deleted and it does 
> not have the trivial_abi attribute.
> 
>   A copy/move constructor is considered trivial for the purposes of calls 
> if:
>   - it is user-provided and
>   - the class has the trivial_abi attribute and
>   - a defaulted definition of the constructor would be 
> trivial for the purposes of calls; or
> 
> We'd need to say what happens if the function in question cannot validly be 
> defaulted for any of the reasons in [dcl.fct.def.default]. Do we try to infer 
> whether it's a copy or move constructor, and use the rules for a defaulted 
> copy or move constructor? Or do we just say that's never trivial for the 
> purposes of calls? Or something else? Eg:
> 
> struct [[clang::trivial_abi]] A {
>   A(A && = make());
> };
> 
> Here, A::A(A&&) cannot validly be defaulted. Is A trivial for the purpose of 
> calls? Likewise:
> 
> struct [[clang::trivial_abi]] B {
>   B(...);
> };
> struct C {
>   volatile B b;
> };
> 
> Here, C's copy constructor calls B::B(...). Is C trivial for the purpose of 
> calls? (OK, Clang crashes on that example today. But still...)
> 
> I'd be uncomfortable making the rules in [dcl.fct.def.default] part of the 
> ABI; they seem to be changing relatively frequently. Perhaps we could say "if 
> the function is a copy constructor ([class.copy.ctor]/1), then consider what 
> an implicitly-declared defaulted copy constructor would do; if it's a move 
> constructor ([class.copy.ctor]/2), then consider what an implicitly-declared 
> defaulted move constructor would do; otherwise, it's not trivial for the 
> purpose of calls". That'd mean A is trivial for the purpose of calls and C is 
> not, which I think is probably the right answer.
> 
>   - it is not user-provided and
>   - the class has no virtual functions and no virtual 
> base classes, and
>   - the constructor used to copy/move each direct base 
> class subobject is trivial for the purposes of calls, and
>   - for each non-static data member that is of class type 
> (or array thereof), the constructor selected to copy/move that member is 
> trivial for the purposes of calls.
> 
>   A destructor is considered trivial for the purposes of calls if:
>   - it is not user-provided or the class has the trivial_abi 
> attribute, and
>   - the destructor is not virtual, and
>   - all of the direct base classes of its class have destructors 
> that are trivial for the purposes of calls, and
>   - for all of the non-static data members of its class that are 
> of class type (or array thereof), each such class is trivial for the purposes 
> of calls.
> 
>   These definitions are intended to follow [class.copy.ctor]p11 and 
> [class.dtor]p6 except for the special rules applicable to trivial_abi classes.
> 
> If I could rephrase: a *tor is considered trivial for for the purposes of 
> calls if it is either defaulted or the class has the trivial_abi attribute, 
> and the defaulted definition would satisfy the language rule for being 
> trivial but with the word "trivial" replaced by "trivial for the purposes of 
> calls". So only effect of the trivial_abi attribute is to "undo" the 
> non-triviality implied by a user-provided *tor when computing triviality for 
> the purpose of calls.
> 
> I think that's a reasonable rule, if we have a satisfactory notion of 
> "defaulted definition".
> 
> I'm not sure about the "defaulted definition" rule for copy/move constructors 
> in trivial_abi classes.  The intent is to allow class temploids with 
> trivial_abi that are instantiated to contain non-trivial classes to just 
> silently become 

[PATCH] D41512: [Sema] -Wtautological-constant-compare is too good. Cripple it.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith accepted this revision.
rsmith added inline comments.
This revision is now accepted and ready to land.



Comment at: include/clang/Basic/DiagnosticGroups.td:438
 def StrncatSize : DiagGroup<"strncat-size">;
+def TautologicalTypeLimitCompare : 
DiagGroup<"tautological-type-limit-compare">;
 def TautologicalUnsignedZeroCompare : 
DiagGroup<"tautological-unsigned-zero-compare">;

lebedev.ri wrote:
> Any opinion on this one?
I would *almost* prefer "tautological-min-max-compare", but I'd be worried 
about confusion with the `std::min` / `std::max` functions. I think this name 
is good enough. (Ideally, a name that clearly conveys this is about non-zero 
limiting values would be better, but that's hard to express.)


Repository:
  rC Clang

https://reviews.llvm.org/D41512



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

[PATCH] D41688: [Lex] Fix crash on code completion in comment in included file.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai added a comment.

A few approaches that I've considered but decided not to pursue:

- Change code completion in comment so we don't exit file early but more 
gracefully. Decided not to do it because I believe early exit is important for 
code completion performance. And `CurLexer`/`CurLexerKind` discrepancy would 
remain anyway, which is not good.
- Use `RemoveTopOfLexerStack` instead of `recomputeCurLexerKind`. It works but 
I'm not confident it doesn't have undesired consequences. And I don't like that 
after removing the top of lexer stack, pushing back tokens would happen on top 
of includer, not on top of includee. But it might be totally OK.
- Add assertion in `InCachingLexMode` that returned value is in sync with 
`CurLexerKind`. It works but I suspect there might be legitimate reasons for 
them to be out of sync for some time. Though it can be a mistake and assertion 
can help to catch it.


https://reviews.llvm.org/D41688



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

[PATCH] D41688: [Lex] Fix crash on code completion in comment in included file.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai created this revision.
vsapsai added reviewers: akyrtzi, doug.gregor.
Herald added subscribers: kbarton, nemanjai.

This fixes PR32732 by updating CurLexerKind to reflect available lexers.
We were hitting null pointer in Preprocessor::Lex because CurLexerKind
was CLK_Lexer but CurLexer was null. And we set it to null in
Preprocessor::HandleEndOfFile when exiting a file with code completion
point.

To reproduce the crash it is important for a comment to be inside a
class specifier. In this case in Parser::ParseClassSpecifier we improve
error recovery by pushing a semicolon token back into the preprocessor
and later on try to lex a token because we haven't reached the end of
file.

Also clang crashes only on code completion in included file, i.e. when
IncludeMacroStack is not empty. Though we reset CurLexer even if include
stack is empty. The difference is that during pushing back a semicolon
token, preprocessor calls EnterCachingLexMode which decides it is
already in caching mode because various lexers are null and
IncludeMacroStack is not empty. As the result, CurLexerKind remains
CLK_Lexer instead of updating to CLK_CachingLexer.

rdar://problem/34787685


https://reviews.llvm.org/D41688

Files:
  clang/lib/Lex/PPCaching.cpp
  clang/lib/Lex/PPLexerChange.cpp
  clang/test/CodeCompletion/Inputs/comments.h
  clang/test/CodeCompletion/comments.cpp


Index: clang/test/CodeCompletion/comments.cpp
===
--- /dev/null
+++ clang/test/CodeCompletion/comments.cpp
@@ -0,0 +1,13 @@
+// Note: the run lines follow their respective tests, since line/column
+// matter in this test.
+
+#include "comments.h"
+
+struct A {
+  // <- code completion
+  /* <- code completion */
+};
+
+// RUN: %clang_cc1 -I %S/Inputs -fsyntax-only -code-completion-at=%s:7:6 %s
+// RUN: %clang_cc1 -I %S/Inputs -fsyntax-only -code-completion-at=%s:8:6 %s
+// RUN: %clang_cc1 -I %S/Inputs -fsyntax-only 
-code-completion-at=%S/Inputs/comments.h:3:6 %s
Index: clang/test/CodeCompletion/Inputs/comments.h
===
--- /dev/null
+++ clang/test/CodeCompletion/Inputs/comments.h
@@ -0,0 +1,4 @@
+// PR32732
+struct B {
+  // <- code completion
+};
Index: clang/lib/Lex/PPLexerChange.cpp
===
--- clang/lib/Lex/PPLexerChange.cpp
+++ clang/lib/Lex/PPLexerChange.cpp
@@ -444,6 +444,7 @@
   }
 
   CurPPLexer = nullptr;
+  recomputeCurLexerKind();
   return true;
 }
 
Index: clang/lib/Lex/PPCaching.cpp
===
--- clang/lib/Lex/PPCaching.cpp
+++ clang/lib/Lex/PPCaching.cpp
@@ -105,8 +105,10 @@
 }
 
 void Preprocessor::EnterCachingLexMode() {
-  if (InCachingLexMode())
+  if (InCachingLexMode()) {
+assert(CurLexerKind == CLK_CachingLexer && "Unexpected lexer kind");
 return;
+  }
 
   PushIncludeMacroStack();
   CurLexerKind = CLK_CachingLexer;


Index: clang/test/CodeCompletion/comments.cpp
===
--- /dev/null
+++ clang/test/CodeCompletion/comments.cpp
@@ -0,0 +1,13 @@
+// Note: the run lines follow their respective tests, since line/column
+// matter in this test.
+
+#include "comments.h"
+
+struct A {
+  // <- code completion
+  /* <- code completion */
+};
+
+// RUN: %clang_cc1 -I %S/Inputs -fsyntax-only -code-completion-at=%s:7:6 %s
+// RUN: %clang_cc1 -I %S/Inputs -fsyntax-only -code-completion-at=%s:8:6 %s
+// RUN: %clang_cc1 -I %S/Inputs -fsyntax-only -code-completion-at=%S/Inputs/comments.h:3:6 %s
Index: clang/test/CodeCompletion/Inputs/comments.h
===
--- /dev/null
+++ clang/test/CodeCompletion/Inputs/comments.h
@@ -0,0 +1,4 @@
+// PR32732
+struct B {
+  // <- code completion
+};
Index: clang/lib/Lex/PPLexerChange.cpp
===
--- clang/lib/Lex/PPLexerChange.cpp
+++ clang/lib/Lex/PPLexerChange.cpp
@@ -444,6 +444,7 @@
   }
 
   CurPPLexer = nullptr;
+  recomputeCurLexerKind();
   return true;
 }
 
Index: clang/lib/Lex/PPCaching.cpp
===
--- clang/lib/Lex/PPCaching.cpp
+++ clang/lib/Lex/PPCaching.cpp
@@ -105,8 +105,10 @@
 }
 
 void Preprocessor::EnterCachingLexMode() {
-  if (InCachingLexMode())
+  if (InCachingLexMode()) {
+assert(CurLexerKind == CLK_CachingLexer && "Unexpected lexer kind");
 return;
+  }
 
   PushIncludeMacroStack();
   CurLexerKind = CLK_CachingLexer;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: trivial_abi

[Richard Smith via cfe-commits]

On 2 January 2018 at 15:33, John McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hey, Richard et al.  Akira and I were talking about the right ABI rule for
> deciding can-pass-in-registers-ness for structs in the presence of
> trivial_abi, and I think I like Akira's approach but wanted to get your
> input.
>
> The current definition in Itanium is:
>
>   *non-trivial for the purposes of calls*
>
> A type is considered non-trivial for the purposes of calls if:
>
>- it has a non-trivial copy constructor, move constructor, or
>destructor, or
>
> I'm assuming we're implicitly excluding deleted functions here. (I'd
prefer to make that explicit; this has been the source of a number of ABI
mismatches.)

>
>- all of its copy and move constructors are deleted.
>
>
> I'd suggest modifying this to:
>
> A type is considered non-trivial for the purposes of calls if:
> - if has a copy constructor, move constructor, or destructor which is
> non-trivial for the purposes of calls, or
> - all of its copy and move constructors are deleted and it does not have
> the trivial_abi attribute.
>
> A copy/move constructor is considered trivial for the purposes of calls if:
> - it is user-provided and
> - the class has the trivial_abi attribute and
> - a defaulted definition of the constructor would be trivial for the
> purposes of calls; or
>

We'd need to say what happens if the function in question cannot validly be
defaulted for any of the reasons in [dcl.fct.def.default]. Do we try to
infer whether it's a copy or move constructor, and use the rules for a
defaulted copy or move constructor? Or do we just say that's never trivial
for the purposes of calls? Or something else? Eg:

struct [[clang::trivial_abi]] A {
  A(A && = make());
};

Here, A::A(A&&) cannot validly be defaulted. Is A trivial for the purpose
of calls? Likewise:

struct [[clang::trivial_abi]] B {
  B(...);
};
struct C {
  volatile B b;
};

Here, C's copy constructor calls B::B(...). Is C trivial for the purpose of
calls? (OK, Clang crashes on that example today. But still...)

I'd be uncomfortable making the rules in [dcl.fct.def.default] part of the
ABI; they seem to be changing relatively frequently. Perhaps we could say
"if the function is a copy constructor ([class.copy.ctor]/1), then consider
what an implicitly-declared defaulted copy constructor would do; if it's a
move constructor ([class.copy.ctor]/2), then consider what an
implicitly-declared defaulted move constructor would do; otherwise, it's
not trivial for the purpose of calls". That'd mean A is trivial for the
purpose of calls and C is not, which I think is probably the right answer.

- it is not user-provided and
> - the class has no virtual functions and no virtual base classes, and
> - the constructor used to copy/move each direct base class subobject is
> trivial for the purposes of calls, and
> - for each non-static data member that is of class type (or array
> thereof), the constructor selected to copy/move that member is trivial for
> the purposes of calls.
>
> A destructor is considered trivial for the purposes of calls if:
> - it is not user-provided or the class has the trivial_abi attribute, and
> - the destructor is not virtual, and
> - all of the direct base classes of its class have destructors that are
> trivial for the purposes of calls, and
> - for all of the non-static data members of its class that are of class
> type (or array thereof), each such class is trivial for the purposes of
> calls.
>
> These definitions are intended to follow [class.copy.ctor]p11 and
> [class.dtor]p6 except for the special rules applicable to trivial_abi
> classes.
>

If I could rephrase: a *tor is considered trivial for for the purposes of
calls if it is either defaulted or the class has the trivial_abi attribute,
and the defaulted definition would satisfy the language rule for being
trivial but with the word "trivial" replaced by "trivial for the purposes
of calls". So only effect of the trivial_abi attribute is to "undo" the
non-triviality implied by a user-provided *tor when computing triviality
for the purpose of calls.

I think that's a reasonable rule, if we have a satisfactory notion of
"defaulted definition".

I'm not sure about the "defaulted definition" rule for copy/move
> constructors in trivial_abi classes.  The intent is to allow class
> temploids with trivial_abi that are instantiated to contain non-trivial
> classes to just silently become non-trivial.  I was thinking at first that
> it would be nice to have a general rule that trivial_abi classes only
> contain trivial_abi subobjects, but unfortunately that's not consistent
> with the standard triviality rule in some silly corner cases: a
> trivially-copyable class can have a non-trivially-copyable subobject if it
> happens to copy that subobject with a trivial copy constructor.  I couldn't
> think of a better way of capturing this than the "defaulted definition"
> rule.  I considered using the actual 

[PATCH] D41151: [analyzer] Adding LoopContext and improve loop modeling

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

//*asked stuff in https://reviews.llvm.org/D39398 regarding how indirect gotos 
are supported*//


https://reviews.llvm.org/D41151



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

[PATCH] D39398: [CFG][Analyzer] Add LoopExit element to the CFG in more cases

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.
Herald added subscribers: dkrupp, a.sidorin, rnkovacs.

These CFGs make perfect sense to me so far, and i guess this is a must-have. 
Thank you!

> Note: In case of IndirectGotoStmt, it could happen that we generate LoopExit 
> elements even for loops which is not exited by that jump. However, it does 
> not seem to be a problem. This could result that we can not apply some more 
> precise modeling feature (like unrolling and widening) but not any more - as 
> I can see. (Also, this is a rare case.)

This seems a bit scary because if there's no obvious one-to-once correspondence 
between entrances and exits along every path, how would we know when to pop 
loop contexts from the stack of location contexts? Like, if we attach variable 
lifetime checks to the loop exit, would we need to write additional code in the 
analyzer to see if the variable indeed goes out of scope on the current path? 
Could you demonstrate how it works in a test case over 
https://reviews.llvm.org/D41151?




Comment at: include/clang/Analysis/CFG.h:172-178
 /// Represents the point where a loop ends.
 /// This element is is only produced when building the CFG for the static
 /// analyzer and hidden behind the 'cfg-loopexit' analyzer config flag.
 ///
-/// Note: a loop exit element can be reached even when the loop body was never
-/// entered.
+/// Note: whenever a loop is entered a loop exit element will be encountered
+/// after leaving it. However, a loop exit element can be reached even when the
+/// loop body was never entered.

I'd be glad to see more documentation on where does this `CFGElement` appear, 
when, and why:
- At the end of the block within the loop?
- At the beginning of the block after the loop?
- In its own block constructed with the sole purpose of sheltering it?
Same goes for the `CFGLoopEntrace`, i guess.



Comment at: test/Analysis/loopexit-cfg-output.cpp:912-914
+// CHECK:   [B5]
+// CHECK-NEXT:   Succs (1): B8
+

P.S. This is not a regression introduced by your patch, but i'm really curious 
what does this block even do.


https://reviews.llvm.org/D39398



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

[PATCH] D41562: [CodeGen] Generate TBAA info on passing arguments and returning values

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Aren't these always loads and stores from allocas?  I would expect TBAA to be 
useless here because it's always strictly less informative than basic-AA, which 
knows that the access doesn't alias with anything.


Repository:
  rL LLVM

https://reviews.llvm.org/D41562



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

[PATCH] D41660: [cmake] Add new linux toolchain file

[Don Hinton via Phabricator via cfe-commits]

hintonda abandoned this revision.
hintonda added a comment.

Thanks for all your suggestions.

Planning to rework and move the toolchain specific part to llvm/cmake/platform 
and abandon the cache part altogether.


Repository:
  rC Clang

https://reviews.llvm.org/D41660



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

[PATCH] D41547: [CodeGen] Fix TBAA info for accesses to members of base classes

[John McCall via Phabricator via cfe-commits]

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

Ok.


Repository:
  rL LLVM

https://reviews.llvm.org/D41547



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

[PATCH] D41539: [CodeGen] Decorate aggregate accesses with TBAA tags

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

You're sure you just want a single TBAA tag on memcpy's?  I would think that it 
might be useful to encode separate path information for the two operands.


https://reviews.llvm.org/D41539



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

[PATCH] D40398: Remove ValueDependent assertions on ICE checks.

[Matt Davis via Phabricator via cfe-commits]

mattd abandoned this revision.
mattd added a comment.

Abandoning as this is no longer a problem with release builds.


https://reviews.llvm.org/D40398



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

[PATCH] D41150: [CFG] Adding new CFGStmt LoopEntrance for the StaticAnalyzer

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

(edited my comment: fixed the suggested change to mention the right block)


https://reviews.llvm.org/D41150



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

[PATCH] D41150: [CFG] Adding new CFGStmt LoopEntrance for the StaticAnalyzer

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Because it wasn't immediately obvious to me how to apply both this patch and 
https://reviews.llvm.org/D39398 (there are a couple of minor conflicts between 
them), i wanted to post a few pictures for the reference, because 
`debug.ViewCFG` graphs are much easier to comprehend than text dumps.

For example, here's the new CFG for `check_return()` in 
`loopexit-cfg-output.cpp`:

  833 int check_return() {
  834   for (int i = 0; i < 10; i++) {
  835 int j = 1;
  836 while (j < 12) {
  837   if (j % 2)
  838 return 0;
  839 }
  840   }
  841   return 1;
  842 }

F5732587: Screen Shot 2018-01-02 at 3.42.17 PM.png 




I essentially have one question at a glance - for loop counter variables, don't 
we want `LoopEntrance` be before the initialization? I.e. on this picture 
wouldn't it be better to have

  [B8]
  1: WhileStmt (LoopEntrance)
  2: 1
  3: int j = 1;

?

Because otherwise our future `LoopContext` wouldn't correspond to any 
variable's lifetime scope, so it'd be kind of useless as a `ScopeContext`. 
Because, as far as i understand, there are two scopes in every loop:

1. The scope of the whole loop which includes the counter,
2. The scope of every iteration, which goes out of scope after the iteration 
ends.

And currently `LoopContext` is none of these. Would loop unrolling still work 
in a sensible manner if we move `LoopEntrance` to the beginning of the block?


https://reviews.llvm.org/D41150



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

[PATCH] D41545: Replace cp -a in various Clang tests

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

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

Hi Hubert,

Thanks for fixing this. `cp -R` is sufficient IMO. LGTM


Repository:
  rC Clang

https://reviews.llvm.org/D41545



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

r321683 - Fix and simplify handling of return type for (generic) lambda conversion function to function pointer.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Jan  2 15:52:42 2018
New Revision: 321683

URL: http://llvm.org/viewvc/llvm-project?rev=321683=rev
Log:
Fix and simplify handling of return type for (generic) lambda conversion 
function to function pointer.

Previously, we would:
 * compute the type of the conversion function and static invoker as a
   side-effect of template argument deduction for a conversion
 * re-compute the type as part of deduced return type deduction when building
   the conversion function itself

Neither of these turns out to be quite correct. There are other ways to reach a
declaration of the conversion function than in a conversion (such as an
explicit call or friend declaration), and performing auto deduction causes the
function type to be rebuilt in the context of the lambda closure type (which is
different from the context in which it originally appeared, resulting in
spurious substitution failures for constructs that are valid in one context but
not the other, such as the use of an enclosing class's "this" pointer).

This patch switches us to use a different strategy: as before, we use the
declared type of the operator() to form the type of the conversion function and
invoker, but we now populate that type as part of return type deduction for the
conversion function. And the invoker is now treated as simply being an
implementation detail of building the conversion function, and isn't given
special treatment by template argument deduction for the conversion function
any more.

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaLambda.cpp
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/lib/Sema/SemaStmt.cpp
cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/test/SemaCXX/cxx1y-generic-lambdas.cpp
cfe/trunk/test/SemaCXX/lambda-expressions.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=321683=321682=321683=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Jan  2 15:52:42 2018
@@ -5547,6 +5547,11 @@ public:
   ExprResult BuildLambdaExpr(SourceLocation StartLoc, SourceLocation EndLoc,
  sema::LambdaScopeInfo *LSI);
 
+  /// Get the return type to use for a lambda's conversion function(s) to
+  /// function pointer type, given the type of the call operator.
+  QualType
+  getLambdaConversionFunctionResultType(const FunctionProtoType *CallOpType);
+
   /// \brief Define the "body" of the conversion from a lambda object to a
   /// function pointer.
   ///
@@ -7760,6 +7765,9 @@ public:
 
   void InstantiateExceptionSpec(SourceLocation PointOfInstantiation,
 FunctionDecl *Function);
+  FunctionDecl *InstantiateFunctionDeclaration(FunctionTemplateDecl *FTD,
+   const TemplateArgumentList 
*Args,
+   SourceLocation Loc);
   void InstantiateFunctionDefinition(SourceLocation PointOfInstantiation,
  FunctionDecl *Function,
  bool Recursive = false,

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=321683=321682=321683=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Tue Jan  2 15:52:42 2018
@@ -12215,30 +12215,27 @@ void Sema::DefineImplicitLambdaToFunctio
 SourceLocation CurrentLocation,
 CXXConversionDecl *Conv) {
   SynthesizedFunctionScope Scope(*this, Conv);
+  assert(!Conv->getReturnType()->isUndeducedType());
 
   CXXRecordDecl *Lambda = Conv->getParent();
-  CXXMethodDecl *CallOp = Lambda->getLambdaCallOperator();
-  // If we are defining a specialization of a conversion to function-ptr
-  // cache the deduced template arguments for this specialization
-  // so that we can use them to retrieve the corresponding call-operator
-  // and static-invoker.
-  const TemplateArgumentList *DeducedTemplateArgs = nullptr;
-
-  // Retrieve the corresponding call-operator specialization.
-  if (Lambda->isGenericLambda()) {
-assert(Conv->isFunctionTemplateSpecialization());
-FunctionTemplateDecl *CallOpTemplate =
-CallOp->getDescribedFunctionTemplate();
-DeducedTemplateArgs = Conv->getTemplateSpecializationArgs();
-void *InsertPos = nullptr;
-FunctionDecl *CallOpSpec = CallOpTemplate->findSpecialization(
-DeducedTemplateArgs->asArray(),
-InsertPos);
-assert(CallOpSpec &&
- 

trivial_abi

[John McCall via cfe-commits]

Hey, Richard et al.  Akira and I were talking about the right ABI rule for 
deciding can-pass-in-registers-ness for structs in the presence of trivial_abi, 
and I think I like Akira's approach but wanted to get your input.

The current definition in Itanium is:

  non-trivial for the purposes of calls <>
 <>
A type is considered non-trivial for the purposes of calls if:

it has a non-trivial copy constructor, move constructor, or destructor, or
all of its copy and move constructors are deleted.
 <>

I'd suggest modifying this to:

A type is considered non-trivial for the purposes of calls if:
- if has a copy constructor, move constructor, or destructor 
which is non-trivial for the purposes of calls, or
- all of its copy and move constructors are deleted and it does 
not have the trivial_abi attribute.

A copy/move constructor is considered trivial for the purposes of calls 
if:
- it is user-provided and
- the class has the trivial_abi attribute and
- a defaulted definition of the constructor would be 
trivial for the purposes of calls; or
- it is not user-provided and
- the class has no virtual functions and no virtual 
base classes, and
- the constructor used to copy/move each direct base 
class subobject is trivial for the purposes of calls, and
- for each non-static data member that is of class type 
(or array thereof), the constructor selected to copy/move that member is 
trivial for the purposes of calls.

A destructor is considered trivial for the purposes of calls if:
- it is not user-provided or the class has the trivial_abi 
attribute, and
- the destructor is not virtual, and
- all of the direct base classes of its class have destructors 
that are trivial for the purposes of calls, and
- for all of the non-static data members of its class that are 
of class type (or array thereof), each such class is trivial for the purposes 
of calls.

These definitions are intended to follow [class.copy.ctor]p11 and 
[class.dtor]p6 except for the special rules applicable to trivial_abi classes.

I'm not sure about the "defaulted definition" rule for copy/move constructors 
in trivial_abi classes.  The intent is to allow class temploids with 
trivial_abi that are instantiated to contain non-trivial classes to just 
silently become non-trivial.  I was thinking at first that it would be nice to 
have a general rule that trivial_abi classes only contain trivial_abi 
subobjects, but unfortunately that's not consistent with the standard 
triviality rule in some silly corner cases: a trivially-copyable class can have 
a non-trivially-copyable subobject if it happens to copy that subobject with a 
trivial copy constructor.  I couldn't think of a better way of capturing this 
than the "defaulted definition" rule.  I considered using the actual 
initializers used by the constructor, but that would introduce a lot of new 
complexity: suddenly we'd be asking about triviality for an arbitrary 
constructor, and copy/move elision make the question somewhat ambiguous anyway.

I'm also not sure about the right rules about virtual methods.  Should we allow 
polymorphic classes to be made trivial by application of the attribute?

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

[PATCH] D23934: Add a -ffixed-date-time= flag that sets the initial value of __DATE__, __TIME__, __TIMESTAMP__

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: lib/Frontend/CompilerInvocation.cpp:2252
+  TM.tm_isdst = -1;
+  mktime();
+  Opts.FixedDateTime = TM;

Does using mktime like this depend on the local timezone?


https://reviews.llvm.org/D23934



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

r321682 - [analyzer] do not crash with assertion on processing locations of bodyfarmed functions

[George Karpenkov via cfe-commits]

Author: george.karpenkov
Date: Tue Jan  2 15:05:47 2018
New Revision: 321682

URL: http://llvm.org/viewvc/llvm-project?rev=321682=rev
Log:
[analyzer] do not crash with assertion on processing locations of bodyfarmed 
functions

This addresses an issue introduced in r183451: since
`removePiecesWithInvalidLocations` is called *after* `adjustCallLocations`,
it is not necessary, and in fact harmful, to have this assertion in
adjustCallLocations.

Addresses rdar://36170689

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

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp
cfe/trunk/test/Analysis/call_once.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp?rev=321682=321681=321682=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp Tue Jan  2 15:05:47 2018
@@ -229,7 +229,6 @@ adjustCallLocations(PathPieces ,
 PathDiagnosticCallPiece *Call = 
dyn_cast(I->get());
 
 if (!Call) {
-  assert((*I)->getLocation().asLocation().isValid());
   continue;
 }
 

Modified: cfe/trunk/test/Analysis/call_once.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/call_once.cpp?rev=321682=321681=321682=diff
==
--- cfe/trunk/test/Analysis/call_once.cpp (original)
+++ cfe/trunk/test/Analysis/call_once.cpp Tue Jan  2 15:05:47 2018
@@ -1,10 +1,11 @@
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -verify %s
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -verify %s -o %t.report
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s -o 
%t.report
 
 // We do NOT model libcxx03 implementation, but the analyzer should still
 // not crash.
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -verify %s
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 
-DEMULATE_LIBSTDCPP -verify %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -verify %s -o 
%t.report
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 
-DEMULATE_LIBSTDCPP -verify %s -o %t.report
+// RUN: rm -rf %t.report
 
 void clang_analyzer_eval(bool);
 


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

[PATCH] D41680: [analyzer] do not crash with assertion on processing locations of bodyfarmed functions

[George Karpenkov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC321682: [analyzer] do not crash with assertion on processing 
locations of bodyfarmed… (authored by george.karpenkov, committed by ).

Repository:
  rC Clang

https://reviews.llvm.org/D41680

Files:
  lib/StaticAnalyzer/Core/BugReporter.cpp
  test/Analysis/call_once.cpp


Index: test/Analysis/call_once.cpp
===
--- test/Analysis/call_once.cpp
+++ test/Analysis/call_once.cpp
@@ -1,10 +1,11 @@
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -verify %s
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -verify %s -o %t.report
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s -o 
%t.report
 
 // We do NOT model libcxx03 implementation, but the analyzer should still
 // not crash.
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -verify %s
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 
-DEMULATE_LIBSTDCPP -verify %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -verify %s -o 
%t.report
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 
-DEMULATE_LIBSTDCPP -verify %s -o %t.report
+// RUN: rm -rf %t.report
 
 void clang_analyzer_eval(bool);
 
Index: lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- lib/StaticAnalyzer/Core/BugReporter.cpp
+++ lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -229,7 +229,6 @@
 PathDiagnosticCallPiece *Call = 
dyn_cast(I->get());
 
 if (!Call) {
-  assert((*I)->getLocation().asLocation().isValid());
   continue;
 }
 


Index: test/Analysis/call_once.cpp
===
--- test/Analysis/call_once.cpp
+++ test/Analysis/call_once.cpp
@@ -1,10 +1,11 @@
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -verify %s
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -verify %s -o %t.report
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s -o %t.report
 
 // We do NOT model libcxx03 implementation, but the analyzer should still
 // not crash.
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -verify %s
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -DEMULATE_LIBSTDCPP -verify %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -verify %s -o %t.report
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -DEMULATE_LIBSTDCPP -verify %s -o %t.report
+// RUN: rm -rf %t.report
 
 void clang_analyzer_eval(bool);
 
Index: lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- lib/StaticAnalyzer/Core/BugReporter.cpp
+++ lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -229,7 +229,6 @@
 PathDiagnosticCallPiece *Call = dyn_cast(I->get());
 
 if (!Call) {
-  assert((*I)->getLocation().asLocation().isValid());
   continue;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D23934: Add a -ffixed-date-time= flag that sets the initial value of __DATE__, __TIME__, __TIMESTAMP__

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai added a comment.

Cannot tell for sure from code but looks like we are still emitting 
`-Wdate-time` "expansion of date or time macro is not reproducible" with this 
flag. At least it's not covered by tests. And another similar warning is 
`-Wpch-date-time`.


https://reviews.llvm.org/D23934



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

[PATCH] D33563: Track whether a unary operation can overflow

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: include/clang/AST/Expr.h:1728
+  UnaryOperator(Expr *input, Opcode opc, QualType type, ExprValueKind VK,
+ExprObjectKind OK, SourceLocation l, bool CanOverflow = false)
+  : Expr(UnaryOperatorClass, type, VK, OK,

Is the default argument necessary here?  Better to avoid when possible.



Comment at: lib/Sema/SemaExpr.cpp:12212
   case UO_Minus:
+CanOverflow = isOverflowingIntegerType(Context, Input.get()->getType());
 Input = UsualUnaryConversions(Input.get());

UO_Plus can't overflow.



Comment at: test/Misc/ast-dump-stmt.c:66
+  // CHECK:ImplicitCastExpr
+  // CHECK:  DeclRefExpr{{.*}}'T2' 'int'
+}

What does it mean for bitwise complement to "overflow"?


https://reviews.llvm.org/D33563



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

[PATCH] D41680: [analyzer] do not crash with assertion on processing locations of bodyfarmed functions

[Artem Dergachev via Phabricator via cfe-commits]

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

Yep, so it still doesn't answer if `removePiecesWithInvalidLocations()` was 
dead code to begin with (considering that the assertion in 
`adjustCallLocations()` says that everything but call locations is valid by 
now, and call locations are fixed immediately after that). The piece with 
invalid location seems to be a control flow piece (grey piece / arrow) which is 
indeed not to be displayed to the user in this case. I'm still not sure 
how/if-at-all this worked before. But the new behavior looks correct and i 
don't see these questions as the most pressing issues we're having at the 
moment :)


https://reviews.llvm.org/D41680



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

[PATCH] D41680: [analyzer] do not crash with assertion on processing locations of bodyfarmed functions

[George Karpenkov via Phabricator via cfe-commits]

george.karpenkov added a comment.

The error is triggered when analyzer finds a bug *inside* the callable captured 
by the body farm.
Probably we didn't see the crash in the wild because either
a) the clang build did not have assertions enabled
or
b) the HTML output was not enabled

and the bug needs both to trigger.
In any case it does not make sense to assert that invalid locations are not 
present on the path if right after we are calling a subroutine which removes 
all diagnostics which do have invalid locations.


https://reviews.llvm.org/D41680



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

[PATCH] D41512: [Sema] -Wtautological-constant-compare is too good. Cripple it.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri updated this revision to Diff 128470.
lebedev.ri added a comment.

Actually update the diagnostic flag :)

I'm going to hold off committing just yet, and wait for @rsmith to sign off.


Repository:
  rC Clang

https://reviews.llvm.org/D41512

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  test/Sema/compare.c
  test/Sema/tautological-constant-compare.c
  test/Sema/tautological-constant-enum-compare.c
  test/Sema/tautological-unsigned-enum-zero-compare.c
  test/Sema/tautological-unsigned-enum-zero-compare.cpp
  test/Sema/tautological-unsigned-zero-compare.c
  test/SemaCXX/compare.cpp

Index: test/SemaCXX/compare.cpp
===
--- test/SemaCXX/compare.cpp
+++ test/SemaCXX/compare.cpp
@@ -1,7 +1,7 @@
 // Force x86-64 because some of our heuristics are actually based
 // on integer sizes.
 
-// RUN: %clang_cc1 -triple x86_64-apple-darwin -fsyntax-only -pedantic -verify -Wsign-compare -std=c++11 %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin -fsyntax-only -pedantic -verify -Wsign-compare -Wtautological-constant-in-range-compare -std=c++11 %s
 
 int test0(long a, unsigned long b) {
   enum EnumA {A};
Index: test/Sema/tautological-unsigned-zero-compare.c
===
--- test/Sema/tautological-unsigned-zero-compare.c
+++ test/Sema/tautological-unsigned-zero-compare.c
@@ -1,7 +1,13 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
-// RUN: %clang_cc1 -fsyntax-only -Wno-tautological-unsigned-zero-compare -verify=silence %s
-// RUN: %clang_cc1 -fsyntax-only -verify -x c++ %s
-// RUN: %clang_cc1 -fsyntax-only -Wno-tautological-unsigned-zero-compare -verify=silence -x c++ %s
+// RUN: %clang_cc1 -fsyntax-only \
+// RUN:-Wtautological-unsigned-zero-compare \
+// RUN:-verify %s
+// RUN: %clang_cc1 -fsyntax-only \
+// RUN:-verify=silence %s
+// RUN: %clang_cc1 -fsyntax-only \
+// RUN:-Wtautological-unsigned-zero-compare \
+// RUN:-verify -x c++ %s
+// RUN: %clang_cc1 -fsyntax-only \
+// RUN:-verify=silence -x c++ %s
 
 unsigned uvalue(void);
 signed int svalue(void);
@@ -32,10 +38,39 @@
   TFunc();
 #endif
 
+  short s = svalue();
+
   unsigned un = uvalue();
 
   // silence-no-diagnostics
 
+  // Note: both sides are promoted to unsigned long prior to the comparison.
+  if (s == 0UL)
+  return 0;
+  if (s != 0UL)
+  return 0;
+  if (s < 0UL) // expected-warning {{comparison of unsigned expression < 0 is always false}}
+  return 0;
+  if (s <= 0UL)
+  return 0;
+  if (s > 0UL)
+  return 0;
+  if (s >= 0UL) // expected-warning {{comparison of unsigned expression >= 0 is always true}}
+  return 0;
+
+  if (0UL == s)
+  return 0;
+  if (0UL != s)
+  return 0;
+  if (0UL < s)
+  return 0;
+  if (0UL <= s) // expected-warning {{comparison of 0 <= unsigned expression is always true}}
+  return 0;
+  if (0UL > s) // expected-warning {{comparison of 0 > unsigned expression is always false}}
+  return 0;
+  if (0UL >= s)
+  return 0;
+
   if (un == 0)
   return 0;
   if (un != 0)
Index: test/Sema/tautological-unsigned-enum-zero-compare.cpp
===
--- test/Sema/tautological-unsigned-enum-zero-compare.cpp
+++ test/Sema/tautological-unsigned-enum-zero-compare.cpp
@@ -1,9 +1,10 @@
 // RUN: %clang_cc1 -std=c++11 -triple=x86_64-pc-linux-gnu -fsyntax-only \
+// RUN:-Wtautological-unsigned-enum-zero-compare \
 // RUN:-verify=unsigned,unsigned-signed %s
 // RUN: %clang_cc1 -std=c++11 -triple=x86_64-pc-win32 -fsyntax-only \
+// RUN:-Wtautological-unsigned-enum-zero-compare \
 // RUN:-verify=unsigned-signed %s
 // RUN: %clang_cc1 -std=c++11 -triple=x86_64-pc-win32 -fsyntax-only \
-// RUN:-Wno-tautological-unsigned-enum-zero-compare \
 // RUN:-verify=silence %s
 
 // silence-no-diagnostics
Index: test/Sema/tautological-unsigned-enum-zero-compare.c
===
--- test/Sema/tautological-unsigned-enum-zero-compare.c
+++ test/Sema/tautological-unsigned-enum-zero-compare.c
@@ -1,9 +1,10 @@
 // RUN: %clang_cc1 -triple=x86_64-pc-linux-gnu -fsyntax-only \
+// RUN:-Wtautological-unsigned-enum-zero-compare \
 // RUN:-verify=unsigned,unsigned-signed %s
 // RUN: %clang_cc1 -triple=x86_64-pc-win32 -fsyntax-only \
+// RUN:-Wtautological-unsigned-enum-zero-compare \
 // RUN:-verify=unsigned-signed %s
 // RUN: %clang_cc1 -triple=x86_64-pc-win32 -fsyntax-only \
-// RUN:-Wno-tautological-unsigned-enum-zero-compare \
 // RUN:-verify=silence %s
 
 // Okay, this is where it gets complicated.
Index: test/Sema/tautological-constant-enum-compare.c
===

[libunwind] r321680 - Reland [PPC64] Port to ppc64le - initial version

[Martin Storsjo via cfe-commits]

Author: mstorsjo
Date: Tue Jan  2 14:11:30 2018
New Revision: 321680

URL: http://llvm.org/viewvc/llvm-project?rev=321680=rev
Log:
Reland [PPC64] Port to ppc64le - initial version

Initial working version of libunwind for PowerPC 64. Tested on
little-endian ppc64 host only.
Based on the existing PowerPC 32 code.

It supports:

- context save/restore (unw_getcontext, unw_init_local, unw_resume)
- read/write from/to saved registers
- backtrace (unw_step)

Patch by Leandro Lupori!

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

Now builds with LIBUNWIND_ENABLE_CROSS_UNWINDING=ON should
work.

Modified:
libunwind/trunk/include/__libunwind_config.h
libunwind/trunk/include/libunwind.h
libunwind/trunk/src/AddressSpace.hpp
libunwind/trunk/src/Registers.hpp
libunwind/trunk/src/UnwindCursor.hpp
libunwind/trunk/src/UnwindRegistersRestore.S
libunwind/trunk/src/UnwindRegistersSave.S
libunwind/trunk/src/assembly.h
libunwind/trunk/src/config.h
libunwind/trunk/src/libunwind.cpp

Modified: libunwind/trunk/include/__libunwind_config.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/__libunwind_config.h?rev=321680=321679=321680=diff
==
--- libunwind/trunk/include/__libunwind_config.h (original)
+++ libunwind/trunk/include/__libunwind_config.h Tue Jan  2 14:11:30 2018
@@ -18,6 +18,7 @@
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_X86   8
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_X86_6432
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_PPC   112
+#define _LIBUNWIND_HIGHEST_DWARF_REGISTER_PPC64 110
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_ARM64 95
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_ARM   287
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_OR1K  31
@@ -39,6 +40,11 @@
 #define _LIBUNWIND_CURSOR_SIZE 33
 #  endif
 #  define _LIBUNWIND_HIGHEST_DWARF_REGISTER 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_X86_64
+# elif defined(__powerpc64__)
+#  define _LIBUNWIND_TARGET_PPC64 1
+#  define _LIBUNWIND_CONTEXT_SIZE 136
+#  define _LIBUNWIND_CURSOR_SIZE 148
+#  define _LIBUNWIND_HIGHEST_DWARF_REGISTER 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_PPC64
 # elif defined(__ppc__)
 #  define _LIBUNWIND_TARGET_PPC 1
 #  define _LIBUNWIND_CONTEXT_SIZE 117
@@ -84,13 +90,14 @@
 # define _LIBUNWIND_TARGET_I386
 # define _LIBUNWIND_TARGET_X86_64 1
 # define _LIBUNWIND_TARGET_PPC 1
+# define _LIBUNWIND_TARGET_PPC64 1
 # define _LIBUNWIND_TARGET_AARCH64 1
 # define _LIBUNWIND_TARGET_ARM 1
 # define _LIBUNWIND_TARGET_OR1K 1
 # define _LIBUNWIND_TARGET_MIPS_O32 1
 # define _LIBUNWIND_TARGET_MIPS_N64 1
-# define _LIBUNWIND_CONTEXT_SIZE 128
-# define _LIBUNWIND_CURSOR_SIZE 140
+# define _LIBUNWIND_CONTEXT_SIZE 136
+# define _LIBUNWIND_CURSOR_SIZE 148
 # define _LIBUNWIND_HIGHEST_DWARF_REGISTER 287
 #endif // _LIBUNWIND_IS_NATIVE_ONLY
 

Modified: libunwind/trunk/include/libunwind.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/libunwind.h?rev=321680=321679=321680=diff
==
--- libunwind/trunk/include/libunwind.h (original)
+++ libunwind/trunk/include/libunwind.h Tue Jan  2 14:11:30 2018
@@ -325,6 +325,120 @@ enum {
   UNW_PPC_SPEFSCR = 112
 };
 
+// 64-bit ppc register numbers
+enum {
+  UNW_PPC64_R0  = 0,
+  UNW_PPC64_R1  = 1,
+  UNW_PPC64_R2  = 2,
+  UNW_PPC64_R3  = 3,
+  UNW_PPC64_R4  = 4,
+  UNW_PPC64_R5  = 5,
+  UNW_PPC64_R6  = 6,
+  UNW_PPC64_R7  = 7,
+  UNW_PPC64_R8  = 8,
+  UNW_PPC64_R9  = 9,
+  UNW_PPC64_R10 = 10,
+  UNW_PPC64_R11 = 11,
+  UNW_PPC64_R12 = 12,
+  UNW_PPC64_R13 = 13,
+  UNW_PPC64_R14 = 14,
+  UNW_PPC64_R15 = 15,
+  UNW_PPC64_R16 = 16,
+  UNW_PPC64_R17 = 17,
+  UNW_PPC64_R18 = 18,
+  UNW_PPC64_R19 = 19,
+  UNW_PPC64_R20 = 20,
+  UNW_PPC64_R21 = 21,
+  UNW_PPC64_R22 = 22,
+  UNW_PPC64_R23 = 23,
+  UNW_PPC64_R24 = 24,
+  UNW_PPC64_R25 = 25,
+  UNW_PPC64_R26 = 26,
+  UNW_PPC64_R27 = 27,
+  UNW_PPC64_R28 = 28,
+  UNW_PPC64_R29 = 29,
+  UNW_PPC64_R30 = 30,
+  UNW_PPC64_R31 = 31,
+  UNW_PPC64_F0  = 32,
+  UNW_PPC64_F1  = 33,
+  UNW_PPC64_F2  = 34,
+  UNW_PPC64_F3  = 35,
+  UNW_PPC64_F4  = 36,
+  UNW_PPC64_F5  = 37,
+  UNW_PPC64_F6  = 38,
+  UNW_PPC64_F7  = 39,
+  UNW_PPC64_F8  = 40,
+  UNW_PPC64_F9  = 41,
+  UNW_PPC64_F10 = 42,
+  UNW_PPC64_F11 = 43,
+  UNW_PPC64_F12 = 44,
+  UNW_PPC64_F13 = 45,
+  UNW_PPC64_F14 = 46,
+  UNW_PPC64_F15 = 47,
+  UNW_PPC64_F16 = 48,
+  UNW_PPC64_F17 = 49,
+  UNW_PPC64_F18 = 50,
+  UNW_PPC64_F19 = 51,
+  UNW_PPC64_F20 = 52,
+  UNW_PPC64_F21 = 53,
+  UNW_PPC64_F22 = 54,
+  UNW_PPC64_F23 = 55,
+  UNW_PPC64_F24 = 56,
+  UNW_PPC64_F25 = 57,
+  UNW_PPC64_F26 = 58,
+  UNW_PPC64_F27 = 59,
+  UNW_PPC64_F28 = 60,
+  UNW_PPC64_F29 = 61,
+  UNW_PPC64_F30 = 62,
+  UNW_PPC64_F31 = 63,
+  UNW_PPC64_LR  = 64,
+  UNW_PPC64_CTR = 65,
+  UNW_PPC64_CR0 = 66,
+  UNW_PPC64_CR1 = 67,
+  UNW_PPC64_CR2 = 68,
+  UNW_PPC64_CR3 = 69,
+  UNW_PPC64_CR4 = 70,
+  UNW_PPC64_CR5 = 71,
+  

[libunwind] r321679 - Don't use a strict larger-than comparison in the check_fit/does_fit static assert

[Martin Storsjo via cfe-commits]

Author: mstorsjo
Date: Tue Jan  2 14:11:22 2018
New Revision: 321679

URL: http://llvm.org/viewvc/llvm-project?rev=321679=rev
Log:
Don't use a strict larger-than comparison in the check_fit/does_fit static 
assert

For builds that only target one architecture, this was required to
be an exact match, while it previously required the allocation to be
strictly larger than the largest concrete one. Requiring it to be
larger than on equal should be enough.

This makes it more straightforward to update _LIBUNWIND_CONTEXT_SIZE
and _LIBUNWIND_CURSOR_SIZE.

Modified:
libunwind/trunk/src/config.h

Modified: libunwind/trunk/src/config.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/config.h?rev=321679=321678=321679=diff
==
--- libunwind/trunk/src/config.h (original)
+++ libunwind/trunk/src/config.h Tue Jan  2 14:11:22 2018
@@ -155,7 +155,7 @@
 #if defined(_LIBUNWIND_IS_NATIVE_ONLY)
 # define COMP_OP ==
 #else
-# define COMP_OP <
+# define COMP_OP <=
 #endif
 template 
 struct check_fit {


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

[PATCH] D41416: [modules] [pch] Do not deserialize all lazy template specializations when looking for one.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

This is looking like a really good start; we'll still want to do something 
about partial specializations, but this should already help a lot.

Can you produce some sample performance numbers for this change? This is 
replacing a linear-time algorithm (with a high constant) with a quadratic-time 
algorithm (with a lower constant), and it'd be useful to confirm that's not 
going to be a pressing problem in the short term. (In the medium term, we 
should move to using an on-disk hash table for template specialization lookup, 
at least for templates with large numbers of specializations.)




Comment at: include/clang/AST/DeclTemplate.h:762-765
+bool operator< (const LazySpecializationInfo ) const {
+  return DeclID < Other.DeclID;
+}
+bool operator== (const LazySpecializationInfo ) const {

No space between operator and `(`, please.



Comment at: lib/AST/DeclTemplate.cpp:209
+  if (Specs[I+1].ODRHash == Hash)
+(void)loadLazySpecializationImpl(Specs[I+1].DeclID);
+   }

Can we remove the loaded specializations from the list / zero them out, so know 
we've already asked the ExternalASTSource for them?



Comment at: lib/AST/DeclTemplate.cpp:235-242
 #ifndef NDEBUG
 void *CorrectInsertPos;
 assert(!findSpecializationImpl(Specializations,
SETraits::getTemplateArgs(Entry),
CorrectInsertPos) &&
InsertPos == CorrectInsertPos &&
"given incorrect InsertPos for specialization");

I'm a little concerned about this: a debug build could perform more 
deserialization than an optimized build here. It's probably not a big deal, but 
it could lead to some surprising debugging experiences down the line (where a 
debug build works but an optimized build misbehaves).

Perhaps we could assert that there are no lazy specializations with the 
relevant hash in our list before performing this lookup? (This'd require that 
we remove them as we load them.)



Comment at: lib/Serialization/ASTReader.cpp:7009-7010
+Args = CTSD->getTemplateArgs().asArray();
   }
+  else if (auto *VTSD = dyn_cast(D)) {
+Template = VTSD->getSpecializedTemplate();

`}` and `else` on same line, please.


https://reviews.llvm.org/D41416



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

[PATCH] D41386: [libunwind][PPC64] Port to ppc64le - initial version

[Tim Shen via Phabricator via cfe-commits]

timshen added a comment.

In https://reviews.llvm.org/D41386#966189, @mstorsjo wrote:

> In https://reviews.llvm.org/D41386#966187, @timshen wrote:
>
> > The static_assert on line 1189 fails with the following build on x86:
> >
> >   cmake -GNinja -DLIBUNWIND_ENABLE_CROSS_UNWINDING=ON 
> > -DLLVM_PATH=$PATH_TO_LLVM $PATH_TO_LIBUNWIND && ninja libunwind.a
> >   
> >
> > It seems that 136 in `# define _LIBUNWIND_CONTEXT_SIZE 136` is too small. 
> > Reverting the patch for now.
>
>
> Actually, I can fix this directly without having to revert, if you give me a 
> couple minutes.


Ah sorry, didn't see this earlier. It's already reverted. :(


Repository:
  rL LLVM

https://reviews.llvm.org/D41386



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

[libunwind] r321678 - Revert `rL321667: [PPC64] Port to ppc64le - initial version`

[Tim Shen via cfe-commits]

Author: timshen
Date: Tue Jan  2 14:04:03 2018
New Revision: 321678

URL: http://llvm.org/viewvc/llvm-project?rev=321678=rev
Log:
Revert `rL321667: [PPC64] Port to ppc64le - initial version`

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

Modified:
libunwind/trunk/include/__libunwind_config.h
libunwind/trunk/include/libunwind.h
libunwind/trunk/src/AddressSpace.hpp
libunwind/trunk/src/Registers.hpp
libunwind/trunk/src/UnwindCursor.hpp
libunwind/trunk/src/UnwindRegistersRestore.S
libunwind/trunk/src/UnwindRegistersSave.S
libunwind/trunk/src/assembly.h
libunwind/trunk/src/config.h
libunwind/trunk/src/libunwind.cpp

Modified: libunwind/trunk/include/__libunwind_config.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/__libunwind_config.h?rev=321678=321677=321678=diff
==
--- libunwind/trunk/include/__libunwind_config.h (original)
+++ libunwind/trunk/include/__libunwind_config.h Tue Jan  2 14:04:03 2018
@@ -18,7 +18,6 @@
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_X86   8
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_X86_6432
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_PPC   112
-#define _LIBUNWIND_HIGHEST_DWARF_REGISTER_PPC64 110
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_ARM64 95
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_ARM   287
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_OR1K  31
@@ -40,11 +39,6 @@
 #define _LIBUNWIND_CURSOR_SIZE 33
 #  endif
 #  define _LIBUNWIND_HIGHEST_DWARF_REGISTER 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_X86_64
-# elif defined(__powerpc64__)
-#  define _LIBUNWIND_TARGET_PPC64 1
-#  define _LIBUNWIND_CONTEXT_SIZE 136
-#  define _LIBUNWIND_CURSOR_SIZE 148
-#  define _LIBUNWIND_HIGHEST_DWARF_REGISTER 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_PPC64
 # elif defined(__ppc__)
 #  define _LIBUNWIND_TARGET_PPC 1
 #  define _LIBUNWIND_CONTEXT_SIZE 117
@@ -90,14 +84,13 @@
 # define _LIBUNWIND_TARGET_I386
 # define _LIBUNWIND_TARGET_X86_64 1
 # define _LIBUNWIND_TARGET_PPC 1
-# define _LIBUNWIND_TARGET_PPC64 1
 # define _LIBUNWIND_TARGET_AARCH64 1
 # define _LIBUNWIND_TARGET_ARM 1
 # define _LIBUNWIND_TARGET_OR1K 1
 # define _LIBUNWIND_TARGET_MIPS_O32 1
 # define _LIBUNWIND_TARGET_MIPS_N64 1
-# define _LIBUNWIND_CONTEXT_SIZE 136
-# define _LIBUNWIND_CURSOR_SIZE 148
+# define _LIBUNWIND_CONTEXT_SIZE 128
+# define _LIBUNWIND_CURSOR_SIZE 140
 # define _LIBUNWIND_HIGHEST_DWARF_REGISTER 287
 #endif // _LIBUNWIND_IS_NATIVE_ONLY
 

Modified: libunwind/trunk/include/libunwind.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/libunwind.h?rev=321678=321677=321678=diff
==
--- libunwind/trunk/include/libunwind.h (original)
+++ libunwind/trunk/include/libunwind.h Tue Jan  2 14:04:03 2018
@@ -325,120 +325,6 @@ enum {
   UNW_PPC_SPEFSCR = 112
 };
 
-// 64-bit ppc register numbers
-enum {
-  UNW_PPC64_R0  = 0,
-  UNW_PPC64_R1  = 1,
-  UNW_PPC64_R2  = 2,
-  UNW_PPC64_R3  = 3,
-  UNW_PPC64_R4  = 4,
-  UNW_PPC64_R5  = 5,
-  UNW_PPC64_R6  = 6,
-  UNW_PPC64_R7  = 7,
-  UNW_PPC64_R8  = 8,
-  UNW_PPC64_R9  = 9,
-  UNW_PPC64_R10 = 10,
-  UNW_PPC64_R11 = 11,
-  UNW_PPC64_R12 = 12,
-  UNW_PPC64_R13 = 13,
-  UNW_PPC64_R14 = 14,
-  UNW_PPC64_R15 = 15,
-  UNW_PPC64_R16 = 16,
-  UNW_PPC64_R17 = 17,
-  UNW_PPC64_R18 = 18,
-  UNW_PPC64_R19 = 19,
-  UNW_PPC64_R20 = 20,
-  UNW_PPC64_R21 = 21,
-  UNW_PPC64_R22 = 22,
-  UNW_PPC64_R23 = 23,
-  UNW_PPC64_R24 = 24,
-  UNW_PPC64_R25 = 25,
-  UNW_PPC64_R26 = 26,
-  UNW_PPC64_R27 = 27,
-  UNW_PPC64_R28 = 28,
-  UNW_PPC64_R29 = 29,
-  UNW_PPC64_R30 = 30,
-  UNW_PPC64_R31 = 31,
-  UNW_PPC64_F0  = 32,
-  UNW_PPC64_F1  = 33,
-  UNW_PPC64_F2  = 34,
-  UNW_PPC64_F3  = 35,
-  UNW_PPC64_F4  = 36,
-  UNW_PPC64_F5  = 37,
-  UNW_PPC64_F6  = 38,
-  UNW_PPC64_F7  = 39,
-  UNW_PPC64_F8  = 40,
-  UNW_PPC64_F9  = 41,
-  UNW_PPC64_F10 = 42,
-  UNW_PPC64_F11 = 43,
-  UNW_PPC64_F12 = 44,
-  UNW_PPC64_F13 = 45,
-  UNW_PPC64_F14 = 46,
-  UNW_PPC64_F15 = 47,
-  UNW_PPC64_F16 = 48,
-  UNW_PPC64_F17 = 49,
-  UNW_PPC64_F18 = 50,
-  UNW_PPC64_F19 = 51,
-  UNW_PPC64_F20 = 52,
-  UNW_PPC64_F21 = 53,
-  UNW_PPC64_F22 = 54,
-  UNW_PPC64_F23 = 55,
-  UNW_PPC64_F24 = 56,
-  UNW_PPC64_F25 = 57,
-  UNW_PPC64_F26 = 58,
-  UNW_PPC64_F27 = 59,
-  UNW_PPC64_F28 = 60,
-  UNW_PPC64_F29 = 61,
-  UNW_PPC64_F30 = 62,
-  UNW_PPC64_F31 = 63,
-  UNW_PPC64_LR  = 64,
-  UNW_PPC64_CTR = 65,
-  UNW_PPC64_CR0 = 66,
-  UNW_PPC64_CR1 = 67,
-  UNW_PPC64_CR2 = 68,
-  UNW_PPC64_CR3 = 69,
-  UNW_PPC64_CR4 = 70,
-  UNW_PPC64_CR5 = 71,
-  UNW_PPC64_CR6 = 72,
-  UNW_PPC64_CR7 = 73,
-  UNW_PPC64_XER = 74,
-  UNW_PPC64_V0  = 75,
-  UNW_PPC64_V1  = 76,
-  UNW_PPC64_V2  = 77,
-  UNW_PPC64_V3  = 78,
-  UNW_PPC64_V4  = 79,
-  UNW_PPC64_V5  = 80,
-  UNW_PPC64_V6  = 81,
-  UNW_PPC64_V7  = 82,
-  UNW_PPC64_V8  = 83,
-  UNW_PPC64_V9  = 84,
-  UNW_PPC64_V10 = 85,
-  UNW_PPC64_V11 = 86,
-  UNW_PPC64_V12 = 87,
- 

[PATCH] D41386: [libunwind][PPC64] Port to ppc64le - initial version

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In https://reviews.llvm.org/D41386#966187, @timshen wrote:

> The static_assert on line 1189 fails with the following build on x86:
>
>   cmake -GNinja -DLIBUNWIND_ENABLE_CROSS_UNWINDING=ON 
> -DLLVM_PATH=$PATH_TO_LLVM $PATH_TO_LIBUNWIND && ninja libunwind.a
>   
>
> It seems that 136 in `# define _LIBUNWIND_CONTEXT_SIZE 136` is too small. 
> Reverting the patch for now.


Actually, I can fix this directly without having to revert, if you give me a 
couple minutes.


Repository:
  rL LLVM

https://reviews.llvm.org/D41386



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

[PATCH] D41386: [libunwind][PPC64] Port to ppc64le - initial version

[Tim Shen via Phabricator via cfe-commits]

timshen added a comment.

The static_assert on line 1189 fails with the following build on x86:

  cmake -GNinja -DLIBUNWIND_ENABLE_CROSS_UNWINDING=ON -DLLVM_PATH=$PATH_TO_LLVM 
$PATH_TO_LIBUNWIND && ninja libunwind.a

It seems that 136 in `# define _LIBUNWIND_CONTEXT_SIZE 136` is too small. 
Reverting the patch for now.


Repository:
  rL LLVM

https://reviews.llvm.org/D41386



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

[PATCH] D41416: [modules] [pch] Do not deserialize all lazy template specializations when looking for one.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added inline comments.



Comment at: lib/Serialization/ASTReaderDecl.cpp:92
   for (unsigned I = 0, Size = Record.readInt(); I != Size; ++I)
-IDs.push_back(ReadDeclID());
+IDs.push_back(LazySpecializationInfo(ReadDeclID(), Record.readInt()));
 }

rsmith wrote:
> Move these subexpressions to separate statements; the two "read" calls are 
> not sequenced here.
Good catch!


https://reviews.llvm.org/D41416



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

[PATCH] D41416: [modules] [pch] Do not deserialize all lazy template specializations when looking for one.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 128465.
v.g.vassilev added a comment.

Teach `ASTReader::CompleteRedeclChain` to load only the template 
specializations with the same template argument list.


https://reviews.llvm.org/D41416

Files:
  include/clang/AST/DeclTemplate.h
  lib/AST/DeclTemplate.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriter.cpp
  lib/Serialization/ASTWriterDecl.cpp

Index: lib/Serialization/ASTWriterDecl.cpp
===
--- lib/Serialization/ASTWriterDecl.cpp
+++ lib/Serialization/ASTWriterDecl.cpp
@@ -162,22 +162,57 @@
   Record.AddSourceLocation(typeParams->getRAngleLoc());
 }
 
-/// Add to the record the first declaration from each module file that
-/// provides a declaration of D. The intent is to provide a sufficient
-/// set such that reloading this set will load all current redeclarations.
-void AddFirstDeclFromEachModule(const Decl *D, bool IncludeLocal) {
-  llvm::MapVector Firsts;
+/// Collect the first declaration from each module file that provides a
+/// declaration of D.
+void CollectFirstDeclFromEachModule(const Decl *D, bool IncludeLocal,
+llvm::MapVector ) {
+
   // FIXME: We can skip entries that we know are implied by others.
   for (const Decl *R = D->getMostRecentDecl(); R; R = R->getPreviousDecl()) {
 if (R->isFromASTFile())
   Firsts[Writer.Chain->getOwningModuleFile(R)] = R;
 else if (IncludeLocal)
   Firsts[nullptr] = R;
   }
+}
+
+/// Add to the record the first declaration from each module file that
+/// provides a declaration of D. The intent is to provide a sufficient
+/// set such that reloading this set will load all current redeclarations.
+void AddFirstDeclFromEachModule(const Decl *D, bool IncludeLocal) {
+  llvm::MapVector Firsts;
+  CollectFirstDeclFromEachModule(D, IncludeLocal, Firsts);
+
   for (const auto  : Firsts)
 Record.AddDeclRef(F.second);
 }
 
+/// Add to the record the first template specialization from each module
+/// file that provides a declaration of D. We store the DeclId and an
+/// ODRHash of the template arguments of D which should provide enough
+/// information to load D only if the template instantiator needs it.
+void AddFirstSpecializationDeclFromEachModule(const Decl *D,
+  bool IncludeLocal) {
+  assert(isa(D) ||
+ isa(D) || isa(D) &&
+ "Must not be called with other decls");
+  llvm::MapVector Firsts;
+  CollectFirstDeclFromEachModule(D, IncludeLocal, Firsts);
+
+  for (const auto  : Firsts) {
+Record.AddDeclRef(F.second);
+ArrayRef Args;
+if (auto *CTSD = dyn_cast(D))
+  Args = CTSD->getTemplateArgs().asArray();
+else if (auto *VTSD = dyn_cast(D))
+  Args = VTSD->getTemplateArgs().asArray();
+else if (auto *FD = dyn_cast(D))
+  Args = FD->getTemplateSpecializationArgs()->asArray();
+assert(Args.size());
+Record.push_back(TemplateArgumentList::ComputeODRHash(Args));
+  }
+}
+
 /// Get the specialization decl from an entry in the specialization list.
 template 
 typename RedeclarableTemplateDecl::SpecEntryTraits::DeclType *
@@ -190,7 +225,8 @@
 decltype(T::PartialSpecializations) (T *Common) {
   return Common->PartialSpecializations;
 }
-ArrayRef getPartialSpecializations(FunctionTemplateDecl::Common *) {
+MutableArrayRef
+getPartialSpecializations(FunctionTemplateDecl::Common *) {
   return None;
 }
 
@@ -207,9 +243,11 @@
 assert(!Common->LazySpecializations);
   }
 
-  ArrayRef LazySpecializations;
+  using LazySpecializationInfo
+= RedeclarableTemplateDecl::LazySpecializationInfo;
+  ArrayRef LazySpecializations;
   if (auto *LS = Common->LazySpecializations)
-LazySpecializations = llvm::makeArrayRef(LS + 1, LS[0]);
+LazySpecializations = llvm::makeArrayRef(LS + 1, LS[0].DeclID);
 
   // Add a slot to the record for the number of specializations.
   unsigned I = Record.size();
@@ -225,12 +263,18 @@
 
   for (auto *D : Specs) {
 assert(D->isCanonicalDecl() && "non-canonical decl in set");
-AddFirstDeclFromEachModule(D, /*IncludeLocal*/true);
+AddFirstSpecializationDeclFromEachModule(D, /*IncludeLocal*/true);
+  }
+  for (auto  : LazySpecializations) {
+Record.push_back(IDHashPair.DeclID);
+Record.push_back(IDHashPair.ODRHash);
   }
-  Record.append(LazySpecializations.begin(), LazySpecializations.end());
 
-  // Update the size entry we added earlier.
-  Record[I] = Record.size() - I - 1;

[PATCH] D41421: Eliminate a magic number. NFC.

[Matt Davis via Phabricator via cfe-commits]

mattd added a comment.

Ping :) I would like someone to commit this on my behalf, thanks!


https://reviews.llvm.org/D41421



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

[PATCH] D38320: [clang] Fix serializers for `TypeTemplateParmDecl` + related types

[Steve O'Brien via Phabricator via cfe-commits]

elsteveogrande updated this revision to Diff 128466.
elsteveogrande edited the summary of this revision.
elsteveogrande added a comment.

Fixed local var names.  Using `arc diff` which hopefully submits latest changes 
w/ full context


Repository:
  rC Clang

https://reviews.llvm.org/D38320

Files:
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/PCH/cxx-templates.cpp
  test/PCH/cxx-templates.h

Index: test/PCH/cxx-templates.h
===
--- test/PCH/cxx-templates.h
+++ test/PCH/cxx-templates.h
@@ -361,3 +361,38 @@
 namespace MemberSpecializationLocation {
   template struct A { static int n; };
 }
+
+// https://bugs.llvm.org/show_bug.cgi?id=34728
+namespace PR34728 {
+
+// case 1: defaulted `NonTypeTemplateParmDecl`, non-defaulted 2nd tpl param
+template 
+int func1(T const &);
+
+template 
+int func1(T const &) {
+  return foo;
+}
+
+// case 2: defaulted `TemplateTypeParmDecl`, non-defaulted 2nd tpl param
+template 
+A func2(B const &);
+
+template 
+A func2(B const &) {
+  return 69;
+}
+
+// case 3: defaulted `TemplateTemplateParmDecl`, non-defaulted 2nd tpl param
+template 
+struct Container { T const  };
+
+template  class C = Container, class D>
+C func3(D const &);
+
+template  class C, class D>
+C func3(D const ) {
+  return Container{d};
+}
+
+} // end namespace PR34728
Index: test/PCH/cxx-templates.cpp
===
--- test/PCH/cxx-templates.cpp
+++ test/PCH/cxx-templates.cpp
@@ -116,3 +116,14 @@
 #endif
   int k = A::n;
 }
+
+// https://bugs.llvm.org/show_bug.cgi?id=34728
+namespace PR34728 {
+int test() {
+  int z1 = func1(2.718);
+  int z2 = func2(3.142);
+  int z3 = 12;
+  Container c = func3(z3);
+  return z1 + z2 + c.item;
+}
+} // end namespace PR34728
Index: lib/Serialization/ASTWriterDecl.cpp
===
--- lib/Serialization/ASTWriterDecl.cpp
+++ lib/Serialization/ASTWriterDecl.cpp
@@ -1542,11 +1542,24 @@
 
   Record.push_back(D->wasDeclaredWithTypename());
 
-  bool OwnsDefaultArg = D->hasDefaultArgument() &&
-!D->defaultArgumentWasInherited();
-  Record.push_back(OwnsDefaultArg);
-  if (OwnsDefaultArg)
-Record.AddTypeSourceInfo(D->getDefaultArgumentInfo());
+  TypeSourceInfo *OwnedDefaultArg = nullptr;
+  Decl const *InheritsFromDecl = nullptr;
+  if (D->hasDefaultArgument()) {
+if (D->defaultArgumentWasInherited()) {
+  InheritsFromDecl = D->getDefaultArgStorage().getInheritedFrom();
+} else {
+  OwnedDefaultArg = D->getDefaultArgumentInfo();
+}
+  }
+
+  Record.push_back(OwnedDefaultArg != nullptr);
+  if (OwnedDefaultArg) {
+Record.AddTypeSourceInfo(OwnedDefaultArg);
+  }
+  Record.push_back(InheritsFromDecl != nullptr);
+  if (InheritsFromDecl) {
+Record.AddDeclRef(InheritsFromDecl);
+  }
 
   Code = serialization::DECL_TEMPLATE_TYPE_PARM;
 }
@@ -1573,11 +1586,26 @@
   } else {
 // Rest of NonTypeTemplateParmDecl.
 Record.push_back(D->isParameterPack());
-bool OwnsDefaultArg = D->hasDefaultArgument() &&
-  !D->defaultArgumentWasInherited();
-Record.push_back(OwnsDefaultArg);
-if (OwnsDefaultArg)
-  Record.AddStmt(D->getDefaultArgument());
+
+Expr *OwnedDefaultArg = nullptr;
+Decl const *InheritsFromDecl = nullptr;
+if (D->hasDefaultArgument()) {
+  if (D->defaultArgumentWasInherited()) {
+InheritsFromDecl = D->getDefaultArgStorage().getInheritedFrom();
+  } else {
+OwnedDefaultArg = D->getDefaultArgument();
+  }
+}
+
+Record.push_back(OwnedDefaultArg != nullptr);
+if (OwnedDefaultArg) {
+  Record.AddStmt(OwnedDefaultArg);
+}
+Record.push_back(InheritsFromDecl != nullptr);
+if (InheritsFromDecl) {
+  Record.AddDeclRef(InheritsFromDecl);
+}
+
 Code = serialization::DECL_NON_TYPE_TEMPLATE_PARM;
   }
 }
@@ -1602,11 +1630,26 @@
   } else {
 // Rest of TemplateTemplateParmDecl.
 Record.push_back(D->isParameterPack());
-bool OwnsDefaultArg = D->hasDefaultArgument() &&
-  !D->defaultArgumentWasInherited();
-Record.push_back(OwnsDefaultArg);
-if (OwnsDefaultArg)
-  Record.AddTemplateArgumentLoc(D->getDefaultArgument());
+
+llvm::Optional OwnedDefaultArg;
+Decl const *InheritsFromDecl = nullptr;
+if (D->hasDefaultArgument()) {
+  if (D->defaultArgumentWasInherited()) {
+InheritsFromDecl = D->getDefaultArgStorage().getInheritedFrom();
+  } else {
+OwnedDefaultArg = D->getDefaultArgument();
+  }
+}
+
+Record.push_back(OwnedDefaultArg.hasValue());
+if (OwnedDefaultArg.hasValue()) {
+  Record.AddTemplateArgumentLoc(*OwnedDefaultArg);
+}
+Record.push_back(InheritsFromDecl != nullptr);
+if (InheritsFromDecl) {
+  Record.AddDeclRef(InheritsFromDecl);
+}
+
 Code = 

[PATCH] D41512: [Sema] -Wtautological-constant-compare is too good. Cripple it.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri updated this revision to Diff 128462.
lebedev.ri marked 3 inline comments as done.
lebedev.ri added a comment.

Renamed `TautologicalRangeCompare` to `TautologicalInRangeCompare`.

Given that previous version of this differential was already previously 
accepted,
and the fact that this needs to happen before the branch, which is rapidly 
approaching,
i'm going to proceed to committing this now.


Repository:
  rC Clang

https://reviews.llvm.org/D41512

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  test/Sema/compare.c
  test/Sema/tautological-constant-compare.c
  test/Sema/tautological-constant-enum-compare.c
  test/Sema/tautological-unsigned-enum-zero-compare.c
  test/Sema/tautological-unsigned-enum-zero-compare.cpp
  test/Sema/tautological-unsigned-zero-compare.c
  test/SemaCXX/compare.cpp

Index: test/SemaCXX/compare.cpp
===
--- test/SemaCXX/compare.cpp
+++ test/SemaCXX/compare.cpp
@@ -1,7 +1,7 @@
 // Force x86-64 because some of our heuristics are actually based
 // on integer sizes.
 
-// RUN: %clang_cc1 -triple x86_64-apple-darwin -fsyntax-only -pedantic -verify -Wsign-compare -std=c++11 %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin -fsyntax-only -pedantic -verify -Wsign-compare -Wtautological-constant-range-compare -std=c++11 %s
 
 int test0(long a, unsigned long b) {
   enum EnumA {A};
Index: test/Sema/tautological-unsigned-zero-compare.c
===
--- test/Sema/tautological-unsigned-zero-compare.c
+++ test/Sema/tautological-unsigned-zero-compare.c
@@ -1,7 +1,13 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
-// RUN: %clang_cc1 -fsyntax-only -Wno-tautological-unsigned-zero-compare -verify=silence %s
-// RUN: %clang_cc1 -fsyntax-only -verify -x c++ %s
-// RUN: %clang_cc1 -fsyntax-only -Wno-tautological-unsigned-zero-compare -verify=silence -x c++ %s
+// RUN: %clang_cc1 -fsyntax-only \
+// RUN:-Wtautological-unsigned-zero-compare \
+// RUN:-verify %s
+// RUN: %clang_cc1 -fsyntax-only \
+// RUN:-verify=silence %s
+// RUN: %clang_cc1 -fsyntax-only \
+// RUN:-Wtautological-unsigned-zero-compare \
+// RUN:-verify -x c++ %s
+// RUN: %clang_cc1 -fsyntax-only \
+// RUN:-verify=silence -x c++ %s
 
 unsigned uvalue(void);
 signed int svalue(void);
@@ -32,10 +38,39 @@
   TFunc();
 #endif
 
+  short s = svalue();
+
   unsigned un = uvalue();
 
   // silence-no-diagnostics
 
+  // Note: both sides are promoted to unsigned long prior to the comparison.
+  if (s == 0UL)
+  return 0;
+  if (s != 0UL)
+  return 0;
+  if (s < 0UL) // expected-warning {{comparison of unsigned expression < 0 is always false}}
+  return 0;
+  if (s <= 0UL)
+  return 0;
+  if (s > 0UL)
+  return 0;
+  if (s >= 0UL) // expected-warning {{comparison of unsigned expression >= 0 is always true}}
+  return 0;
+
+  if (0UL == s)
+  return 0;
+  if (0UL != s)
+  return 0;
+  if (0UL < s)
+  return 0;
+  if (0UL <= s) // expected-warning {{comparison of 0 <= unsigned expression is always true}}
+  return 0;
+  if (0UL > s) // expected-warning {{comparison of 0 > unsigned expression is always false}}
+  return 0;
+  if (0UL >= s)
+  return 0;
+
   if (un == 0)
   return 0;
   if (un != 0)
Index: test/Sema/tautological-unsigned-enum-zero-compare.cpp
===
--- test/Sema/tautological-unsigned-enum-zero-compare.cpp
+++ test/Sema/tautological-unsigned-enum-zero-compare.cpp
@@ -1,9 +1,10 @@
 // RUN: %clang_cc1 -std=c++11 -triple=x86_64-pc-linux-gnu -fsyntax-only \
+// RUN:-Wtautological-unsigned-enum-zero-compare \
 // RUN:-verify=unsigned,unsigned-signed %s
 // RUN: %clang_cc1 -std=c++11 -triple=x86_64-pc-win32 -fsyntax-only \
+// RUN:-Wtautological-unsigned-enum-zero-compare \
 // RUN:-verify=unsigned-signed %s
 // RUN: %clang_cc1 -std=c++11 -triple=x86_64-pc-win32 -fsyntax-only \
-// RUN:-Wno-tautological-unsigned-enum-zero-compare \
 // RUN:-verify=silence %s
 
 // silence-no-diagnostics
Index: test/Sema/tautological-unsigned-enum-zero-compare.c
===
--- test/Sema/tautological-unsigned-enum-zero-compare.c
+++ test/Sema/tautological-unsigned-enum-zero-compare.c
@@ -1,9 +1,10 @@
 // RUN: %clang_cc1 -triple=x86_64-pc-linux-gnu -fsyntax-only \
+// RUN:-Wtautological-unsigned-enum-zero-compare \
 // RUN:-verify=unsigned,unsigned-signed %s
 // RUN: %clang_cc1 -triple=x86_64-pc-win32 -fsyntax-only \
+// RUN:-Wtautological-unsigned-enum-zero-compare \
 // RUN:-verify=unsigned-signed %s
 // RUN: %clang_cc1 -triple=x86_64-pc-win32 -fsyntax-only \
-// RUN:-Wno-tautological-unsigned-enum-zero-compare 

[PATCH] D41512: [Sema] -Wtautological-constant-compare is too good. Cripple it.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: include/clang/Basic/DiagnosticGroups.td:440
 def TautologicalUnsignedEnumZeroCompare : 
DiagGroup<"tautological-unsigned-enum-zero-compare">;
+def TautologicalRangeCompare : 
DiagGroup<"tautological-constant-range-compare">;
 def TautologicalOutOfRangeCompare : 
DiagGroup<"tautological-constant-out-of-range-compare">;

lebedev.ri wrote:
> smeenai wrote:
> > aaron.ballman wrote:
> > > lebedev.ri wrote:
> > > > rsmith wrote:
> > > > > "tautological-constant-in-range-compare" would make more sense to me, 
> > > > > as the complement of "tautological-constant-out-of-range-compare".
> > > > I did think about it.
> > > > To me "tautological-constant-in-range-compare" may sound as if the 
> > > > constant is //somewhere// in the range,
> > > > while i'd say "tautological-constant-range-compare" better highlights 
> > > > the fact that the constant *is* the range limit.
> > > > No?
> > > I don't have strong opinions on this name, but have a slight preference 
> > > for "in range" because I'm left wondering how "range compare" relates to 
> > > "out of range compare".
> > How about range-limit-compare or range-edge-compare or range-bound-compare 
> > or something of that nature, that explicitly captures the fact that it's 
> > the range limit?
> Ok, `def TautologicalInRangeCompare : 
> DiagGroup<"tautological-constant-in-range-compare",` it is then.
I think @smeenai may have found a name I like better: 
tautological-range-limit-compare. @rsmith, what do you think?


Repository:
  rC Clang

https://reviews.llvm.org/D41512



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

[PATCH] D41416: [modules] [pch] Do not deserialize all lazy template specializations when looking for one.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 128460.
v.g.vassilev marked 2 inline comments as done.
v.g.vassilev added a comment.

Address inline comments: order the read operations.


https://reviews.llvm.org/D41416

Files:
  include/clang/AST/DeclTemplate.h
  lib/AST/DeclTemplate.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriter.cpp
  lib/Serialization/ASTWriterDecl.cpp

Index: lib/Serialization/ASTWriterDecl.cpp
===
--- lib/Serialization/ASTWriterDecl.cpp
+++ lib/Serialization/ASTWriterDecl.cpp
@@ -162,22 +162,57 @@
   Record.AddSourceLocation(typeParams->getRAngleLoc());
 }
 
-/// Add to the record the first declaration from each module file that
-/// provides a declaration of D. The intent is to provide a sufficient
-/// set such that reloading this set will load all current redeclarations.
-void AddFirstDeclFromEachModule(const Decl *D, bool IncludeLocal) {
-  llvm::MapVector Firsts;
+/// Collect the first declaration from each module file that provides a
+/// declaration of D.
+void CollectFirstDeclFromEachModule(const Decl *D, bool IncludeLocal,
+llvm::MapVector ) {
+
   // FIXME: We can skip entries that we know are implied by others.
   for (const Decl *R = D->getMostRecentDecl(); R; R = R->getPreviousDecl()) {
 if (R->isFromASTFile())
   Firsts[Writer.Chain->getOwningModuleFile(R)] = R;
 else if (IncludeLocal)
   Firsts[nullptr] = R;
   }
+}
+
+/// Add to the record the first declaration from each module file that
+/// provides a declaration of D. The intent is to provide a sufficient
+/// set such that reloading this set will load all current redeclarations.
+void AddFirstDeclFromEachModule(const Decl *D, bool IncludeLocal) {
+  llvm::MapVector Firsts;
+  CollectFirstDeclFromEachModule(D, IncludeLocal, Firsts);
+
   for (const auto  : Firsts)
 Record.AddDeclRef(F.second);
 }
 
+/// Add to the record the first template specialization from each module
+/// file that provides a declaration of D. We store the DeclId and an
+/// ODRHash of the template arguments of D which should provide enough
+/// information to load D only if the template instantiator needs it.
+void AddFirstSpecializationDeclFromEachModule(const Decl *D,
+  bool IncludeLocal) {
+  assert(isa(D) ||
+ isa(D) || isa(D) &&
+ "Must not be called with other decls");
+  llvm::MapVector Firsts;
+  CollectFirstDeclFromEachModule(D, IncludeLocal, Firsts);
+
+  for (const auto  : Firsts) {
+Record.AddDeclRef(F.second);
+ArrayRef Args;
+if (auto *CTSD = dyn_cast(D))
+  Args = CTSD->getTemplateArgs().asArray();
+else if (auto *VTSD = dyn_cast(D))
+  Args = VTSD->getTemplateArgs().asArray();
+else if (auto *FD = dyn_cast(D))
+  Args = FD->getTemplateSpecializationArgs()->asArray();
+assert(Args.size());
+Record.push_back(TemplateArgumentList::ComputeODRHash(Args));
+  }
+}
+
 /// Get the specialization decl from an entry in the specialization list.
 template 
 typename RedeclarableTemplateDecl::SpecEntryTraits::DeclType *
@@ -190,7 +225,8 @@
 decltype(T::PartialSpecializations) (T *Common) {
   return Common->PartialSpecializations;
 }
-ArrayRef getPartialSpecializations(FunctionTemplateDecl::Common *) {
+MutableArrayRef
+getPartialSpecializations(FunctionTemplateDecl::Common *) {
   return None;
 }
 
@@ -207,9 +243,11 @@
 assert(!Common->LazySpecializations);
   }
 
-  ArrayRef LazySpecializations;
+  using LazySpecializationInfo
+= RedeclarableTemplateDecl::LazySpecializationInfo;
+  ArrayRef LazySpecializations;
   if (auto *LS = Common->LazySpecializations)
-LazySpecializations = llvm::makeArrayRef(LS + 1, LS[0]);
+LazySpecializations = llvm::makeArrayRef(LS + 1, LS[0].DeclID);
 
   // Add a slot to the record for the number of specializations.
   unsigned I = Record.size();
@@ -225,12 +263,18 @@
 
   for (auto *D : Specs) {
 assert(D->isCanonicalDecl() && "non-canonical decl in set");
-AddFirstDeclFromEachModule(D, /*IncludeLocal*/true);
+AddFirstSpecializationDeclFromEachModule(D, /*IncludeLocal*/true);
+  }
+  for (auto  : LazySpecializations) {
+Record.push_back(IDHashPair.DeclID);
+Record.push_back(IDHashPair.ODRHash);
   }
-  Record.append(LazySpecializations.begin(), LazySpecializations.end());
 
-  // Update the size entry we added earlier.
-  Record[I] = Record.size() - I - 1;
+  // Update the size entry we added earlier. We 

[PATCH] D41680: [analyzer] do not crash with assertion on processing locations of bodyfarmed functions

[George Karpenkov via Phabricator via cfe-commits]

george.karpenkov created this revision.
george.karpenkov added reviewers: dcoughlin, NoQ.
Herald added subscribers: a.sidorin, szepet, kristof.beyls, xazax.hun, aemerson.

This addresses an issue introduced in r183451: since 
`removePiecesWithInvalidLocations` is called *after* `adjustCallLocations`, it 
is not necessary, and in fact harmful, to have this assertion in 
`adjustCallLocations`.

Addresses rdar://36170689


https://reviews.llvm.org/D41680

Files:
  lib/StaticAnalyzer/Core/BugReporter.cpp
  test/Analysis/call_once.cpp


Index: test/Analysis/call_once.cpp
===
--- test/Analysis/call_once.cpp
+++ test/Analysis/call_once.cpp
@@ -1,10 +1,11 @@
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -verify %s
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -verify %s -o %t.report
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s -o 
%t.report
 
 // We do NOT model libcxx03 implementation, but the analyzer should still
 // not crash.
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -verify %s
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 
-DEMULATE_LIBSTDCPP -verify %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -verify %s -o 
%t.report
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 
-DEMULATE_LIBSTDCPP -verify %s -o %t.report
+// RUN: rm -rf %t.report
 
 void clang_analyzer_eval(bool);
 
Index: lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- lib/StaticAnalyzer/Core/BugReporter.cpp
+++ lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -229,7 +229,6 @@
 PathDiagnosticCallPiece *Call = 
dyn_cast(I->get());
 
 if (!Call) {
-  assert((*I)->getLocation().asLocation().isValid());
   continue;
 }
 


Index: test/Analysis/call_once.cpp
===
--- test/Analysis/call_once.cpp
+++ test/Analysis/call_once.cpp
@@ -1,10 +1,11 @@
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -verify %s
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -verify %s -o %t.report
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s -o %t.report
 
 // We do NOT model libcxx03 implementation, but the analyzer should still
 // not crash.
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -verify %s
-// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -DEMULATE_LIBSTDCPP -verify %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -verify %s -o %t.report
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBCXX03 -DEMULATE_LIBSTDCPP -verify %s -o %t.report
+// RUN: rm -rf %t.report
 
 void clang_analyzer_eval(bool);
 
Index: lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- lib/StaticAnalyzer/Core/BugReporter.cpp
+++ lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -229,7 +229,6 @@
 PathDiagnosticCallPiece *Call = dyn_cast(I->get());
 
 if (!Call) {
-  assert((*I)->getLocation().asLocation().isValid());
   continue;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r321676 - [WinEH] Allow for multiple terminatepads

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Tue Jan  2 13:34:16 2018
New Revision: 321676

URL: http://llvm.org/viewvc/llvm-project?rev=321676=rev
Log:
[WinEH] Allow for multiple terminatepads

Fixes verifier errors with Windows EH and OpenMP, which injects a
terminate scope around parallel blocks.

Fixes PR35778

Modified:
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/test/OpenMP/openmp_win_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGException.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGException.cpp?rev=321676=321675=321676=diff
==
--- cfe/trunk/lib/CodeGen/CGException.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGException.cpp Tue Jan  2 13:34:16 2018
@@ -646,7 +646,7 @@ CodeGenFunction::getMSVCDispatchBlock(EH
 return DispatchBlock;
 
   if (EHS.getKind() == EHScope::Terminate)
-DispatchBlock = getTerminateHandler();
+DispatchBlock = getTerminateFunclet();
   else
 DispatchBlock = createBasicBlock();
   CGBuilderTy Builder(*this, DispatchBlock);
@@ -1334,24 +1334,15 @@ llvm::BasicBlock *CodeGenFunction::getTe
   if (TerminateHandler)
 return TerminateHandler;
 
-  CGBuilderTy::InsertPoint SavedIP = Builder.saveAndClearIP();
-
   // Set up the terminate handler.  This block is inserted at the very
   // end of the function by FinishFunction.
   TerminateHandler = createBasicBlock("terminate.handler");
+  CGBuilderTy::InsertPoint SavedIP = Builder.saveAndClearIP();
   Builder.SetInsertPoint(TerminateHandler);
+
   llvm::Value *Exn = nullptr;
-  SaveAndRestore RestoreCurrentFuncletPad(
-  CurrentFuncletPad);
-  if (EHPersonality::get(*this).usesFuncletPads()) {
-llvm::Value *ParentPad = CurrentFuncletPad;
-if (!ParentPad)
-  ParentPad = llvm::ConstantTokenNone::get(CGM.getLLVMContext());
-CurrentFuncletPad = Builder.CreateCleanupPad(ParentPad);
-  } else {
-if (getLangOpts().CPlusPlus)
-  Exn = getExceptionFromSlot();
-  }
+  if (getLangOpts().CPlusPlus)
+Exn = getExceptionFromSlot();
   llvm::CallInst *terminateCall =
   CGM.getCXXABI().emitTerminateForUnexpectedException(*this, Exn);
   terminateCall->setDoesNotReturn();
@@ -1363,6 +1354,42 @@ llvm::BasicBlock *CodeGenFunction::getTe
   return TerminateHandler;
 }
 
+llvm::BasicBlock *CodeGenFunction::getTerminateFunclet() {
+  assert(EHPersonality::get(*this).usesFuncletPads() &&
+ "use getTerminateLandingPad for non-funclet EH");
+
+  llvm::BasicBlock * = TerminateFunclets[CurrentFuncletPad];
+  if (TerminateFunclet)
+return TerminateFunclet;
+
+  CGBuilderTy::InsertPoint SavedIP = Builder.saveAndClearIP();
+
+  // Set up the terminate handler.  This block is inserted at the very
+  // end of the function by FinishFunction.
+  TerminateFunclet = createBasicBlock("terminate.handler");
+  Builder.SetInsertPoint(TerminateFunclet);
+
+  // Create the cleanuppad using the current parent pad as its token. Use 
'none'
+  // if this is a top-level terminate scope, which is the common case.
+  SaveAndRestore RestoreCurrentFuncletPad(
+  CurrentFuncletPad);
+  llvm::Value *ParentPad = CurrentFuncletPad;
+  if (!ParentPad)
+ParentPad = llvm::ConstantTokenNone::get(CGM.getLLVMContext());
+  CurrentFuncletPad = Builder.CreateCleanupPad(ParentPad);
+
+  // Emit the __std_terminate call.
+  llvm::CallInst *terminateCall =
+  CGM.getCXXABI().emitTerminateForUnexpectedException(*this, nullptr);
+  terminateCall->setDoesNotReturn();
+  Builder.CreateUnreachable();
+
+  // Restore the saved insertion state.
+  Builder.restoreIP(SavedIP);
+
+  return TerminateFunclet;
+}
+
 llvm::BasicBlock *CodeGenFunction::getEHResumeBlock(bool isCleanup) {
   if (EHResumeBlock) return EHResumeBlock;
 

Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.cpp?rev=321676=321675=321676=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenFunction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenFunction.cpp Tue Jan  2 13:34:16 2018
@@ -419,6 +419,9 @@ void CodeGenFunction::FinishFunction(Sou
   EmitIfUsed(*this, TerminateHandler);
   EmitIfUsed(*this, UnreachableBlock);
 
+  for (const auto  : TerminateFunclets)
+EmitIfUsed(*this, FuncletAndParent.second);
+
   if (CGM.getCodeGenOpts().EmitDeclMetadata)
 EmitDeclMetadata();
 

Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.h?rev=321676=321675=321676=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenFunction.h (original)
+++ cfe/trunk/lib/CodeGen/CodeGenFunction.h Tue Jan  2 13:34:16 2018
@@ -34,6 +34,7 @@
 #include "clang/Frontend/CodeGenOptions.h"
 #include "llvm/ADT/ArrayRef.h"
 #include 

[PATCH] D41677: Change memcpy/memove/memset to have dest and source alignment attributes.

[Daniel Neilson via Phabricator via cfe-commits]

dneilson added a comment.

In https://reviews.llvm.org/D41677#966094, @rjmccall wrote:

> I'm glad to hear that progress is finally happening on this.
>
> The change to CGBuilder looks good to me.  I'm going to take your word for it 
> that the test changes are all just obvious updates; if there's one in 
> particular that you'd like me to look at, I'd be happy to.


Thanks! Yeah, the CGBuilder change is the meat of it. The test changes are all 
either sed-script changes, or manual fixes. For the manual fixes I made an 
effort to make sure that if the test wasn't checking for a specific alignment 
value before this change then it won't be checking for a specific alignment 
value after it either (i.e. matches like align {{[0-9]+}} when the alignment 
value doesn't matter).


Repository:
  rC Clang

https://reviews.llvm.org/D41677



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

[PATCH] D41677: Change memcpy/memove/memset to have dest and source alignment attributes.

[John McCall via Phabricator via cfe-commits]

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

I'm glad to hear that progress is finally happening on this.

The change to CGBuilder looks good to me.  I'm going to take your word for it 
that the test changes are all just obvious updates; if there's one in 
particular that you'd like me to look at, I'd be happy to.


Repository:
  rC Clang

https://reviews.llvm.org/D41677



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

[PATCH] D41520: smmintrin.h documentation fixes and updates

[Douglas Yung via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL321671: [DOXYGEN] Fix doxygen and content issues in 
smmintrin.h (authored by dyung, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D41520?vs=127949=128449#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D41520

Files:
  cfe/trunk/lib/Headers/smmintrin.h


Index: cfe/trunk/lib/Headers/smmintrin.h
===
--- cfe/trunk/lib/Headers/smmintrin.h
+++ cfe/trunk/lib/Headers/smmintrin.h
@@ -648,7 +648,7 @@
 ///input vectors are used as an input for dot product; otherwise that input
 ///is treated as zero. Bits [1:0] determine which elements of the result
 ///will receive a copy of the final dot product, with bit [0] corresponding
-///to the lowest element and bit [3] corresponding to the highest element 
of
+///to the lowest element and bit [1] corresponding to the highest element 
of
 ///each [2 x double] vector. If a bit is set, the dot product is returned 
in
 ///the corresponding element; otherwise that element is set to zero.
 #define _mm_dp_pd(X, Y, M) __extension__ ({\
@@ -866,8 +866,8 @@
 ///  11: Copies the selected bits from \a Y to result bits [127:96]. \n
 ///Bits[3:0]: If any of these bits are set, the corresponding result
 ///element is cleared.
-/// \returns A 128-bit vector of [4 x float] containing the copied single-
-///precision floating point elements from the operands.
+/// \returns A 128-bit vector of [4 x float] containing the copied
+///single-precision floating point elements from the operands.
 #define _mm_insert_ps(X, Y, N) __builtin_ia32_insertps128((X), (Y), (N))
 
 /// \brief Extracts a 32-bit integer from a 128-bit vector of [4 x float] and


Index: cfe/trunk/lib/Headers/smmintrin.h
===
--- cfe/trunk/lib/Headers/smmintrin.h
+++ cfe/trunk/lib/Headers/smmintrin.h
@@ -648,7 +648,7 @@
 ///input vectors are used as an input for dot product; otherwise that input
 ///is treated as zero. Bits [1:0] determine which elements of the result
 ///will receive a copy of the final dot product, with bit [0] corresponding
-///to the lowest element and bit [3] corresponding to the highest element of
+///to the lowest element and bit [1] corresponding to the highest element of
 ///each [2 x double] vector. If a bit is set, the dot product is returned in
 ///the corresponding element; otherwise that element is set to zero.
 #define _mm_dp_pd(X, Y, M) __extension__ ({\
@@ -866,8 +866,8 @@
 ///  11: Copies the selected bits from \a Y to result bits [127:96]. \n
 ///Bits[3:0]: If any of these bits are set, the corresponding result
 ///element is cleared.
-/// \returns A 128-bit vector of [4 x float] containing the copied single-
-///precision floating point elements from the operands.
+/// \returns A 128-bit vector of [4 x float] containing the copied
+///single-precision floating point elements from the operands.
 #define _mm_insert_ps(X, Y, N) __builtin_ia32_insertps128((X), (Y), (N))
 
 /// \brief Extracts a 32-bit integer from a 128-bit vector of [4 x float] and
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r321671 - [DOXYGEN] Fix doxygen and content issues in smmintrin.h

[Douglas Yung via cfe-commits]

Author: dyung
Date: Tue Jan  2 12:45:29 2018
New Revision: 321671

URL: http://llvm.org/viewvc/llvm-project?rev=321671=rev
Log:
[DOXYGEN] Fix doxygen and content issues in smmintrin.h

- Fix formatting issue due to hyphenated terms at line breaks.
- Fix typo

This patch was made by Craig Flores

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

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

Modified: cfe/trunk/lib/Headers/smmintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/smmintrin.h?rev=321671=321670=321671=diff
==
--- cfe/trunk/lib/Headers/smmintrin.h (original)
+++ cfe/trunk/lib/Headers/smmintrin.h Tue Jan  2 12:45:29 2018
@@ -648,7 +648,7 @@ _mm_mul_epi32 (__m128i __V1, __m128i __V
 ///input vectors are used as an input for dot product; otherwise that input
 ///is treated as zero. Bits [1:0] determine which elements of the result
 ///will receive a copy of the final dot product, with bit [0] corresponding
-///to the lowest element and bit [3] corresponding to the highest element 
of
+///to the lowest element and bit [1] corresponding to the highest element 
of
 ///each [2 x double] vector. If a bit is set, the dot product is returned 
in
 ///the corresponding element; otherwise that element is set to zero.
 #define _mm_dp_pd(X, Y, M) __extension__ ({\
@@ -866,8 +866,8 @@ _mm_max_epu32 (__m128i __V1, __m128i __V
 ///  11: Copies the selected bits from \a Y to result bits [127:96]. \n
 ///Bits[3:0]: If any of these bits are set, the corresponding result
 ///element is cleared.
-/// \returns A 128-bit vector of [4 x float] containing the copied single-
-///precision floating point elements from the operands.
+/// \returns A 128-bit vector of [4 x float] containing the copied
+///single-precision floating point elements from the operands.
 #define _mm_insert_ps(X, Y, N) __builtin_ia32_insertps128((X), (Y), (N))
 
 /// \brief Extracts a 32-bit integer from a 128-bit vector of [4 x float] and


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

[PATCH] D38320: [clang] Fix serializers for `TypeTemplateParmDecl` + related types

[Steve O'Brien via Phabricator via cfe-commits]

elsteveogrande added a comment.

Hi @arphaman, thanks very much!  Sorry, I didn't notice there was activity on 
this old patch until now.

I'll make these changes as suggested and re-send it with full context.


Repository:
  rL LLVM

https://reviews.llvm.org/D38320



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

[PATCH] D41518: pmmintrin.h documentation fixes and updates

[Douglas Yung via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL321670: [DOXYGEN] Fix doxygen and content issues in 
pmmintrin.h (authored by dyung, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D41518?vs=127947=128448#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D41518

Files:
  cfe/trunk/lib/Headers/pmmintrin.h


Index: cfe/trunk/lib/Headers/pmmintrin.h
===
--- cfe/trunk/lib/Headers/pmmintrin.h
+++ cfe/trunk/lib/Headers/pmmintrin.h
@@ -115,8 +115,8 @@
   return __builtin_ia32_hsubps((__v4sf)__a, (__v4sf)__b);
 }
 
-/// \brief Moves and duplicates high-order (odd-indexed) values from a 128-bit
-///vector of [4 x float] to float values stored in a 128-bit vector of
+/// \brief Moves and duplicates odd-indexed values from a 128-bit vector
+///of [4 x float] to float values stored in a 128-bit vector of
 ///[4 x float].
 ///
 /// \headerfile 
@@ -137,7 +137,7 @@
   return __builtin_shufflevector((__v4sf)__a, (__v4sf)__a, 1, 1, 3, 3);
 }
 
-/// \brief Duplicates low-order (even-indexed) values from a 128-bit vector of
+/// \brief Duplicates even-indexed values from a 128-bit vector of
 ///[4 x float] to float values stored in a 128-bit vector of [4 x float].
 ///
 /// \headerfile 


Index: cfe/trunk/lib/Headers/pmmintrin.h
===
--- cfe/trunk/lib/Headers/pmmintrin.h
+++ cfe/trunk/lib/Headers/pmmintrin.h
@@ -115,8 +115,8 @@
   return __builtin_ia32_hsubps((__v4sf)__a, (__v4sf)__b);
 }
 
-/// \brief Moves and duplicates high-order (odd-indexed) values from a 128-bit
-///vector of [4 x float] to float values stored in a 128-bit vector of
+/// \brief Moves and duplicates odd-indexed values from a 128-bit vector
+///of [4 x float] to float values stored in a 128-bit vector of
 ///[4 x float].
 ///
 /// \headerfile 
@@ -137,7 +137,7 @@
   return __builtin_shufflevector((__v4sf)__a, (__v4sf)__a, 1, 1, 3, 3);
 }
 
-/// \brief Duplicates low-order (even-indexed) values from a 128-bit vector of
+/// \brief Duplicates even-indexed values from a 128-bit vector of
 ///[4 x float] to float values stored in a 128-bit vector of [4 x float].
 ///
 /// \headerfile 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r321670 - [DOXYGEN] Fix doxygen and content issues in pmmintrin.h

[Douglas Yung via cfe-commits]

Author: dyung
Date: Tue Jan  2 12:42:53 2018
New Revision: 321670

URL: http://llvm.org/viewvc/llvm-project?rev=321670=rev
Log:
[DOXYGEN] Fix doxygen and content issues in pmmintrin.h

- Fix incorrect wording in various intrinsic descriptions. Previously the 
descriptions used "low-order" and "high-order" when the intended meaning was 
"even-indexed" and "odd-indexed".

This patch was made by Craig Flores

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

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

Modified: cfe/trunk/lib/Headers/pmmintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/pmmintrin.h?rev=321670=321669=321670=diff
==
--- cfe/trunk/lib/Headers/pmmintrin.h (original)
+++ cfe/trunk/lib/Headers/pmmintrin.h Tue Jan  2 12:42:53 2018
@@ -115,8 +115,8 @@ _mm_hsub_ps(__m128 __a, __m128 __b)
   return __builtin_ia32_hsubps((__v4sf)__a, (__v4sf)__b);
 }
 
-/// \brief Moves and duplicates high-order (odd-indexed) values from a 128-bit
-///vector of [4 x float] to float values stored in a 128-bit vector of
+/// \brief Moves and duplicates odd-indexed values from a 128-bit vector
+///of [4 x float] to float values stored in a 128-bit vector of
 ///[4 x float].
 ///
 /// \headerfile 
@@ -137,7 +137,7 @@ _mm_movehdup_ps(__m128 __a)
   return __builtin_shufflevector((__v4sf)__a, (__v4sf)__a, 1, 1, 3, 3);
 }
 
-/// \brief Duplicates low-order (even-indexed) values from a 128-bit vector of
+/// \brief Duplicates even-indexed values from a 128-bit vector of
 ///[4 x float] to float values stored in a 128-bit vector of [4 x float].
 ///
 /// \headerfile 


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

[PATCH] D41516: emmintrin.h documentation fixes and updates

[Douglas Yung via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL321669: [DOXYGEN] Fix doxygen and content issues in 
emmintrin.h (authored by dyung, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D41516?vs=127939=128447#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D41516

Files:
  cfe/trunk/lib/Headers/emmintrin.h

Index: cfe/trunk/lib/Headers/emmintrin.h
===
--- cfe/trunk/lib/Headers/emmintrin.h
+++ cfe/trunk/lib/Headers/emmintrin.h
@@ -217,8 +217,8 @@
 
 /// \brief Calculates the square root of the lower double-precision value of
 ///the second operand and returns it in the lower 64 bits of the result.
-///The upper 64 bits of the result are copied from the upper double-
-///precision value of the first operand.
+///The upper 64 bits of the result are copied from the upper
+///double-precision value of the first operand.
 ///
 /// \headerfile 
 ///
@@ -260,8 +260,8 @@
 
 /// \brief Compares lower 64-bit double-precision values of both operands, and
 ///returns the lesser of the pair of values in the lower 64-bits of the
-///result. The upper 64 bits of the result are copied from the upper double-
-///precision value of the first operand.
+///result. The upper 64 bits of the result are copied from the upper
+///double-precision value of the first operand.
 ///
 /// \headerfile 
 ///
@@ -304,8 +304,8 @@
 
 /// \brief Compares lower 64-bit double-precision values of both operands, and
 ///returns the greater of the pair of values in the lower 64-bits of the
-///result. The upper 64 bits of the result are copied from the upper double-
-///precision value of the first operand.
+///result. The upper 64 bits of the result are copied from the upper
+///double-precision value of the first operand.
 ///
 /// \headerfile 
 ///
@@ -983,8 +983,10 @@
 }
 
 /// \brief Compares the lower double-precision floating-point values in each of
-///the two 128-bit floating-point vectors of [2 x double] for equality. The
-///comparison yields 0 for false, 1 for true.
+///the two 128-bit floating-point vectors of [2 x double] for equality.
+///
+///The comparison yields 0 for false, 1 for true. If either of the two
+///lower double-precision values is NaN, 0 is returned.
 ///
 /// \headerfile 
 ///
@@ -996,7 +998,8 @@
 /// \param __b
 ///A 128-bit vector of [2 x double]. The lower double-precision value is
 ///compared to the lower double-precision value of \a __a.
-/// \returns An integer containing the comparison results.
+/// \returns An integer containing the comparison results. If either of the two
+///lower double-precision values is NaN, 0 is returned.
 static __inline__ int __DEFAULT_FN_ATTRS
 _mm_comieq_sd(__m128d __a, __m128d __b)
 {
@@ -1008,7 +1011,8 @@
 ///the value in the first parameter is less than the corresponding value in
 ///the second parameter.
 ///
-///The comparison yields 0 for false, 1 for true.
+///The comparison yields 0 for false, 1 for true. If either of the two
+///lower double-precision values is NaN, 0 is returned.
 ///
 /// \headerfile 
 ///
@@ -1020,7 +1024,8 @@
 /// \param __b
 ///A 128-bit vector of [2 x double]. The lower double-precision value is
 ///compared to the lower double-precision value of \a __a.
-/// \returns An integer containing the comparison results.
+/// \returns An integer containing the comparison results. If either of the two
+/// lower double-precision values is NaN, 0 is returned.
 static __inline__ int __DEFAULT_FN_ATTRS
 _mm_comilt_sd(__m128d __a, __m128d __b)
 {
@@ -1032,7 +1037,8 @@
 ///the value in the first parameter is less than or equal to the
 ///corresponding value in the second parameter.
 ///
-///The comparison yields 0 for false, 1 for true.
+///The comparison yields 0 for false, 1 for true. If either of the two
+///lower double-precision values is NaN, 0 is returned.
 ///
 /// \headerfile 
 ///
@@ -1044,7 +1050,8 @@
 /// \param __b
 /// A 128-bit vector of [2 x double]. The lower double-precision value is
 /// compared to the lower double-precision value of \a __a.
-/// \returns An integer containing the comparison results.
+/// \returns An integer containing the comparison results. If either of the two
+/// lower double-precision values is NaN, 0 is returned.
 static __inline__ int __DEFAULT_FN_ATTRS
 _mm_comile_sd(__m128d __a, __m128d __b)
 {
@@ -1056,7 +1063,8 @@
 ///the value in the first parameter is greater than the corresponding value
 ///in the second parameter.
 ///
-///The comparison yields 0 for false, 1 for true.
+///The comparison yields 0 for false, 1 for true. If either of the two
+///lower double-precision values is NaN, 0 is returned.
 ///
 /// \headerfile 
 ///
@@ -1068,7 +1076,8 @@
 /// \param __b
 ///A 128-bit vector of [2 x double]. The 

r321669 - [DOXYGEN] Fix doxygen and content issues in emmintrin.h

[Douglas Yung via cfe-commits]

Author: dyung
Date: Tue Jan  2 12:39:29 2018
New Revision: 321669

URL: http://llvm.org/viewvc/llvm-project?rev=321669=rev
Log:
[DOXYGEN] Fix doxygen and content issues in emmintrin.h

- Fixed innaccurate instruction mappings for various intrinsics.
- Fixed description of NaN handling in comparison intrinsics.
- Unify description of _mm_store_pd1 to match _mm_store1_pd.
- Fix incorrect wording in various intrinsic descriptions. Previously the 
descriptions used "low-order" and "high-order" when the intended meaning was 
"even-indexed" and "odd-indexed".
- Fix typos.
- Add missing italics command (\a) for params and fixed some parameter 
spellings.

This patch was made by Craig Flores

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

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

Modified: cfe/trunk/lib/Headers/emmintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/emmintrin.h?rev=321669=321668=321669=diff
==
--- cfe/trunk/lib/Headers/emmintrin.h (original)
+++ cfe/trunk/lib/Headers/emmintrin.h Tue Jan  2 12:39:29 2018
@@ -217,8 +217,8 @@ _mm_div_pd(__m128d __a, __m128d __b)
 
 /// \brief Calculates the square root of the lower double-precision value of
 ///the second operand and returns it in the lower 64 bits of the result.
-///The upper 64 bits of the result are copied from the upper double-
-///precision value of the first operand.
+///The upper 64 bits of the result are copied from the upper
+///double-precision value of the first operand.
 ///
 /// \headerfile 
 ///
@@ -260,8 +260,8 @@ _mm_sqrt_pd(__m128d __a)
 
 /// \brief Compares lower 64-bit double-precision values of both operands, and
 ///returns the lesser of the pair of values in the lower 64-bits of the
-///result. The upper 64 bits of the result are copied from the upper 
double-
-///precision value of the first operand.
+///result. The upper 64 bits of the result are copied from the upper
+///double-precision value of the first operand.
 ///
 /// \headerfile 
 ///
@@ -304,8 +304,8 @@ _mm_min_pd(__m128d __a, __m128d __b)
 
 /// \brief Compares lower 64-bit double-precision values of both operands, and
 ///returns the greater of the pair of values in the lower 64-bits of the
-///result. The upper 64 bits of the result are copied from the upper 
double-
-///precision value of the first operand.
+///result. The upper 64 bits of the result are copied from the upper
+///double-precision value of the first operand.
 ///
 /// \headerfile 
 ///
@@ -983,8 +983,10 @@ _mm_cmpnge_sd(__m128d __a, __m128d __b)
 }
 
 /// \brief Compares the lower double-precision floating-point values in each of
-///the two 128-bit floating-point vectors of [2 x double] for equality. The
-///comparison yields 0 for false, 1 for true.
+///the two 128-bit floating-point vectors of [2 x double] for equality.
+///
+///The comparison yields 0 for false, 1 for true. If either of the two
+///lower double-precision values is NaN, 0 is returned.
 ///
 /// \headerfile 
 ///
@@ -996,7 +998,8 @@ _mm_cmpnge_sd(__m128d __a, __m128d __b)
 /// \param __b
 ///A 128-bit vector of [2 x double]. The lower double-precision value is
 ///compared to the lower double-precision value of \a __a.
-/// \returns An integer containing the comparison results.
+/// \returns An integer containing the comparison results. If either of the two
+///lower double-precision values is NaN, 0 is returned.
 static __inline__ int __DEFAULT_FN_ATTRS
 _mm_comieq_sd(__m128d __a, __m128d __b)
 {
@@ -1008,7 +1011,8 @@ _mm_comieq_sd(__m128d __a, __m128d __b)
 ///the value in the first parameter is less than the corresponding value in
 ///the second parameter.
 ///
-///The comparison yields 0 for false, 1 for true.
+///The comparison yields 0 for false, 1 for true. If either of the two
+///lower double-precision values is NaN, 0 is returned.
 ///
 /// \headerfile 
 ///
@@ -1020,7 +1024,8 @@ _mm_comieq_sd(__m128d __a, __m128d __b)
 /// \param __b
 ///A 128-bit vector of [2 x double]. The lower double-precision value is
 ///compared to the lower double-precision value of \a __a.
-/// \returns An integer containing the comparison results.
+/// \returns An integer containing the comparison results. If either of the two
+/// lower double-precision values is NaN, 0 is returned.
 static __inline__ int __DEFAULT_FN_ATTRS
 _mm_comilt_sd(__m128d __a, __m128d __b)
 {
@@ -1032,7 +1037,8 @@ _mm_comilt_sd(__m128d __a, __m128d __b)
 ///the value in the first parameter is less than or equal to the
 ///corresponding value in the second parameter.
 ///
-///The comparison yields 0 for false, 1 for true.
+///The comparison yields 0 for false, 1 for true. If either of the two
+///lower double-precision values is NaN, 0 is returned.
 ///
 /// \headerfile 
 ///
@@ -1044,7 +1050,8 @@ 

[PATCH] D41660: [cmake] Add new linux toolchain file

[Don Hinton via Phabricator via cfe-commits]

hintonda added a comment.

In https://reviews.llvm.org/D41660#966023, @phosek wrote:

> @hintonda I think this should be a platform file in 
> https://github.com/llvm-mirror/llvm/tree/master/cmake/platforms rather than 
> Clang cache file. Platform files are concerned with the host platform 
> (including cross-compilation), while cache files are  related to the 
> distribution setup. What you're trying to do is the former rather than the 
> latter. Some of the aspects of your setup like the bootstrap tool setup is 
> already handled by the 2-stage build so you should use that rather than 
> reimplementing your own solution.


Thanks for the pointer.  I'll rework the patch along the lines you suggest.


Repository:
  rC Clang

https://reviews.llvm.org/D41660



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

[PATCH] D41213: [libcxx] [test] Improve MSVC portability.

[Stephan T. Lavavej via Phabricator via cfe-commits]

STL_MSFT added a comment.

Ping? (And happy new year!)


https://reviews.llvm.org/D41213



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

[PATCH] D41386: [libunwind][PPC64] Port to ppc64le - initial version

[Martin Storsjö via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL321667: [PPC64] Port to ppc64le - initial version (authored 
by mstorsjo, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D41386?vs=127516=128445#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D41386

Files:
  libunwind/trunk/include/__libunwind_config.h
  libunwind/trunk/include/libunwind.h
  libunwind/trunk/src/AddressSpace.hpp
  libunwind/trunk/src/Registers.hpp
  libunwind/trunk/src/UnwindCursor.hpp
  libunwind/trunk/src/UnwindRegistersRestore.S
  libunwind/trunk/src/UnwindRegistersSave.S
  libunwind/trunk/src/assembly.h
  libunwind/trunk/src/config.h
  libunwind/trunk/src/libunwind.cpp

Index: libunwind/trunk/src/UnwindRegistersSave.S
===
--- libunwind/trunk/src/UnwindRegistersSave.S
+++ libunwind/trunk/src/UnwindRegistersSave.S
@@ -237,6 +237,109 @@
 DEFINE_LIBUNWIND_FUNCTION(unw_getcontext)
   teq $0, $0
 
+#elif defined(__powerpc64__)
+
+//
+// extern int unw_getcontext(unw_context_t* thread_state)
+//
+// On entry:
+//  thread_state pointer is in r3
+//
+DEFINE_LIBUNWIND_FUNCTION(unw_getcontext)
+  std   %r0,   16(%r3)
+  mflr  %r0
+  std   %r0,0(%r3)  // store lr as ssr0
+  std   %r1,   24(%r3)
+  std   %r2,   32(%r3)
+  std   %r3,   40(%r3)
+  std   %r4,   48(%r3)
+  std   %r5,   56(%r3)
+  std   %r6,   64(%r3)
+  std   %r7,   72(%r3)
+  std   %r8,   80(%r3)
+  std   %r9,   88(%r3)
+  std   %r10,  96(%r3)
+  std   %r11, 104(%r3)
+  std   %r12, 112(%r3)
+  std   %r13, 120(%r3)
+  std   %r14, 128(%r3)
+  std   %r15, 136(%r3)
+  std   %r16, 144(%r3)
+  std   %r17, 152(%r3)
+  std   %r18, 160(%r3)
+  std   %r19, 168(%r3)
+  std   %r20, 176(%r3)
+  std   %r21, 184(%r3)
+  std   %r22, 192(%r3)
+  std   %r23, 200(%r3)
+  std   %r24, 208(%r3)
+  std   %r25, 216(%r3)
+  std   %r26, 224(%r3)
+  std   %r27, 232(%r3)
+  std   %r28, 240(%r3)
+  std   %r29, 248(%r3)
+  std   %r30, 256(%r3)
+  std   %r31, 264(%r3)
+
+  mfcr  %r0
+  std   %r0,  272(%r3)
+
+  mfxer %r0
+  std   %r0,  280(%r3)
+
+  mflr  %r0
+  std   %r0,  288(%r3)
+
+  mfctr %r0
+  std   %r0,  296(%r3)
+
+  mfvrsave%r0
+  std   %r0,  304(%r3)
+
+  // save float registers
+  stfd  %f0,  312(%r3)
+  stfd  %f1,  320(%r3)
+  stfd  %f2,  328(%r3)
+  stfd  %f3,  336(%r3)
+  stfd  %f4,  344(%r3)
+  stfd  %f5,  352(%r3)
+  stfd  %f6,  360(%r3)
+  stfd  %f7,  368(%r3)
+  stfd  %f8,  376(%r3)
+  stfd  %f9,  384(%r3)
+  stfd  %f10, 392(%r3)
+  stfd  %f11, 400(%r3)
+  stfd  %f12, 408(%r3)
+  stfd  %f13, 416(%r3)
+  stfd  %f14, 424(%r3)
+  stfd  %f15, 432(%r3)
+  stfd  %f16, 440(%r3)
+  stfd  %f17, 448(%r3)
+  stfd  %f18, 456(%r3)
+  stfd  %f19, 464(%r3)
+  stfd  %f20, 472(%r3)
+  stfd  %f21, 480(%r3)
+  stfd  %f22, 488(%r3)
+  stfd  %f23, 496(%r3)
+  stfd  %f24, 504(%r3)
+  stfd  %f25, 512(%r3)
+  stfd  %f26, 520(%r3)
+  stfd  %f27, 528(%r3)
+  stfd  %f28, 536(%r3)
+  stfd  %f29, 544(%r3)
+  stfd  %f30, 552(%r3)
+  stfd  %f31, 560(%r3)
+
+  mffs  %f0
+  stfd  %f0,  568(%r3)
+
+  //TODO: save vector registers
+
+
+  li%r3,  0   // return UNW_ESUCCESS
+  blr
+
+
 #elif defined(__ppc__)
 
 ;
Index: libunwind/trunk/src/libunwind.cpp
===
--- libunwind/trunk/src/libunwind.cpp
+++ libunwind/trunk/src/libunwind.cpp
@@ -51,6 +51,8 @@
 # define REGISTER_KIND Registers_x86
 #elif defined(__x86_64__)
 # define REGISTER_KIND Registers_x86_64
+#elif defined(__powerpc64__)
+# define REGISTER_KIND Registers_ppc64
 #elif defined(__ppc__)
 # define REGISTER_KIND Registers_ppc
 #elif defined(__aarch64__)
Index: libunwind/trunk/src/assembly.h
===
--- libunwind/trunk/src/assembly.h
+++ libunwind/trunk/src/assembly.h
@@ -16,7 +16,9 @@
 #ifndef UNWIND_ASSEMBLY_H
 #define UNWIND_ASSEMBLY_H
 
-#if defined(__POWERPC__) || defined(__powerpc__) || defined(__ppc__)
+#if defined(__powerpc64__)
+#define SEPARATOR ;
+#elif defined(__POWERPC__) || defined(__powerpc__) || defined(__ppc__)
 #define SEPARATOR @
 #elif defined(__arm64__)
 #define SEPARATOR %%
Index: libunwind/trunk/src/UnwindRegistersRestore.S
===
--- libunwind/trunk/src/UnwindRegistersRestore.S
+++ libunwind/trunk/src/UnwindRegistersRestore.S
@@ -128,6 +128,101 @@
   ret# rip was saved here
 
 
+#elif defined(__powerpc64__)
+
+DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind15Registers_ppc646jumptoEv)
+//
+// void libunwind::Registers_ppc64::jumpto()
+//
+// On entry:
+//  thread_state pointer is in r3
+//
+
+  // restore integral registers
+  // skip r0 for now
+  // skip r1 for now
+  ld%r2,   32(%r3)
+  // skip r3 for now
+  // skip r4 for now
+  // skip r5 for now
+  ld%r6,   64(%r3)
+  ld%r7,   72(%r3)
+  ld%r8,   80(%r3)
+  ld%r9,   88(%r3)
+  ld%r10,  96(%r3)
+  ld%r11, 104(%r3)
+  ld%r12, 

[libunwind] r321667 - [PPC64] Port to ppc64le - initial version

[Martin Storsjo via cfe-commits]

Author: mstorsjo
Date: Tue Jan  2 12:10:54 2018
New Revision: 321667

URL: http://llvm.org/viewvc/llvm-project?rev=321667=rev
Log:
[PPC64] Port to ppc64le - initial version

Initial working version of libunwind for PowerPC 64. Tested on
little-endian ppc64 host only.
Based on the existing PowerPC 32 code.

It supports:

- context save/restore (unw_getcontext, unw_init_local, unw_resume)
- read/write from/to saved registers
- backtrace (unw_step)

Patch by Leandro Lupori!

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

Modified:
libunwind/trunk/include/__libunwind_config.h
libunwind/trunk/include/libunwind.h
libunwind/trunk/src/AddressSpace.hpp
libunwind/trunk/src/Registers.hpp
libunwind/trunk/src/UnwindCursor.hpp
libunwind/trunk/src/UnwindRegistersRestore.S
libunwind/trunk/src/UnwindRegistersSave.S
libunwind/trunk/src/assembly.h
libunwind/trunk/src/config.h
libunwind/trunk/src/libunwind.cpp

Modified: libunwind/trunk/include/__libunwind_config.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/__libunwind_config.h?rev=321667=321666=321667=diff
==
--- libunwind/trunk/include/__libunwind_config.h (original)
+++ libunwind/trunk/include/__libunwind_config.h Tue Jan  2 12:10:54 2018
@@ -18,6 +18,7 @@
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_X86   8
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_X86_6432
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_PPC   112
+#define _LIBUNWIND_HIGHEST_DWARF_REGISTER_PPC64 110
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_ARM64 95
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_ARM   287
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_OR1K  31
@@ -39,6 +40,11 @@
 #define _LIBUNWIND_CURSOR_SIZE 33
 #  endif
 #  define _LIBUNWIND_HIGHEST_DWARF_REGISTER 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_X86_64
+# elif defined(__powerpc64__)
+#  define _LIBUNWIND_TARGET_PPC64 1
+#  define _LIBUNWIND_CONTEXT_SIZE 136
+#  define _LIBUNWIND_CURSOR_SIZE 148
+#  define _LIBUNWIND_HIGHEST_DWARF_REGISTER 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_PPC64
 # elif defined(__ppc__)
 #  define _LIBUNWIND_TARGET_PPC 1
 #  define _LIBUNWIND_CONTEXT_SIZE 117
@@ -84,13 +90,14 @@
 # define _LIBUNWIND_TARGET_I386
 # define _LIBUNWIND_TARGET_X86_64 1
 # define _LIBUNWIND_TARGET_PPC 1
+# define _LIBUNWIND_TARGET_PPC64 1
 # define _LIBUNWIND_TARGET_AARCH64 1
 # define _LIBUNWIND_TARGET_ARM 1
 # define _LIBUNWIND_TARGET_OR1K 1
 # define _LIBUNWIND_TARGET_MIPS_O32 1
 # define _LIBUNWIND_TARGET_MIPS_N64 1
-# define _LIBUNWIND_CONTEXT_SIZE 128
-# define _LIBUNWIND_CURSOR_SIZE 140
+# define _LIBUNWIND_CONTEXT_SIZE 136
+# define _LIBUNWIND_CURSOR_SIZE 148
 # define _LIBUNWIND_HIGHEST_DWARF_REGISTER 287
 #endif // _LIBUNWIND_IS_NATIVE_ONLY
 

Modified: libunwind/trunk/include/libunwind.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/libunwind.h?rev=321667=321666=321667=diff
==
--- libunwind/trunk/include/libunwind.h (original)
+++ libunwind/trunk/include/libunwind.h Tue Jan  2 12:10:54 2018
@@ -325,6 +325,120 @@ enum {
   UNW_PPC_SPEFSCR = 112
 };
 
+// 64-bit ppc register numbers
+enum {
+  UNW_PPC64_R0  = 0,
+  UNW_PPC64_R1  = 1,
+  UNW_PPC64_R2  = 2,
+  UNW_PPC64_R3  = 3,
+  UNW_PPC64_R4  = 4,
+  UNW_PPC64_R5  = 5,
+  UNW_PPC64_R6  = 6,
+  UNW_PPC64_R7  = 7,
+  UNW_PPC64_R8  = 8,
+  UNW_PPC64_R9  = 9,
+  UNW_PPC64_R10 = 10,
+  UNW_PPC64_R11 = 11,
+  UNW_PPC64_R12 = 12,
+  UNW_PPC64_R13 = 13,
+  UNW_PPC64_R14 = 14,
+  UNW_PPC64_R15 = 15,
+  UNW_PPC64_R16 = 16,
+  UNW_PPC64_R17 = 17,
+  UNW_PPC64_R18 = 18,
+  UNW_PPC64_R19 = 19,
+  UNW_PPC64_R20 = 20,
+  UNW_PPC64_R21 = 21,
+  UNW_PPC64_R22 = 22,
+  UNW_PPC64_R23 = 23,
+  UNW_PPC64_R24 = 24,
+  UNW_PPC64_R25 = 25,
+  UNW_PPC64_R26 = 26,
+  UNW_PPC64_R27 = 27,
+  UNW_PPC64_R28 = 28,
+  UNW_PPC64_R29 = 29,
+  UNW_PPC64_R30 = 30,
+  UNW_PPC64_R31 = 31,
+  UNW_PPC64_F0  = 32,
+  UNW_PPC64_F1  = 33,
+  UNW_PPC64_F2  = 34,
+  UNW_PPC64_F3  = 35,
+  UNW_PPC64_F4  = 36,
+  UNW_PPC64_F5  = 37,
+  UNW_PPC64_F6  = 38,
+  UNW_PPC64_F7  = 39,
+  UNW_PPC64_F8  = 40,
+  UNW_PPC64_F9  = 41,
+  UNW_PPC64_F10 = 42,
+  UNW_PPC64_F11 = 43,
+  UNW_PPC64_F12 = 44,
+  UNW_PPC64_F13 = 45,
+  UNW_PPC64_F14 = 46,
+  UNW_PPC64_F15 = 47,
+  UNW_PPC64_F16 = 48,
+  UNW_PPC64_F17 = 49,
+  UNW_PPC64_F18 = 50,
+  UNW_PPC64_F19 = 51,
+  UNW_PPC64_F20 = 52,
+  UNW_PPC64_F21 = 53,
+  UNW_PPC64_F22 = 54,
+  UNW_PPC64_F23 = 55,
+  UNW_PPC64_F24 = 56,
+  UNW_PPC64_F25 = 57,
+  UNW_PPC64_F26 = 58,
+  UNW_PPC64_F27 = 59,
+  UNW_PPC64_F28 = 60,
+  UNW_PPC64_F29 = 61,
+  UNW_PPC64_F30 = 62,
+  UNW_PPC64_F31 = 63,
+  UNW_PPC64_LR  = 64,
+  UNW_PPC64_CTR = 65,
+  UNW_PPC64_CR0 = 66,
+  UNW_PPC64_CR1 = 67,
+  UNW_PPC64_CR2 = 68,
+  UNW_PPC64_CR3 = 69,
+  UNW_PPC64_CR4 = 70,
+  UNW_PPC64_CR5 = 71,
+  UNW_PPC64_CR6 = 72,
+  UNW_PPC64_CR7 = 73,
+  UNW_PPC64_XER = 74,
+  UNW_PPC64_V0 

[PATCH] D41677: Change memcpy/memove/memset to have dest and source alignment attributes.

[Daniel Neilson via Phabricator via cfe-commits]

dneilson created this revision.
dneilson added a reviewer: rjmccall.
Herald added subscribers: fedor.sergeev, kbarton, aheejin, sbc100, javed.absar, 
nhaehnle, nemanjai, jyknight.

Upstream LLVM is changing the the prototypes of the @llvm.memcpy/memmove/memset
intrinsics. This change updates the Clang CGBuilder and the Clang tests
for this change.

The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argument
which is required to be a constant integer. It represents the alignment of the
dest (and source), and so must be the minimum of the actual alignment of the
two.

This change allows source and dest to each have their own alignments by
using the alignment attribute on their arguments. The alignment argument
is removed.

For example, code which used to read:
 call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 
false)
will now read
 call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 
100, i1 false)


Repository:
  rC Clang

https://reviews.llvm.org/D41677

Files:
  lib/CodeGen/CGBuilder.h
  test/CodeGen/2007-11-07-CopyAggregateAlign.c
  test/CodeGen/2007-11-07-ZeroAggregateAlign.c
  test/CodeGen/64bit-swiftcall.c
  test/CodeGen/aarch64-neon-intrinsics.c
  test/CodeGen/aarch64-neon-ldst-one.c
  test/CodeGen/aarch64-neon-perm.c
  test/CodeGen/aarch64-poly64.c
  test/CodeGen/aarch64-v8.2a-neon-intrinsics.c
  test/CodeGen/arm-arguments.c
  test/CodeGen/arm64-be-bitfield.c
  test/CodeGen/arm_neon_intrinsics.c
  test/CodeGen/atomic-arm64.c
  test/CodeGen/block-byref-aggr.c
  test/CodeGen/builtin-memfns.c
  test/CodeGen/c11atomics-ios.c
  test/CodeGen/c11atomics.c
  test/CodeGen/compound-literal.c
  test/CodeGen/le32-vaarg.c
  test/CodeGen/ms-intrinsics.c
  test/CodeGen/no-opt-volatile-memcpy.c
  test/CodeGen/packed-nest-unpacked.c
  test/CodeGen/packed-structure.c
  test/CodeGen/partial-reinitialization2.c
  test/CodeGen/ppc-varargs-struct.c
  test/CodeGen/ppc64-align-struct.c
  test/CodeGen/ppc64-soft-float.c
  test/CodeGen/ppc64le-aggregates.c
  test/CodeGen/sparc-vaarg.c
  test/CodeGen/tbaa-struct.cpp
  test/CodeGen/volatile.c
  test/CodeGen/wasm-varargs.c
  test/CodeGen/windows-swiftcall.c
  test/CodeGen/x86-atomic-long_double.c
  test/CodeGen/x86_32-arguments-realign.c
  test/CodeGen/x86_64-arguments.c
  test/CodeGen/xcore-abi.c
  test/CodeGenCXX/alignment.cpp
  test/CodeGenCXX/assign-construct-memcpy.cpp
  test/CodeGenCXX/constructor-direct-call.cpp
  test/CodeGenCXX/copy-constructor-elim.cpp
  test/CodeGenCXX/copy-constructor-synthesis-2.cpp
  test/CodeGenCXX/copy-constructor-synthesis.cpp
  test/CodeGenCXX/cxx0x-delegating-ctors.cpp
  test/CodeGenCXX/cxx0x-initializer-array.cpp
  test/CodeGenCXX/cxx11-initializer-array-new.cpp
  test/CodeGenCXX/cxx1z-lambda-star-this.cpp
  test/CodeGenCXX/eh.cpp
  test/CodeGenCXX/float16-declarations.cpp
  test/CodeGenCXX/microsoft-abi-sret-and-byval.cpp
  test/CodeGenCXX/microsoft-abi-virtual-inheritance.cpp
  test/CodeGenCXX/microsoft-uuidof.cpp
  test/CodeGenCXX/new-array-init.cpp
  test/CodeGenCXX/no-opt-volatile-memcpy.cpp
  test/CodeGenCXX/pod-member-memcpys.cpp
  test/CodeGenCXX/pr20897.cpp
  test/CodeGenCXX/value-init.cpp
  test/CodeGenCXX/varargs.cpp
  test/CodeGenObjC/arc-foreach.m
  test/CodeGenObjC/arc.m
  test/CodeGenObjC/builtin-memfns.m
  test/CodeGenObjC/messages-2.m
  test/CodeGenObjC/stret-1.m
  test/CodeGenObjCXX/arc-exceptions.mm
  test/CodeGenOpenCL/amdgcn-automatic-variable.cl
  test/CodeGenOpenCL/amdgpu-nullptr.cl
  test/CodeGenOpenCL/partial_initializer.cl
  test/CodeGenOpenCL/private-array-initialization.cl
  test/Modules/templates.mm
  test/OpenMP/atomic_write_codegen.c
  test/OpenMP/distribute_firstprivate_codegen.cpp
  test/OpenMP/distribute_lastprivate_codegen.cpp
  test/OpenMP/distribute_parallel_for_firstprivate_codegen.cpp
  test/OpenMP/distribute_parallel_for_lastprivate_codegen.cpp
  test/OpenMP/distribute_parallel_for_simd_firstprivate_codegen.cpp
  test/OpenMP/distribute_parallel_for_simd_lastprivate_codegen.cpp
  test/OpenMP/distribute_simd_firstprivate_codegen.cpp
  test/OpenMP/distribute_simd_lastprivate_codegen.cpp
  test/OpenMP/for_firstprivate_codegen.cpp
  test/OpenMP/for_lastprivate_codegen.cpp
  test/OpenMP/for_reduction_codegen.cpp
  test/OpenMP/nvptx_target_firstprivate_codegen.cpp
  test/OpenMP/ordered_doacross_codegen.cpp
  test/OpenMP/parallel_codegen.cpp
  test/OpenMP/parallel_copyin_codegen.cpp
  test/OpenMP/parallel_firstprivate_codegen.cpp
  test/OpenMP/parallel_reduction_codegen.cpp
  test/OpenMP/sections_firstprivate_codegen.cpp
  test/OpenMP/sections_lastprivate_codegen.cpp
  test/OpenMP/sections_reduction_codegen.cpp
  test/OpenMP/single_codegen.cpp
  test/OpenMP/single_firstprivate_codegen.cpp
  test/OpenMP/target_enter_data_depend_codegen.cpp
  test/OpenMP/target_exit_data_depend_codegen.cpp
  test/OpenMP/target_firstprivate_codegen.cpp
  test/OpenMP/target_teams_distribute_firstprivate_codegen.cpp
  

[PATCH] D41660: [cmake] Add new linux toolchain file

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

@hintonda I think this should be a platform file in 
https://github.com/llvm-mirror/llvm/tree/master/cmake/platforms rather than 
Clang cache file. Platform files are concerned with the host platform 
(including cross-compilation), while cache files are  related to the 
distribution setup. What you're trying to do is the former rather than the 
latter. Some of the aspects of your setup like the bootstrap tool setup is 
already handled by the 2-stage build so you should use that rather than 
reimplementing your own solution.


Repository:
  rC Clang

https://reviews.llvm.org/D41660



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

[PATCH] D15935: Improve diagnostics for literal conversion to Boolean

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:3147-3149
+def warn_impcast_literal_to_bool : Warning<
+  "implicit conversion from %0 to %1; will always evaluate to "
+  "'%select{false|true}2'">, InGroup;

Warning groups are cheap, and fine-grained groups give users a way to 
incrementally roll out our new improved warnings.  Can we retain the 
string-conversion group and add a new warning flag for the new cases (both as 
subgroups of literal-conversion), rather than rolling them into a single group?

I think this diagnostic text is worse for the string literal case than the old 
text: the type of the string literal is not relevant to the warning, and 
displaying it seems confusing. For consistency, something like "implicit 
conversion from string literal to 'bool'; will always evaluate to 'true'" would 
work.

Also, please include the word "literal" in the version of this warning for 
floating-point and character literals. (And actually, maybe using the "implicit 
conversion from floating-point literal to 'bool' [...]" formulation would be 
clearer there too, rather than listing a largely-irrelevant type.)


https://reviews.llvm.org/D15935



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

[libcxx] r321666 - One more (should be) inline variable that is defined in the dylib

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Jan  2 11:23:30 2018
New Revision: 321666

URL: http://llvm.org/viewvc/llvm-project?rev=321666=rev
Log:
One more (should be) inline variable that is defined in the dylib

Modified:
libcxx/trunk/include/__mutex_base

Modified: libcxx/trunk/include/__mutex_base
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__mutex_base?rev=321666=321665=321666=diff
==
--- libcxx/trunk/include/__mutex_base (original)
+++ libcxx/trunk/include/__mutex_base Tue Jan  2 11:23:30 2018
@@ -82,9 +82,9 @@ extern const adopt_lock_t  adopt_lock;
 
 #else
 
-_LIBCPP_INLINE_VAR constexpr defer_lock_t  defer_lock  = defer_lock_t();
-_LIBCPP_INLINE_VAR constexpr try_to_lock_t try_to_lock = try_to_lock_t();
-_LIBCPP_INLINE_VAR constexpr adopt_lock_t  adopt_lock  = adopt_lock_t();
+/* _LIBCPP_INLINE_VAR */ constexpr defer_lock_t  defer_lock  = defer_lock_t();
+/* _LIBCPP_INLINE_VAR */ constexpr try_to_lock_t try_to_lock = try_to_lock_t();
+/* _LIBCPP_INLINE_VAR */ constexpr adopt_lock_t  adopt_lock  = adopt_lock_t();
 
 #endif
 


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

[PATCH] D41660: [cmake] Add new linux toolchain file

[Don Hinton via Phabricator via cfe-commits]

hintonda added a comment.

In https://reviews.llvm.org/D41660#965935, @hintonda wrote:

> In https://reviews.llvm.org/D41660#965877, @beanz wrote:
>
> > You should split the CMake cache file you created into two files, (1) a 
> > CMake Cache to manage the build configuration and (2) a tool chain file for 
> > targeting Linux. As @semeenai pointed out we absolutly want the behavior of 
> > the toolchain file being loaded multiple times. That is the correct way 
> > this build should work.
>
>
> I really like keeping this in a single file, but will break it up if 
> necessary.
>
> The `if` part of the if/else is used in stage1 as a cache file, and the 
> `else` part used in stage2 (and as you said, is loaded many times).  
> Splitting this into two files won't make much difference in that regard.
>
> > For bootstrap builds where you want the stage1 to run on your build host, 
> > you should be able to set `BOOTSTRAP_CMAKE_TOOLCHAIN_FILE` in the first 
> > stage build, to signal to the first stage build that the second stage will 
> > be cross-compiled, and we can customize the multi-stage dependencies 
> > correctly based on that. That avoids the need for the 
> > `ADDITIONAL_CLANG_BOOTSTRAP_DEPS` variable, which feels a bit hacky to me.
>
> Unless there's another way to do it, It's not hacky.  I believe the term is 
> `escape hatch`.
>
> While I'm happy to use `BOOTSTRAP_CMAKE_TOOLCHAIN_FILE` instead of passing 
> `-DCMAKE_TOOLCHAIN_FILE=${CMAKE_CURRENT_LIST_FILE}`, I do not see how it 
> helps with this problem.  When running `ninja stage2`, I need to insure that 
> the dependancies where built.  `BOOTSTRAP_LLVM_ENABLE_LLD` can be used to add 
> `lld` to the dependency list, but since I'm setting 
> `CLANG_DEFAULT_LINKER=llb`, I don't want clang adding `-fuse-ld`.


Did a quick test and setting BOOTSTRAP_CMAKE_TOOLCHAIN_FILE does not work in 
this case.

> If I run this on Linux for both stages, it doesn't matter, because 
> clang/CMakeLists.txt add llvm-ar and llvm-ranlib automatically, but since I'm 
> on APPLE (see clang/CMakeLists.txt:559), they don't get added.
> 
> So, how else would I add them?




Repository:
  rC Clang

https://reviews.llvm.org/D41660



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

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added a comment.

@weimingz: Since your platform supports `srand(0)`, is it possible to look at 
how your platform implements `srand(0)` and "inline" that implementation into 
`random_device`? That seems like it would be more in keeping with the other 
ifdefs in this file.

I'm confident that constructing an instance of `random_device` MUST NOT 
actually call `srand`. (I'd like to say that it shouldn't even call `rand`.) 
Either of those calls would be observable by the programmer. But there is a 
precedent for e.g. `random_shuffle` making calls to `rand`.


Repository:
  rCXX libc++

https://reviews.llvm.org/D41316



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

r321665 - Suppress undefined-template warnings when the pattern is declared in a system header.

[Nick Lewycky via cfe-commits]

Author: nicholas
Date: Tue Jan  2 11:10:12 2018
New Revision: 321665

URL: http://llvm.org/viewvc/llvm-project?rev=321665=rev
Log:
Suppress undefined-template warnings when the pattern is declared in a system 
header.

The way to fix an undefined-template warning is to add lines to the header file 
that defines the template pattern. We should suppress the warnings when the 
template pattern is in a system header because we don't expect users to edit 
those.

Modified:
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/test/SemaTemplate/undefined-template.cpp

Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp?rev=321665=321664=321665=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp Tue Jan  2 11:10:12 2018
@@ -3812,7 +3812,8 @@ void Sema::InstantiateFunctionDefinition
   PendingInstantiations.push_back(
 std::make_pair(Function, PointOfInstantiation));
 } else if (TSK == TSK_ImplicitInstantiation) {
-  if (AtEndOfTU && !getDiagnostics().hasErrorOccurred()) {
+  if (AtEndOfTU && !getDiagnostics().hasErrorOccurred() &&
+  !getSourceManager().isInSystemHeader(PatternDecl->getLocStart())) {
 Diag(PointOfInstantiation, diag::warn_func_template_missing)
   << Function;
 Diag(PatternDecl->getLocation(), diag::note_forward_template_decl);
@@ -4347,7 +4348,8 @@ void Sema::InstantiateVariableDefinition
 std::make_pair(Var, PointOfInstantiation));
 } else if (TSK == TSK_ImplicitInstantiation) {
   // Warn about missing definition at the end of translation unit.
-  if (AtEndOfTU && !getDiagnostics().hasErrorOccurred()) {
+  if (AtEndOfTU && !getDiagnostics().hasErrorOccurred() &&
+  !getSourceManager().isInSystemHeader(PatternDecl->getLocStart())) {
 Diag(PointOfInstantiation, diag::warn_var_template_missing)
   << Var;
 Diag(PatternDecl->getLocation(), diag::note_forward_template_decl);

Modified: cfe/trunk/test/SemaTemplate/undefined-template.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaTemplate/undefined-template.cpp?rev=321665=321664=321665=diff
==
--- cfe/trunk/test/SemaTemplate/undefined-template.cpp (original)
+++ cfe/trunk/test/SemaTemplate/undefined-template.cpp Tue Jan  2 11:10:12 2018
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -std=c++14 -Wundefined-func-template 
%s
 
+#if !defined(INCLUDE)
 template  struct C1 {
   static char s_var_1;   // expected-note{{forward declaration of template 
entity is here}}
   static char s_var_2;   // expected-note{{forward declaration of template 
entity is here}}
@@ -142,6 +143,16 @@ namespace test_24 {
   void h(X x) { g(x); } // no warning for use of 'g' despite the 
declaration having been instantiated from a template
 }
 
+#define INCLUDE
+#include "undefined-template.cpp"
+void func_25(SystemHeader *x) {
+  x->meth();
+}
+
 int main() {
   return 0;
 }
+#else
+#pragma clang system_header
+template  struct SystemHeader { T meth(); };
+#endif


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

[PATCH] D41655: [clang-tidy] New check bugprone-unused-return-value

[Kalle Huttunen via Phabricator via cfe-commits]

khuttun marked 7 inline comments as done.
khuttun added a comment.

In https://reviews.llvm.org/D41655#965551, @JonasToth wrote:

> I think it would be more user friendly if the configured list can be a list 
> and the `|` concatenation is done within your code.


What do you exactly mean by list? It seems some other checks use comma or 
semicolon separators in their configuration strings, but is that really more 
user friendly than using "|"? At least now it's clear that the whole string is 
a regex.


https://reviews.llvm.org/D41655



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

[PATCH] D40850: suppress undefined-template warnings when the pattern is declared in a system header

[Richard Smith - zygoloid via Phabricator via cfe-commits]

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

Thanks, I agree with your reasoning.


https://reviews.llvm.org/D40850



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

[libcxx] r321664 - Un-inline a few more variables that are exported from the dylib.

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Jan  2 11:01:45 2018
New Revision: 321664

URL: http://llvm.org/viewvc/llvm-project?rev=321664=rev
Log:
Un-inline a few more variables that are exported from the dylib.

Modified:
libcxx/trunk/include/__functional_base
libcxx/trunk/include/functional

Modified: libcxx/trunk/include/__functional_base
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__functional_base?rev=321664=321663=321664=diff
==
--- libcxx/trunk/include/__functional_base (original)
+++ libcxx/trunk/include/__functional_base Tue Jan  2 11:01:45 2018
@@ -564,7 +564,7 @@ struct _LIBCPP_TEMPLATE_VIS allocator_ar
 #if defined(_LIBCPP_CXX03_LANG) || defined(_LIBCPP_BUILDING_MEMORY)
 extern const allocator_arg_t allocator_arg;
 #else
-_LIBCPP_INLINE_VAR constexpr allocator_arg_t allocator_arg = allocator_arg_t();
+/* _LIBCPP_INLINE_VAR */ constexpr allocator_arg_t allocator_arg = 
allocator_arg_t();
 #endif
 
 // uses_allocator

Modified: libcxx/trunk/include/functional
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/functional?rev=321664=321663=321664=diff
==
--- libcxx/trunk/include/functional (original)
+++ libcxx/trunk/include/functional Tue Jan  2 11:01:45 2018
@@ -2020,16 +2020,16 @@ _LIBCPP_FUNC_VIS extern const __ph<8>
 _LIBCPP_FUNC_VIS extern const __ph<9>   _9;
 _LIBCPP_FUNC_VIS extern const __ph<10> _10;
 #else
-_LIBCPP_INLINE_VAR constexpr __ph<1>   _1{};
-_LIBCPP_INLINE_VAR constexpr __ph<2>   _2{};
-_LIBCPP_INLINE_VAR constexpr __ph<3>   _3{};
-_LIBCPP_INLINE_VAR constexpr __ph<4>   _4{};
-_LIBCPP_INLINE_VAR constexpr __ph<5>   _5{};
-_LIBCPP_INLINE_VAR constexpr __ph<6>   _6{};
-_LIBCPP_INLINE_VAR constexpr __ph<7>   _7{};
-_LIBCPP_INLINE_VAR constexpr __ph<8>   _8{};
-_LIBCPP_INLINE_VAR constexpr __ph<9>   _9{};
-_LIBCPP_INLINE_VAR constexpr __ph<10> _10{};
+/* _LIBCPP_INLINE_VAR */ constexpr __ph<1>   _1{};
+/* _LIBCPP_INLINE_VAR */ constexpr __ph<2>   _2{};
+/* _LIBCPP_INLINE_VAR */ constexpr __ph<3>   _3{};
+/* _LIBCPP_INLINE_VAR */ constexpr __ph<4>   _4{};
+/* _LIBCPP_INLINE_VAR */ constexpr __ph<5>   _5{};
+/* _LIBCPP_INLINE_VAR */ constexpr __ph<6>   _6{};
+/* _LIBCPP_INLINE_VAR */ constexpr __ph<7>   _7{};
+/* _LIBCPP_INLINE_VAR */ constexpr __ph<8>   _8{};
+/* _LIBCPP_INLINE_VAR */ constexpr __ph<9>   _9{};
+/* _LIBCPP_INLINE_VAR */ constexpr __ph<10> _10{};
 #endif // defined(_LIBCPP_CXX03_LANG) || defined(_LIBCPP_BUILDING_BIND)
 
 }  // placeholders


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

[libcxx] r321663 - Temporarily revert the inlining of 'piecewise_construct' because it is exported from the dylib.

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Jan  2 10:57:47 2018
New Revision: 321663

URL: http://llvm.org/viewvc/llvm-project?rev=321663=rev
Log:
Temporarily revert the inlining of 'piecewise_construct' because it is exported 
from the dylib.

Modified:
libcxx/trunk/include/utility

Modified: libcxx/trunk/include/utility
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/utility?rev=321663=321662=321663=diff
==
--- libcxx/trunk/include/utility (original)
+++ libcxx/trunk/include/utility Tue Jan  2 10:57:47 2018
@@ -296,7 +296,7 @@ struct _LIBCPP_TEMPLATE_VIS piecewise_co
 #if defined(_LIBCPP_CXX03_LANG) || defined(_LIBCPP_BUILDING_UTILITY)
 extern const piecewise_construct_t piecewise_construct;// = 
piecewise_construct_t();
 #else
-_LIBCPP_INLINE_VAR constexpr piecewise_construct_t piecewise_construct = 
piecewise_construct_t();
+/* _LIBCPP_INLINE_VAR */ constexpr piecewise_construct_t piecewise_construct = 
piecewise_construct_t();
 #endif
 
 #if defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)


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

[PATCH] D40850: suppress undefined-template warnings when the pattern is declared in a system header

[Nick Lewycky via Phabricator via cfe-commits]

nlewycky added a comment.

Ping!


https://reviews.llvm.org/D40850



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

[PATCH] D41416: [modules] [pch] Do not deserialize all lazy template specializations when looking for one.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

I think you should track lazy partial specializations separately from lazy full 
specializations -- we need to load all the partial specializations when doing 
partial specialization selection, and don't want to load all full 
specializations at the same time.




Comment at: lib/Serialization/ASTReaderDecl.cpp:92
   for (unsigned I = 0, Size = Record.readInt(); I != Size; ++I)
-IDs.push_back(ReadDeclID());
+IDs.push_back(LazySpecializationInfo(ReadDeclID(), Record.readInt()));
 }

Move these subexpressions to separate statements; the two "read" calls are not 
sequenced here.



Comment at: lib/Serialization/ASTReaderDecl.cpp:3972
   // It will be added to the template's lazy specialization set.
-  PendingLazySpecializationIDs.push_back(ReadDeclID());
+  LazySpecializationInfo LazySpecInfo(ReadDeclID(), Record.readInt());
+  PendingLazySpecializationIDs.push_back(LazySpecInfo);

Likewise here.


Repository:
  rL LLVM

https://reviews.llvm.org/D41416



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

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

[Weiming Zhao via Phabricator via cfe-commits]

weimingz added a comment.

Should we go with current patch? or provide a srand/rand based implementation 
as an option?


Repository:
  rCXX libc++

https://reviews.llvm.org/D41316



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

[libcxx] r321661 - A couple more inlined variables that I missed the first time

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Jan  2 10:41:01 2018
New Revision: 321661

URL: http://llvm.org/viewvc/llvm-project?rev=321661=rev
Log:
A couple more inlined variables that I missed the first time

Modified:
libcxx/trunk/include/type_traits
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/include/type_traits
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/type_traits?rev=321661=321660=321661=diff
==
--- libcxx/trunk/include/type_traits (original)
+++ libcxx/trunk/include/type_traits Tue Jan  2 10:41:01 2018
@@ -4523,12 +4523,14 @@ struct _LIBCPP_TEMPLATE_VIS is_invocable
 : integral_constant::value> {};
 
 template 
-constexpr bool is_invocable_v = is_invocable<_Fn, _Args...>::value;
+_LIBCPP_INLINE_VAR constexpr bool is_invocable_v
+= is_invocable<_Fn, _Args...>::value;
 
 template 
-constexpr bool is_invocable_r_v = is_invocable_r<_Ret, _Fn, _Args...>::value;
+_LIBCPP_INLINE_VAR constexpr bool is_invocable_r_v
+= is_invocable_r<_Ret, _Fn, _Args...>::value;
 
-// is_nothrow_callable
+// is_nothrow_invocable
 
 template 
 struct _LIBCPP_TEMPLATE_VIS is_nothrow_invocable
@@ -4539,10 +4541,12 @@ struct _LIBCPP_TEMPLATE_VIS is_nothrow_i
 : integral_constant::value> {};
 
 template 
-constexpr bool is_nothrow_invocable_v = is_nothrow_invocable<_Fn, 
_Args...>::value;
+_LIBCPP_INLINE_VAR constexpr bool is_nothrow_invocable_v
+= is_nothrow_invocable<_Fn, _Args...>::value;
 
 template 
-constexpr bool is_nothrow_invocable_r_v = is_nothrow_invocable_r<_Ret, _Fn, 
_Args...>::value;
+_LIBCPP_INLINE_VAR constexpr bool is_nothrow_invocable_r_v
+= is_nothrow_invocable_r<_Ret, _Fn, _Args...>::value;
 
 #endif // _LIBCPP_STD_VER > 14
 
@@ -4682,10 +4686,12 @@ struct _LIBCPP_TEMPLATE_VIS is_nothrow_s
 };
 
 template 
-constexpr bool is_swappable_with_v = is_swappable_with<_Tp, _Up>::value;
+_LIBCPP_INLINE_VAR constexpr bool is_swappable_with_v
+= is_swappable_with<_Tp, _Up>::value;
 
 template 
-constexpr bool is_swappable_v = is_swappable<_Tp>::value;
+_LIBCPP_INLINE_VAR constexpr bool is_swappable_v
+= is_swappable<_Tp>::value;
 
 template 
 _LIBCPP_INLINE_VAR constexpr bool is_nothrow_swappable_with_v

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=321661=321660=321661=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Tue Jan  2 10:41:01 2018
@@ -171,7 +171,7 @@
 
   
 
-The parts of P0607 that are not done are for 
has_unique_object_representations_v, is_callable_v and 
is_nothrow_callable_v, plus the regex bits.
+The parts of P0607 that are not done are for 
has_unique_object_representations_v, plus the regex 
bits.
 
 [ Note: "Nothing to do" means that no library changes were needed to 
implement this change -- end note]
 


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

[PATCH] D41660: [cmake] Add new linux toolchain file

[Don Hinton via Phabricator via cfe-commits]

hintonda added a comment.

In https://reviews.llvm.org/D41660#965877, @beanz wrote:

> You should split the CMake cache file you created into two files, (1) a CMake 
> Cache to manage the build configuration and (2) a tool chain file for 
> targeting Linux. As @semeenai pointed out we absolutly want the behavior of 
> the toolchain file being loaded multiple times. That is the correct way this 
> build should work.


I really like keeping this in a single file, but will break it up if necessary.

The `if` part of the if/else is used in stage1 as a cache file, and the `else` 
part used in stage2 (and as you said, is loaded many times).  Splitting this 
into two files won't make much difference in that regard.

> For bootstrap builds where you want the stage1 to run on your build host, you 
> should be able to set `BOOTSTRAP_CMAKE_TOOLCHAIN_FILE` in the first stage 
> build, to signal to the first stage build that the second stage will be 
> cross-compiled, and we can customize the multi-stage dependencies correctly 
> based on that. That avoids the need for the `ADDITIONAL_CLANG_BOOTSTRAP_DEPS` 
> variable, which feels a bit hacky to me.

Unless there's another way to do it, It's not hacky.  I believe the term is 
`escape hatch`.

While I'm happy to use `BOOTSTRAP_CMAKE_TOOLCHAIN_FILE` instead of passing 
`-DCMAKE_TOOLCHAIN_FILE=${CMAKE_CURRENT_LIST_FILE}`, I do not see how it helps 
with this problem.  When running `ninja stage2`, I need to insure that the 
dependancies where built.  `BOOTSTRAP_LLVM_ENABLE_LLD` can be used to add `lld` 
to the dependency list, but since I'm setting `CLANG_DEFAULT_LINKER=llb`, I 
don't want clang adding `-fuse-ld`.

If I run this on Linux for both stages, it doesn't matter, because 
clang/CMakeLists.txt add llvm-ar and llvm-ranlib automatically, but since I'm 
on APPLE (see clang/CMakeLists.txt:559), they don't get added.

So, how else would I add them?




Comment at: cmake/caches/linux-toolchain.cmake:2
+# This file is intended to support cross compiling a linux toolchain
+# on any host system, includind Darwin.
+#

smeenai wrote:
> Cross-compilation terminology is kinda weird, and traditionally, the "host" 
> is actually the system the built binaries will be run on (Linux in this 
> case), whereas the build machine is the "build" (but of course that word is 
> super ambiguous). I think LLVM generally sticks to that terminology though, 
> e.g. `LLVM_HOST_TRIPLE`.
I'll work on cleaning up this comment, but the idea is that we cross compile on 
any host system, e.g., Linux, Darwin, Windows, etc., and target Linux.



Comment at: cmake/caches/linux-toolchain.cmake:84
+  else()
+set(BOOTSTRAP_STAGE2_PROJECTS "clang;libcxx;libcxxabi;libunwind" CACHE 
STRING "" FORCE)
+  endif()

smeenai wrote:
> Nit: write this out as a list instead of a string with semicolons? (I know 
> they're equivalent, but the list reads nicer IMO.)
Perhaps, but this is the style used throughout the clang+llvm cmake files.



Comment at: cmake/caches/linux-toolchain.cmake:88
+  # Required on non-elf hosts.
+  set(ADDITIONAL_CLANG_BOOTSTRAP_DEPS "lld;llvm-ar;llvm-ranlib" CACHE STRING 
"")
+

smeenai wrote:
> Not exactly related, but I wonder why the LLVM build needs ranlib (rather 
> than just invoking ar appropriately).
Darwin version of ranlib doesn't like elf binaries, so we need the one we build 
in stage1.



Comment at: cmake/caches/linux-toolchain.cmake:102
+else()
+  set(CMAKE_SYSTEM_NAME Linux CACHE STRING "" FORCE)
+

smeenai wrote:
> The CMake documentation for CMAKE_SYSTEM_NAME says CMAKE_SYSTEM_VERSION 
> should also be set when cross-compiling (though I haven't seen any ill 
> effects from not doing so). Setting CMAKE_SYSTEM_PROCESSOR probably doesn't 
> hurt either.
These can be passed to stage1 as BOOTSTRAP_CMAKE_SYSTEM_VERSION, etc., allowing 
the user full control.  I'll add a note to the comments up top.


Repository:
  rC Clang

https://reviews.llvm.org/D41660



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

[PATCH] D41326: [clang-tidy] Added diagnostics about incorrect usage of NOLINT comment

[Anton via Phabricator via cfe-commits]

xgsa updated this revision to Diff 128431.
xgsa added a comment.

Rename the check `nolint-usage` => `readability-nolint-usage` for consistency.
Update diagnostics message according to the review comments.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D41326

Files:
  clang-tidy/ClangTidy.cpp
  clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tidy/ClangTidyDiagnosticConsumer.h
  test/clang-tidy/nolint.cpp
  test/clang-tidy/nolintnextline.cpp
  test/clang-tidy/readability-nolint-usage.cpp

Index: test/clang-tidy/readability-nolint-usage.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-nolint-usage.cpp
@@ -0,0 +1,171 @@
+// RUN: %check_clang_tidy %s readability-nolint-usage,google-explicit-constructor,misc-unused-parameters %t --
+
+// Case: NO_LINT on line with an error.
+class A1 { A1(int i); }; // NOLINT
+
+// Case: NO_LINT on line without errors.
+class A2 { explicit A2(int i); }; // NOLINT
+// CHECK-MESSAGES: :[[@LINE-1]]:38: warning: there are no diagnostics on this line
+
+// Case: NO_LINT for the specific check on line with an error on it.
+class A3 { A3(int i); }; // NOLINT(google-explicit-constructor)
+
+// Case: NO_LINT for the specific check on line with an error on another check.
+class A4 { A4(int i); }; // NOLINT(misc-unused-parameters)
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
+// CHECK-MESSAGES: :[[@LINE-2]]:29: warning: there are no diagnostics for 'misc-unused-parameters' on this line
+
+// Case: NO_LINT for the specific check on line without errors.
+class A5 { explicit A5(int i); }; // NOLINT(google-explicit-constructor)
+// CHECK-MESSAGES: :[[@LINE-1]]:38: warning: there are no diagnostics for 'google-explicit-constructor' on this line
+
+// Case: NO_LINT for unknown check on line with an error on some check.
+class A6 { A6(int i); }; // NOLINT(unknown-check)
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
+// CHECK-MESSAGES: :[[@LINE-2]]:29: warning: unknown check name 'unknown-check' specified in NOLINT comment
+
+// Case: NO_LINT for unknown check on line without errors.
+class A7 { explicit A7(int i); }; // NOLINT(unknown-check)
+// CHECK-MESSAGES: :[[@LINE-1]]:38: warning: unknown check name 'unknown-check' specified in NOLINT comment
+
+// Case: NO_LINT with not closed parenthesis without check names.
+class A8 { A8(int i); }; // NOLINT(
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: unbalanced parentheses in NOLINT comment; all diagnostics silenced for this line
+
+// Case: NO_LINT with not closed parenthesis with check names.
+class A9 { A9(int i); }; // NOLINT(unknown-check
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: unbalanced parentheses in NOLINT comment; all diagnostics silenced for this line
+
+// Case: NO_LINT with clang diagnostics
+int f() {
+  int i = 0; // NOLINT
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: there are no diagnostics on this line
+  int j = 0; // NOLINT(clang-diagnostic-unused-variable)
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: there are no diagnostics for 'clang-diagnostic-unused-variable' on this line
+  return i + j;
+}
+
+#define MACRO(X) class X { explicit X(int i); };
+
+// Case: NO_LINT on macro instantiation line
+MACRO(M1) // NOLINT
+// CHECK-MESSAGES: :[[@LINE-1]]:14: warning: there are no diagnostics on this line
+
+// Case: NO_LINT with the specific check on macro instantiation line
+MACRO(M2) // NOLINT(google-explicit-constructor)
+// CHECK-MESSAGES: :[[@LINE-1]]:14: warning: there are no diagnostics for 'google-explicit-constructor' on this line
+
+// Case: NO_LINT on macro line
+#define MACRO2(X) class X { explicit X(int i); }; // NOLINT
+MACRO2(M3)
+// CHECK-MESSAGES: :[[@LINE-2]]:54: warning: there are no diagnostics on this line
+
+// Case: NO_LINT with the specific check on macro line
+#define MACRO3(X) class X { explicit X(int i); }; // NOLINT(google-explicit-constructor)
+MACRO(M4)
+// CHECK-MESSAGES: :[[@LINE-2]]:54: warning: there are no diagnostics for 'google-explicit-constructor' on this line
+
+// Case: NO_LINT with readability-nolint-usage on line without errors.
+class B1 { explicit B1(int i); }; // NOLINT(readability-nolint-usage)
+
+// Case: NO_LINT with the specific check and readability-nolint-usage on line without errors.
+class B2 { explicit B2(int i); }; // NOLINT(google-explicit-constructor, readability-nolint-usage)
+
+// Case: NO_LINT with the unknown check and readability-nolint-usage on line without errors.
+class B3 { explicit B3(int i); }; // NOLINT(unknown-check, readability-nolint-usage)
+
+
+// Case: NO_LINT_NEXT_LINE before line with an error.
+// NOLINTNEXTLINE
+class C1 { C1(int i); };
+
+// Case: NO_LINT_NEXT_LINE before line without errors.
+// NOLINTNEXTLINE
+class C2 { explicit C2(int i); };
+// CHECK-MESSAGES: :[[@LINE-2]]:4: warning: there are no diagnostics on the next line
+
+// Case: 

Re: [PATCH] D41414: [analyzer] Add keyboard j/k navigation to HTML reports

[David Blaikie via cfe-commits]

Sure, this is post-commit review feedback.

vim with dvorak works in the sense that it's not unusable, but it's pretty
awkward (see, for example, discussions like this:
http://vim.wikia.com/wiki/Using_Vim_with_the_Dvorak_keyboard_layout )

On Tue, Jan 2, 2018 at 10:03 AM George Karpenkov 
wrote:

> This patch has already landed — also IIRC e.g. vim on dvorak also uses
> hjkl navigation with no issues.
>
>
> On Dec 25, 2017, at 11:21 AM, David Blaikie  wrote:
>
> any chance this can be implemented based on keyboard layout, so it's good
> for dvorak users as well? (maybe it already is, I don't know - just
> mentioning it in case)
>
> On Thu, Dec 21, 2017 at 2:58 PM George Karpenkov via Phabricator via
> cfe-commits  wrote:
>
>> This revision was automatically updated to reflect the committed changes.
>> Closed by commit rC321320: [analyzer] Add Javascript to analyzer HTML
>> output to allow keyboard navigation. (authored by george.karpenkov,
>> committed by ).
>> Herald added a subscriber: cfe-commits.
>>
>> Changed prior to commit:
>>   https://reviews.llvm.org/D41414?vs=127919=127954#toc
>>
>> Repository:
>>   rC Clang
>>
>> https://reviews.llvm.org/D41414
>>
>> Files:
>>   lib/Rewrite/HTMLRewrite.cpp
>>   lib/StaticAnalyzer/Core/HTMLDiagnostics.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

[PATCH] D41512: [Sema] -Wtautological-constant-compare is too good. Cripple it.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

@aaron.ballman, @smeenai, thank you for feedback!




Comment at: include/clang/Basic/DiagnosticGroups.td:440
 def TautologicalUnsignedEnumZeroCompare : 
DiagGroup<"tautological-unsigned-enum-zero-compare">;
+def TautologicalRangeCompare : 
DiagGroup<"tautological-constant-range-compare">;
 def TautologicalOutOfRangeCompare : 
DiagGroup<"tautological-constant-out-of-range-compare">;

smeenai wrote:
> aaron.ballman wrote:
> > lebedev.ri wrote:
> > > rsmith wrote:
> > > > "tautological-constant-in-range-compare" would make more sense to me, 
> > > > as the complement of "tautological-constant-out-of-range-compare".
> > > I did think about it.
> > > To me "tautological-constant-in-range-compare" may sound as if the 
> > > constant is //somewhere// in the range,
> > > while i'd say "tautological-constant-range-compare" better highlights the 
> > > fact that the constant *is* the range limit.
> > > No?
> > I don't have strong opinions on this name, but have a slight preference for 
> > "in range" because I'm left wondering how "range compare" relates to "out 
> > of range compare".
> How about range-limit-compare or range-edge-compare or range-bound-compare or 
> something of that nature, that explicitly captures the fact that it's the 
> range limit?
Ok, `def TautologicalInRangeCompare : 
DiagGroup<"tautological-constant-in-range-compare",` it is then.



Comment at: include/clang/Basic/DiagnosticGroups.td:438
 def StrncatSize : DiagGroup<"strncat-size">;
+def TautologicalTypeLimitCompare : 
DiagGroup<"tautological-type-limit-compare">;
 def TautologicalUnsignedZeroCompare : 
DiagGroup<"tautological-unsigned-zero-compare">;

Any opinion on this one?


Repository:
  rC Clang

https://reviews.llvm.org/D41512



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

[PATCH] D41528: [Sema] Don't emit the -Wstrict-prototypes warning for variadic functions.

[Volodymyr Sapsai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL321660: [Sema] Dont emit the -Wstrict-prototypes 
warning for variadic functions. (authored by vsapsai, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D41528?vs=127965=128430#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D41528

Files:
  cfe/trunk/lib/Sema/SemaType.cpp
  cfe/trunk/test/Sema/warn-strict-prototypes.c


Index: cfe/trunk/lib/Sema/SemaType.cpp
===
--- cfe/trunk/lib/Sema/SemaType.cpp
+++ cfe/trunk/lib/Sema/SemaType.cpp
@@ -4767,7 +4767,7 @@
 break;
   case DeclaratorChunk::Function: {
 const DeclaratorChunk::FunctionTypeInfo  = DeclType.Fun;
-if (FTI.NumParams == 0)
+if (FTI.NumParams == 0 && !FTI.isVariadic)
   S.Diag(DeclType.Loc, diag::warn_strict_prototypes)
   << IsBlock
   << FixItHint::CreateInsertion(FTI.getRParenLoc(), "void");
Index: cfe/trunk/test/Sema/warn-strict-prototypes.c
===
--- cfe/trunk/test/Sema/warn-strict-prototypes.c
+++ cfe/trunk/test/Sema/warn-strict-prototypes.c
@@ -65,3 +65,9 @@
 void __attribute__((cdecl)) foo12(d) // expected-warning {{this old-style 
function definition is not preceded by a prototype}}
   short d;
 {}
+
+// No warnings for variadic functions. Overloadable attribute is required
+// to avoid err_ellipsis_first_param error.
+// rdar://problem/33251668
+void foo13(...) __attribute__((overloadable));
+void foo13(...) __attribute__((overloadable)) {}


Index: cfe/trunk/lib/Sema/SemaType.cpp
===
--- cfe/trunk/lib/Sema/SemaType.cpp
+++ cfe/trunk/lib/Sema/SemaType.cpp
@@ -4767,7 +4767,7 @@
 break;
   case DeclaratorChunk::Function: {
 const DeclaratorChunk::FunctionTypeInfo  = DeclType.Fun;
-if (FTI.NumParams == 0)
+if (FTI.NumParams == 0 && !FTI.isVariadic)
   S.Diag(DeclType.Loc, diag::warn_strict_prototypes)
   << IsBlock
   << FixItHint::CreateInsertion(FTI.getRParenLoc(), "void");
Index: cfe/trunk/test/Sema/warn-strict-prototypes.c
===
--- cfe/trunk/test/Sema/warn-strict-prototypes.c
+++ cfe/trunk/test/Sema/warn-strict-prototypes.c
@@ -65,3 +65,9 @@
 void __attribute__((cdecl)) foo12(d) // expected-warning {{this old-style function definition is not preceded by a prototype}}
   short d;
 {}
+
+// No warnings for variadic functions. Overloadable attribute is required
+// to avoid err_ellipsis_first_param error.
+// rdar://problem/33251668
+void foo13(...) __attribute__((overloadable));
+void foo13(...) __attribute__((overloadable)) {}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D41414: [analyzer] Add keyboard j/k navigation to HTML reports

[George Karpenkov via cfe-commits]

This patch has already landed — also IIRC e.g. vim on dvorak also uses hjkl 
navigation with no issues.

> On Dec 25, 2017, at 11:21 AM, David Blaikie  wrote:
> 
> any chance this can be implemented based on keyboard layout, so it's good for 
> dvorak users as well? (maybe it already is, I don't know - just mentioning it 
> in case)
> 
> On Thu, Dec 21, 2017 at 2:58 PM George Karpenkov via Phabricator via 
> cfe-commits > 
> wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rC321320: [analyzer] Add Javascript to analyzer HTML output 
> to allow keyboard navigation. (authored by george.karpenkov, committed by ).
> Herald added a subscriber: cfe-commits.
> 
> Changed prior to commit:
>   https://reviews.llvm.org/D41414?vs=127919=127954#toc 
> 
> 
> Repository:
>   rC Clang
> 
> https://reviews.llvm.org/D41414 
> 
> Files:
>   lib/Rewrite/HTMLRewrite.cpp
>   lib/StaticAnalyzer/Core/HTMLDiagnostics.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

r321660 - [Sema] Don't emit the -Wstrict-prototypes warning for variadic functions.

[Volodymyr Sapsai via cfe-commits]

Author: vsapsai
Date: Tue Jan  2 10:02:19 2018
New Revision: 321660

URL: http://llvm.org/viewvc/llvm-project?rev=321660=rev
Log:
[Sema] Don't emit the -Wstrict-prototypes warning for variadic functions.

rdar://problem/33251668

Reviewers: arphaman, ahatanak

Reviewed By: arphaman

Subscribers: ptitei, cfe-commits

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

Modified:
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/test/Sema/warn-strict-prototypes.c

Modified: cfe/trunk/lib/Sema/SemaType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaType.cpp?rev=321660=321659=321660=diff
==
--- cfe/trunk/lib/Sema/SemaType.cpp (original)
+++ cfe/trunk/lib/Sema/SemaType.cpp Tue Jan  2 10:02:19 2018
@@ -4767,7 +4767,7 @@ static TypeSourceInfo *GetFullTypeForDec
 break;
   case DeclaratorChunk::Function: {
 const DeclaratorChunk::FunctionTypeInfo  = DeclType.Fun;
-if (FTI.NumParams == 0)
+if (FTI.NumParams == 0 && !FTI.isVariadic)
   S.Diag(DeclType.Loc, diag::warn_strict_prototypes)
   << IsBlock
   << FixItHint::CreateInsertion(FTI.getRParenLoc(), "void");

Modified: cfe/trunk/test/Sema/warn-strict-prototypes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/warn-strict-prototypes.c?rev=321660=321659=321660=diff
==
--- cfe/trunk/test/Sema/warn-strict-prototypes.c (original)
+++ cfe/trunk/test/Sema/warn-strict-prototypes.c Tue Jan  2 10:02:19 2018
@@ -65,3 +65,9 @@ void foo11(p, p2) int p; int p2; {}
 void __attribute__((cdecl)) foo12(d) // expected-warning {{this old-style 
function definition is not preceded by a prototype}}
   short d;
 {}
+
+// No warnings for variadic functions. Overloadable attribute is required
+// to avoid err_ellipsis_first_param error.
+// rdar://problem/33251668
+void foo13(...) __attribute__((overloadable));
+void foo13(...) __attribute__((overloadable)) {}


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

[PATCH] D41512: [Sema] -Wtautological-constant-compare is too good. Cripple it.

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.



Comment at: include/clang/Basic/DiagnosticGroups.td:440
 def TautologicalUnsignedEnumZeroCompare : 
DiagGroup<"tautological-unsigned-enum-zero-compare">;
+def TautologicalRangeCompare : 
DiagGroup<"tautological-constant-range-compare">;
 def TautologicalOutOfRangeCompare : 
DiagGroup<"tautological-constant-out-of-range-compare">;

aaron.ballman wrote:
> lebedev.ri wrote:
> > rsmith wrote:
> > > "tautological-constant-in-range-compare" would make more sense to me, as 
> > > the complement of "tautological-constant-out-of-range-compare".
> > I did think about it.
> > To me "tautological-constant-in-range-compare" may sound as if the constant 
> > is //somewhere// in the range,
> > while i'd say "tautological-constant-range-compare" better highlights the 
> > fact that the constant *is* the range limit.
> > No?
> I don't have strong opinions on this name, but have a slight preference for 
> "in range" because I'm left wondering how "range compare" relates to "out of 
> range compare".
How about range-limit-compare or range-edge-compare or range-bound-compare or 
something of that nature, that explicitly captures the fact that it's the range 
limit?


Repository:
  rC Clang

https://reviews.llvm.org/D41512



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

[PATCH] D41512: [Sema] -Wtautological-constant-compare is too good. Cripple it.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: include/clang/Basic/DiagnosticGroups.td:440
 def TautologicalUnsignedEnumZeroCompare : 
DiagGroup<"tautological-unsigned-enum-zero-compare">;
+def TautologicalRangeCompare : 
DiagGroup<"tautological-constant-range-compare">;
 def TautologicalOutOfRangeCompare : 
DiagGroup<"tautological-constant-out-of-range-compare">;

lebedev.ri wrote:
> rsmith wrote:
> > "tautological-constant-in-range-compare" would make more sense to me, as 
> > the complement of "tautological-constant-out-of-range-compare".
> I did think about it.
> To me "tautological-constant-in-range-compare" may sound as if the constant 
> is //somewhere// in the range,
> while i'd say "tautological-constant-range-compare" better highlights the 
> fact that the constant *is* the range limit.
> No?
I don't have strong opinions on this name, but have a slight preference for "in 
range" because I'm left wondering how "range compare" relates to "out of range 
compare".


Repository:
  rC Clang

https://reviews.llvm.org/D41512



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

Re: [PATCH] D41039: Add support for attribute "trivial_abi"

[David Blaikie via cfe-commits]

On Tue, Dec 19, 2017 at 9:43 PM Akira Hatanaka  wrote:

> On Tue, Dec 12, 2017 at 12:12 PM, John McCall  wrote:
>
>> On Tue, Dec 12, 2017 at 1:45 PM, David Blaikie 
>> wrote:
>>
>>> On Mon, Dec 11, 2017 at 5:38 PM John McCall  wrote:
>>>
 On Mon, Dec 11, 2017 at 6:19 PM, David Blaikie 
 wrote:

> On Mon, Dec 11, 2017 at 3:16 PM John McCall via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> rjmccall added a comment.
>>
>> In https://reviews.llvm.org/D41039#951648, @ahatanak wrote:
>>
>> > I had a discussion with Duncan today and he pointed out that
>> perhaps we shouldn't allow users to annotate a struct with "trivial_abi" 
>> if
>> one of its subobjects is non-trivial and is not annotated with
>> "trivial_abi" since that gives users too much power.
>> >
>> > Should we error out or drop "trivial_abi" from struct Outer when
>> the following code is compiled?
>> >
>> >   struct Inner1 {
>> > ~Inner1(); // non-trivial
>> > int x;
>> >   };
>> >
>> >   struct __attribute__((trivial_abi)) Outer {
>> > ~Outer();
>> > Inner1 x;
>> >   };
>> >
>> >
>> > The current patch doesn't error out or drop the attribute, but the
>> patch would probably be much simpler if we didn't allow it.
>>
>>
>> I think it makes sense to emit an error if there is provably a
>> non-trivial-ABI component.  However, for class temploids I think that
>> diagnostic should only fire on the definition, not on instantiations; for
>> example:
>>
>>   template  struct __attribute__((trivial_abi)) holder {
>>  T value;
>>  ~holder() {}
>>   };
>>   holder hs; // this instantiation should be legal
>> despite the fact that holder cannot be trivial-ABI.
>>
>> But we should still be able to emit the diagnostic in template
>> definitions, e.g.:
>>
>>   template  struct __attribute__((trivial_abi)) named_holder
>> {
>>  std::string name; // there are no instantiations of this
>> template that could ever be trivial-ABI
>>  T value;
>>  ~named_holder() {}
>>   };
>>
>> The wording should be something akin to the standard template rule
>> that a template is ill-formed if it has no valid instantiations, no
>> diagnostic required.
>>
>> I would definitely like to open the conversation about the name of
>> the attribute.  I don't think we've used "abi" in an existing attribute
>> name; usually it's more descriptive.  And "trivial" is a weighty word in
>> the standard.  I'm not sure I have a great counter-proposal off the top 
>> of
>> my head, though.
>>
>
> Agreed on both counts (would love a better name, don't have any
> stand-out candidates off the top of my head).
>
> I feel like a more descriptive term about the property of the object
> would make me happier - something like "address_independent_identity"
> (s/identity/value/?) though, yeah, that's not spectacular by any stretch.
>

 Incidentally, your comments are not showing up on Phabricator for some
 reason.

>>>
>>> Yeah, Phab doesn't do a great job looking on the mailing list for
>>> interesting replies - I forget, maybe it only catches bottom post or top
>>> post but not infix replies or something...
>>>
>>
>> Well, fortunately the mailing list is also archived. :)
>>
>>
>>> The term "trivially movable" suggests itself, with two caveats:
   - What we're talking about is trivial *destructive* movability, i.e.
 that the combination of moving the value to a new object and not destroying
 the old object can be done trivially, which is not quite the same as
 trivial movability in the normal C++ sense, which I guess could be a
 property that someone theoretically might care about (if the type is
 trivially destructed, but it isn't copyable for semantic reasons?).
   - Trivial destructive movability is a really common property, and
 it's something that a compiler would really like to optimize based on even
 in cases where trivial_abi can't be adopted for binary-compatibility
 reasons.  Stealing the term for the stronger property that the type is
 trivially destructively movable *and its ABI should reflect that in a
 specific way* would be unfortunate.

>>>
>>> Fair point.
>>>
>>>
 "trivially_movable" is a long attribute anyway, and
 "trivially_destructively_movable" is even worse.

 Maybe that second point is telling us that this isn't purely
 descriptive — it's inherently talking about the ABI, not just the semantics
 of the type.  I might be talking myself into accepting trivial_abi if we
 don't end up with a better suggestion.

>>>
>>> *nod* I think if you want to 

[PATCH] D41239: Turn a config macro (_LIBCPP_HAS_NO_INLINE_VARIABLES) into an attribute macro (_LIBCPP_INLINE_VAR)

[Marshall Clow via Phabricator via cfe-commits]

mclow.lists abandoned this revision.
mclow.lists added a comment.

This was committed as part of r321658


https://reviews.llvm.org/D41239



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

[libcxx] r321658 - Implement most of P0607: Inline Variables for the Standard Library. This involved marking a lot of variables as inline (but only for C++17 and later).

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Jan  2 09:17:01 2018
New Revision: 321658

URL: http://llvm.org/viewvc/llvm-project?rev=321658=rev
Log:
Implement most of P0607: Inline Variables for the Standard Library. This 
involved marking a lot of variables as inline (but only for C++17 and later).

Modified:
libcxx/trunk/include/__config
libcxx/trunk/include/__functional_base
libcxx/trunk/include/__mutex_base
libcxx/trunk/include/chrono
libcxx/trunk/include/functional
libcxx/trunk/include/memory
libcxx/trunk/include/mutex
libcxx/trunk/include/optional
libcxx/trunk/include/ratio
libcxx/trunk/include/system_error
libcxx/trunk/include/tuple
libcxx/trunk/include/type_traits
libcxx/trunk/include/utility
libcxx/trunk/include/variant
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=321658=321657=321658=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Tue Jan  2 09:17:01 2018
@@ -980,9 +980,10 @@ template  struct __static_asse
 #define _LIBCPP_NODISCARD_AFTER_CXX17
 #endif
 
-// FIXME: Remove all usages of this macro once compilers catch up.
-#if !defined(__cpp_inline_variables) || (__cpp_inline_variables < 201606L)
-# define _LIBCPP_HAS_NO_INLINE_VARIABLES
+#if _LIBCPP_STD_VER > 14 && defined(__cpp_inline_variables) && 
(__cpp_inline_variables >= 201606L)
+# define _LIBCPP_INLINE_VAR  inline
+#else
+# define _LIBCPP_INLINE_VAR  
 #endif
 
 #ifdef _LIBCPP_HAS_NO_RVALUE_REFERENCES

Modified: libcxx/trunk/include/__functional_base
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__functional_base?rev=321658=321657=321658=diff
==
--- libcxx/trunk/include/__functional_base (original)
+++ libcxx/trunk/include/__functional_base Tue Jan  2 09:17:01 2018
@@ -564,7 +564,7 @@ struct _LIBCPP_TEMPLATE_VIS allocator_ar
 #if defined(_LIBCPP_CXX03_LANG) || defined(_LIBCPP_BUILDING_MEMORY)
 extern const allocator_arg_t allocator_arg;
 #else
-constexpr allocator_arg_t allocator_arg = allocator_arg_t();
+_LIBCPP_INLINE_VAR constexpr allocator_arg_t allocator_arg = allocator_arg_t();
 #endif
 
 // uses_allocator
@@ -601,7 +601,7 @@ struct _LIBCPP_TEMPLATE_VIS uses_allocat
 
 #if _LIBCPP_STD_VER > 14
 template 
-constexpr size_t uses_allocator_v = uses_allocator<_Tp, _Alloc>::value;
+_LIBCPP_INLINE_VAR constexpr size_t uses_allocator_v = uses_allocator<_Tp, 
_Alloc>::value;
 #endif
 
 #ifndef _LIBCPP_CXX03_LANG

Modified: libcxx/trunk/include/__mutex_base
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__mutex_base?rev=321658=321657=321658=diff
==
--- libcxx/trunk/include/__mutex_base (original)
+++ libcxx/trunk/include/__mutex_base Tue Jan  2 09:17:01 2018
@@ -82,9 +82,9 @@ extern const adopt_lock_t  adopt_lock;
 
 #else
 
-constexpr defer_lock_t  defer_lock  = defer_lock_t();
-constexpr try_to_lock_t try_to_lock = try_to_lock_t();
-constexpr adopt_lock_t  adopt_lock  = adopt_lock_t();
+_LIBCPP_INLINE_VAR constexpr defer_lock_t  defer_lock  = defer_lock_t();
+_LIBCPP_INLINE_VAR constexpr try_to_lock_t try_to_lock = try_to_lock_t();
+_LIBCPP_INLINE_VAR constexpr adopt_lock_t  adopt_lock  = adopt_lock_t();
 
 #endif
 

Modified: libcxx/trunk/include/chrono
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/chrono?rev=321658=321657=321658=diff
==
--- libcxx/trunk/include/chrono (original)
+++ libcxx/trunk/include/chrono Tue Jan  2 09:17:01 2018
@@ -26,7 +26,7 @@ duration_cast(const duration 
{};
 
 #if _LIBCPP_STD_VER > 14 && !defined(_LIBCPP_HAS_NO_VARIABLE_TEMPLATES)
-template  _LIBCPP_CONSTEXPR bool treat_as_floating_point_v
+template 
+_LIBCPP_INLINE_VAR _LIBCPP_CONSTEXPR bool treat_as_floating_point_v
 = treat_as_floating_point<_Rep>::value;
 #endif
 

Modified: libcxx/trunk/include/functional
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/functional?rev=321658=321657=321658=diff
==
--- libcxx/trunk/include/functional (original)
+++ libcxx/trunk/include/functional Tue Jan  2 09:17:01 2018
@@ -213,9 +213,9 @@ template struct is_bind_express
 template struct is_placeholder;
 
 // See C++14 20.9.9, Function object binders
-template  

[PATCH] D41668: [clangd] Add static index for the global code completion.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added reviewers: sammccall, ioeric.
Herald added subscribers: ilya-biryukov, klimek.

Use the YAML-format symbols (generated by the global-symbol-builder tool) to
do the global code completion.
It is **experimental** only , but it allows us to experience global code
completion on a relatively small project.

Tested with LLVM project.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D41668

Files:
  clangd/ClangdLSPServer.cpp
  clangd/ClangdLSPServer.h
  clangd/ClangdServer.cpp
  clangd/ClangdServer.h
  clangd/CodeComplete.cpp
  clangd/CodeComplete.h
  clangd/index/MemIndex.cpp
  clangd/index/MemIndex.h
  clangd/tool/ClangdMain.cpp
  unittests/clangd/CodeCompleteTests.cpp

Index: unittests/clangd/CodeCompleteTests.cpp
===
--- unittests/clangd/CodeCompleteTests.cpp
+++ unittests/clangd/CodeCompleteTests.cpp
@@ -453,12 +453,6 @@
 
 std::unique_ptr simpleIndexFromSymbols(
 std::vector> Symbols) {
-  auto I = llvm::make_unique();
-  struct Snapshot {
-SymbolSlab Slab;
-std::vector Pointers;
-  };
-  auto Snap = std::make_shared();
   SymbolSlab::Builder Slab;
   for (const auto  : Symbols) {
 Symbol Sym;
@@ -475,13 +469,7 @@
 Sym.SymInfo.Kind = Pair.second;
 Slab.insert(Sym);
   }
-  Snap->Slab = std::move(Slab).build();
-  for (auto  : Snap->Slab)
-Snap->Pointers.push_back();
-  auto S = std::shared_ptr(std::move(Snap),
->Pointers);
-  I->build(std::move(S));
-  return std::move(I);
+  return BuildMemIndex(std::move(Slab));
 }
 
 TEST(CompletionTest, NoIndex) {
@@ -496,6 +484,18 @@
   EXPECT_THAT(Results.items, Has("No"));
 }
 
+TEST(CompletionTest, StaticIndex) {
+  clangd::CodeCompleteOptions Opts;
+  auto I = simpleIndexFromSymbols({{"ns::XYZ", index::SymbolKind::Class}});
+  Opts.StaticIndex = I.get();
+
+  auto Results = completions(R"cpp(
+  void f() { ::ns::^ }
+  )cpp",
+ Opts);
+  EXPECT_THAT(Results.items, Has("XYZ", CompletionItemKind::Class));
+}
+
 TEST(CompletionTest, SimpleIndexBased) {
   clangd::CodeCompleteOptions Opts;
   auto I = simpleIndexFromSymbols({{"ns::XYZ", index::SymbolKind::Class},
Index: clangd/tool/ClangdMain.cpp
===
--- clangd/tool/ClangdMain.cpp
+++ clangd/tool/ClangdMain.cpp
@@ -11,6 +11,7 @@
 #include "JSONRPCDispatcher.h"
 #include "Path.h"
 #include "Trace.h"
+#include "index/SymbolYAML.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
@@ -26,7 +27,25 @@
 
 namespace {
 enum class PCHStorageFlag { Disk, Memory };
+
+// Build an in-memory static index for global symbols from a YAML-format file.
+// The size of global symbols should be relatively small, so that all symbols
+// can be managed in memory.
+std::unique_ptr
+BuildGlobalIndex(llvm::StringRef GlobalSymbolFilePath) {
+  auto Buffer = llvm::MemoryBuffer::getFile(GlobalSymbolFilePath);
+  if (!Buffer) {
+llvm::errs() << "Can't open " << GlobalSymbolFilePath << "\n";
+return nullptr;
+  }
+  auto Slab = SymbolFromYAML(Buffer.get()->getBuffer());
+  SymbolSlab::Builder SymsBuilder;
+  for (auto Sym : Slab)
+SymsBuilder.insert(Sym);
+
+  return BuildMemIndex(std::move(SymsBuilder));
 }
+} // namespace
 
 static llvm::cl::opt CompileCommandsDir(
 "compile-commands-dir",
@@ -97,6 +116,13 @@
 "use index built from symbols in opened files"),
 llvm::cl::init(false), llvm::cl::Hidden);
 
+static llvm::cl::opt GlobalIndexFile(
+"global-index-file",
+llvm::cl::desc(
+"YAML-format global symbol file to build the static index. It is only "
+"available when 'enable-index-based-completion' is enabled."),
+llvm::cl::init(""), llvm::cl::Hidden);
+
 int main(int argc, char *argv[]) {
   llvm::cl::ParseCommandLineOptions(argc, argv, "clangd");
 
@@ -182,13 +208,16 @@
   // Change stdin to binary to not lose \r\n on windows.
   llvm::sys::ChangeStdinToBinary();
 
+  std::unique_ptr GlobalIdx;
+  if (EnableIndexBasedCompletion && !GlobalIndexFile.empty())
+GlobalIdx = BuildGlobalIndex(GlobalIndexFile);
   clangd::CodeCompleteOptions CCOpts;
   CCOpts.EnableSnippets = EnableSnippets;
   CCOpts.IncludeIneligibleResults = IncludeIneligibleResults;
   // Initialize and run ClangdLSPServer.
   ClangdLSPServer LSPServer(Out, WorkerThreadsCount, StorePreamblesInMemory,
 CCOpts, ResourceDirRef, CompileCommandsDirPath,
-EnableIndexBasedCompletion);
+EnableIndexBasedCompletion, std::move(GlobalIdx));
   constexpr int NoShutdownRequestErrorCode = 1;
   llvm::set_thread_name("clangd.main");
   return LSPServer.run(std::cin) ? 0 : NoShutdownRequestErrorCode;
Index: clangd/index/MemIndex.h

[PATCH] D41660: [cmake] Add new linux toolchain file

[Chris Bieneman via Phabricator via cfe-commits]

beanz added a comment.

You should split the CMake cache file you created into two files, (1) a CMake 
Cache to manage the build configuration and (2) a tool chain file for targeting 
Linux. As @semeenai pointed out we absolutly want the behavior of the toolchain 
file being loaded multiple times. That is the correct way this build should 
work.

For bootstrap builds where you want the stage1 to run on your build host, you 
should be able to set `BOOTSTRAP_CMAKE_TOOLCHAIN_FILE` in the first stage 
build, to signal to the first stage build that the second stage will be 
cross-compiled, and we can customize the multi-stage dependencies correctly 
based on that. That avoids the need for the `ADDITIONAL_CLANG_BOOTSTRAP_DEPS` 
variable, which feels a bit hacky to me.


Repository:
  rC Clang

https://reviews.llvm.org/D41660



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

[PATCH] D41660: [cmake] Add new linux toolchain file

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D41660#965686, @hintonda wrote:

> In https://reviews.llvm.org/D41660#965656, @smeenai wrote:
>
> >
>
>
> Cache files are preferred since they are only loaded once


Isn't that precisely the behavior needed for cross-compilation though? You want 
all of your CMake configuration checks (which are independent CMake configures) 
to load your toolchain file, which is what you get automatically (and cache 
files don't behave that way).

From what I understand, the if part of the top-level `if(DEFINED SYSROOT)` is 
essentially functioning as a cache file to set up the stage2 build, and the 
else part is used as a toolchain file for that build. I think it would be 
cleaner to separate the two out; other cache files seem to be split out into 
stage1 and stage2 caches, for example (over here it would be stage1 cache and a 
stage2 toolchain, but the concept is similar).




Comment at: cmake/caches/linux-toolchain.cmake:2
+# This file is intended to support cross compiling a linux toolchain
+# on any host system, includind Darwin.
+#

Cross-compilation terminology is kinda weird, and traditionally, the "host" is 
actually the system the built binaries will be run on (Linux in this case), 
whereas the build machine is the "build" (but of course that word is super 
ambiguous). I think LLVM generally sticks to that terminology though, e.g. 
`LLVM_HOST_TRIPLE`.



Comment at: cmake/caches/linux-toolchain.cmake:84
+  else()
+set(BOOTSTRAP_STAGE2_PROJECTS "clang;libcxx;libcxxabi;libunwind" CACHE 
STRING "" FORCE)
+  endif()

Nit: write this out as a list instead of a string with semicolons? (I know 
they're equivalent, but the list reads nicer IMO.)



Comment at: cmake/caches/linux-toolchain.cmake:88
+  # Required on non-elf hosts.
+  set(ADDITIONAL_CLANG_BOOTSTRAP_DEPS "lld;llvm-ar;llvm-ranlib" CACHE STRING 
"")
+

Not exactly related, but I wonder why the LLVM build needs ranlib (rather than 
just invoking ar appropriately).



Comment at: cmake/caches/linux-toolchain.cmake:102
+else()
+  set(CMAKE_SYSTEM_NAME Linux CACHE STRING "" FORCE)
+

The CMake documentation for CMAKE_SYSTEM_NAME says CMAKE_SYSTEM_VERSION should 
also be set when cross-compiling (though I haven't seen any ill effects from 
not doing so). Setting CMAKE_SYSTEM_PROCESSOR probably doesn't hurt either.


Repository:
  rC Clang

https://reviews.llvm.org/D41660



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

[PATCH] D33563: Track whether a unary operation can overflow

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Post-holiday ping.


https://reviews.llvm.org/D33563



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

[PATCH] D41553: Support parsing double square-bracket attributes in ObjC

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Post-holiday ping.


https://reviews.llvm.org/D41553



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

[PATCH] D15935: Improve diagnostics for literal conversion to Boolean

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Post-holiday ping.


https://reviews.llvm.org/D15935



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

[PATCH] D41317: Infrastructure for adding C attributes

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Post-holiday ping.


https://reviews.llvm.org/D41317



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