Re: [PATCH] D18478: python bindings: expose the clang version string

2016-08-07 Thread Saleem Abdulrasool via cfe-commits
compnerd added a comment.

Hmm, could do something devious.  Write the test and run that through the c 
preprocessor and then use that to compare the string.  Ugly, but would be 
completely generic and ensure that we see the value we expect always.


https://reviews.llvm.org/D18478



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


Re: [PATCH] D22426: Fix automatic detection of ARM MSVC toolset in clang.exe

2016-08-07 Thread Saleem Abdulrasool via cfe-commits
compnerd added inline comments.


Comment at: lib/Driver/MSVCToolChain.cpp:478
@@ +477,3 @@
+  // toolset, if it exists.
+  if (llvm::sys::fs::exists(X64BinDir)) {
+path = X64BinDir.str();

As per the consensus, this should be:

if (llvm::sys::getProcessTriple().getArch() == llvm::Triple::x86_64 && 
llvm::sys::fs::exists(X64BinDir)) {


https://reviews.llvm.org/D22426



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


r277976 - Pass information in a record instead of stack. NFC

2016-08-07 Thread Serge Pavlov via cfe-commits
Author: sepavloff
Date: Sun Aug  7 23:02:15 2016
New Revision: 277976

URL: http://llvm.org/viewvc/llvm-project?rev=277976=rev
Log:
Pass information in a record instead of stack. NFC

Functions of Sema that work with building of nested name specifiers have too
many parameters (BuildCXXNestedNameSpecifier already expects 10 arguments).
With this change the information about identifier and its context is packed
into a structure, which is then passes to the semantic functions.

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Parse/ParseExprCXX.cpp
cfe/trunk/lib/Sema/SemaCXXScopeSpec.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/TreeTransform.h

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=277976=277975=277976=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Sun Aug  7 23:02:15 2016
@@ -4954,16 +4954,41 @@ public:
bool *CanCorrect = nullptr);
   NamedDecl *FindFirstQualifierInScope(Scope *S, NestedNameSpecifier *NNS);
 
+  /// \brief Keeps information about an identifier in a nested-name-spec.
+  ///
+  struct NestedNameSpecInfo {
+/// \brief The type of the object, if we're parsing nested-name-specifier 
in
+/// a member access expression.
+ParsedType ObjectType;
+
+/// \brief The identifier preceding the '::'.
+IdentifierInfo *Identifier;
+
+/// \brief The location of the identifier.
+SourceLocation IdentifierLoc;
+
+/// \brief The location of the '::'.
+SourceLocation CCLoc;
+
+/// \brief Creates info object for the most typical case.
+NestedNameSpecInfo(IdentifierInfo *II, SourceLocation IdLoc,
+ SourceLocation ColonColonLoc, ParsedType ObjectType = 
ParsedType())
+  : ObjectType(ObjectType), Identifier(II), IdentifierLoc(IdLoc),
+CCLoc(ColonColonLoc) {
+}
+
+NestedNameSpecInfo(IdentifierInfo *II, SourceLocation IdLoc,
+   SourceLocation ColonColonLoc, QualType ObjectType)
+  : ObjectType(ParsedType::make(ObjectType)), Identifier(II),
+IdentifierLoc(IdLoc), CCLoc(ColonColonLoc) {
+}
+  };
+
   bool isNonTypeNestedNameSpecifier(Scope *S, CXXScopeSpec ,
-SourceLocation IdLoc,
-IdentifierInfo ,
-ParsedType ObjectType);
+NestedNameSpecInfo );
 
   bool BuildCXXNestedNameSpecifier(Scope *S,
-   IdentifierInfo ,
-   SourceLocation IdentifierLoc,
-   SourceLocation CCLoc,
-   QualType ObjectType,
+   NestedNameSpecInfo ,
bool EnteringContext,
CXXScopeSpec ,
NamedDecl *ScopeLookupResult,
@@ -4974,14 +4999,8 @@ public:
   ///
   /// \param S The scope in which this nested-name-specifier occurs.
   ///
-  /// \param Identifier The identifier preceding the '::'.
-  ///
-  /// \param IdentifierLoc The location of the identifier.
-  ///
-  /// \param CCLoc The location of the '::'.
-  ///
-  /// \param ObjectType The type of the object, if we're parsing
-  /// nested-name-specifier in a member access expression.
+  /// \param IdInfo Parser information about an identifier in the
+  /// nested-name-spec.
   ///
   /// \param EnteringContext Whether we're entering the context nominated by
   /// this nested-name-specifier.
@@ -5000,10 +5019,7 @@ public:
   ///
   /// \returns true if an error occurred, false otherwise.
   bool ActOnCXXNestedNameSpecifier(Scope *S,
-   IdentifierInfo ,
-   SourceLocation IdentifierLoc,
-   SourceLocation CCLoc,
-   ParsedType ObjectType,
+   NestedNameSpecInfo ,
bool EnteringContext,
CXXScopeSpec ,
bool ErrorRecoveryLookup = false,
@@ -5016,10 +5032,7 @@ public:
SourceLocation ColonColonLoc);
 
   bool IsInvalidUnlessNestedName(Scope *S, CXXScopeSpec ,
- IdentifierInfo ,
- SourceLocation IdentifierLoc,
- SourceLocation ColonLoc,
- ParsedType ObjectType,
+ NestedNameSpecInfo ,
  bool EnteringContext);
 
   /// \brief The parser has parsed a nested-name-specifier

Modified: 

Re: [PATCH] D22904: Fix two bugs for musl-libc on ARM

2016-08-07 Thread Lei Zhang via cfe-commits
zlei added a comment.

@rengolin Could you please apply this patch? I don't have the permission.

Thanks.


https://reviews.llvm.org/D22904



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


Re: [PATCH] D22666: Frontend: Fix mcount inlining bug

2016-08-07 Thread Honggyu Kim via cfe-commits
honggyu.kim added a comment.

In https://reviews.llvm.org/D22666#506884, @compnerd wrote:

> The `\01` is to prevent the mangler from touching the function name.  If you 
> noticed the check tags in the quoted test, some targets expect it to be 
> decorated and others do not.  What exactly do you mean that `lit` has a 
> strings matching with `\01`?  Its not a string `\01`, its the octal character 
> 1.


Hi Saleem,

It seems that name mangling is done before mcount call insertion so I think we 
don't have to put `\01` prefix for mcount names.  I have tested on x86-64 and 
ARM.  Are there any other targets that work in a different order?
I've checked this `clang::CodeGen::CodeGenModule::getMangledName()` is always 
executed before `clang::CodeGen::CodeGenFunction::StartFunction()`, which 
actually inserts mcount calls.
Please correct me if I'm wrong


https://reviews.llvm.org/D22666



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


[libcxx] r277970 - Fix copy/move constructor annotation for the uses-allocator test types.

2016-08-07 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Sun Aug  7 21:22:41 2016
New Revision: 277970

URL: http://llvm.org/viewvc/llvm-project?rev=277970=rev
Log:
Fix copy/move constructor annotation for the uses-allocator test types.

Previously the copy/move constructors of the test types did not
properly set the arg_id to T const& or T&& respectivly.


Modified:
libcxx/trunk/test/support/uses_alloc_types.hpp

Modified: libcxx/trunk/test/support/uses_alloc_types.hpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/support/uses_alloc_types.hpp?rev=277970=277969=277970=diff
==
--- libcxx/trunk/test/support/uses_alloc_types.hpp (original)
+++ libcxx/trunk/test/support/uses_alloc_types.hpp Sun Aug  7 21:22:41 2016
@@ -119,7 +119,7 @@ using detail::EnableIfB;
 
 struct AllocLastTag {};
 
-template 
+template 
 struct UsesAllocatorTestBase {
 public:
 using CtorAlloc = typename std::conditional<
@@ -153,6 +153,16 @@ protected:
 : args_id(aid), constructor_called(UA_None), allocator()
 {}
 
+UsesAllocatorTestBase(UsesAllocatorTestBase const&)
+: args_id(()), constructor_called(UA_None),
+  allocator()
+{}
+
+UsesAllocatorTestBase(UsesAllocatorTestBase&&)
+: args_id(()), constructor_called(UA_None),
+  allocator()
+{}
+
 template 
 UsesAllocatorTestBase(std::allocator_arg_t, CtorAlloc const& a, Args&&...)
 : args_id(()),
@@ -188,12 +198,12 @@ private:
 };
 
 template 
-class UsesAllocatorV1 : public UsesAllocatorTestBase
+class UsesAllocatorV1 : public UsesAllocatorTestBase, Alloc>
 {
 public:
 typedef Alloc allocator_type;
 
-using Base = UsesAllocatorTestBase;
+using Base = UsesAllocatorTestBase;
 using CtorAlloc = typename Base::CtorAlloc;
 
 UsesAllocatorV1() : Base(<>()) {}
@@ -218,12 +228,12 @@ public:
 
 
 template 
-class UsesAllocatorV2 : public UsesAllocatorTestBase
+class UsesAllocatorV2 : public UsesAllocatorTestBase, Alloc>
 {
 public:
 typedef Alloc allocator_type;
 
-using Base = UsesAllocatorTestBase;
+using Base = UsesAllocatorTestBase;
 using CtorAlloc = typename Base::CtorAlloc;
 
 UsesAllocatorV2() : Base(<>()) {}
@@ -240,12 +250,12 @@ public:
 };
 
 template 
-class UsesAllocatorV3 : public UsesAllocatorTestBase
+class UsesAllocatorV3 : public UsesAllocatorTestBase, Alloc>
 {
 public:
 typedef Alloc allocator_type;
 
-using Base = UsesAllocatorTestBase;
+using Base = UsesAllocatorTestBase;
 using CtorAlloc = typename Base::CtorAlloc;
 
 UsesAllocatorV3() : Base(<>()) {}
@@ -268,12 +278,12 @@ public:
 };
 
 template 
-class NotUsesAllocator : public UsesAllocatorTestBase
+class NotUsesAllocator : public UsesAllocatorTestBase, Alloc>
 {
 public:
 // no allocator_type typedef provided
 
-using Base = UsesAllocatorTestBase;
+using Base = UsesAllocatorTestBase;
 using CtorAlloc = typename Base::CtorAlloc;
 
 NotUsesAllocator() : Base(<>()) {}


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


Re: r277923 - [ASTReader] Use real move semantics instead of emulating them in the copy ctor.

2016-08-07 Thread Piotr Padlewski via cfe-commits
2016-08-06 5:45 GMT-07:00 Benjamin Kramer via cfe-commits <
cfe-commits@lists.llvm.org>:

> Author: d0k
> Date: Sat Aug  6 07:45:16 2016
> New Revision: 277923
>
> URL: http://llvm.org/viewvc/llvm-project?rev=277923=rev
> Log:
> [ASTReader] Use real move semantics instead of emulating them in the copy
> ctor.
>
> No functionality change intended.
>
> Modified:
> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>
> Modified: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/
> Serialization/ASTReaderDecl.cpp?rev=277923=277922=277923=diff
> 
> ==
> --- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp (original)
> +++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp Sat Aug  6 07:45:16 2016
> @@ -170,12 +170,12 @@ namespace clang {
>ASTReader 
>NamedDecl *New;
>NamedDecl *Existing;
> -  mutable bool AddResult;
> +  bool AddResult;
>
>unsigned AnonymousDeclNumber;
>IdentifierInfo *TypedefNameForLinkage;
>
> -  void operator=(FindExistingResult&) = delete;
> +  void operator=(FindExistingResult &&) = delete;
>
>  public:
>FindExistingResult(ASTReader )
> @@ -189,7 +189,7 @@ namespace clang {
>  AnonymousDeclNumber(AnonymousDeclNumber),
>  TypedefNameForLinkage(TypedefNameForLinkage) {}
>
> -  FindExistingResult(const FindExistingResult )
> +  FindExistingResult(FindExistingResult &)
>: Reader(Other.Reader), New(Other.New),
> Existing(Other.Existing),
>  AddResult(Other.AddResult),
>  AnonymousDeclNumber(Other.AnonymousDeclNumber),
>
> Shouldn't these lines have std::move() everywhere to make them real move
ctors?



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Piotr Padlewski via cfe-commits
2016-08-07 15:38 GMT-07:00 Aaron Ballman :

On Sun, Aug 7, 2016 at 6:33 PM, Piotr Padlewski
>  wrote:
> > Prazek added a comment.
> >
> > Yea, I also have never heard of it. I don't think it is worth even
> discussing
>
Just because you've never heard of a compiler extension that gets
> pointed out during review does not mean it's not worth discussing. Not
> everyone has heard of every compiler vendor extension we support,
> that's why we do public review in a wide audience. :-) Again, I am not
> suggesting the OP do this as part of this patch.
>
> GCC has many extensions. My point is that I also don't know any user that
use it.
Of course it doesn't imply that no one is using it, but I strongly belive
that
There are so few user in the word that I think it is much better to spend
time doing something other useful in clang-tidy than to even discuss this
topic.
It is good that you have mentioned it, at least I learned something new :)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D22996: [cxx1z-constexpr-lambda] Implement constant evaluation of non-capturing lambda expressions.

2016-08-07 Thread Hubert Tong via cfe-commits
hubert.reinterpretcast added inline comments.


Comment at: lib/AST/ExprConstant.cpp:5775
@@ +5774,3 @@
+Info.FFDiag(E, diag::note_unimplemented_constexpr_lambda_feature_ast)
+<< "can not evaluate lambda expressions with captures";
+return false;

Minor nit: I think this should be "cannot".


Comment at: test/SemaCXX/cxx1z-constexpr-lambdas.cpp:10
@@ +9,3 @@
+#endif
+auto L = [] { };
+constexpr int foo(decltype(L) l) { return 0; }

Mark this `constexpr` as well?


Repository:
  rL LLVM

https://reviews.llvm.org/D22996



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Aaron Ballman via cfe-commits
On Sun, Aug 7, 2016 at 6:33 PM, Piotr Padlewski
 wrote:
> Prazek added a comment.
>
> Yea, I also have never heard of it. I don't think it is worth even discussing

Just because you've never heard of a compiler extension that gets
pointed out during review does not mean it's not worth discussing. Not
everyone has heard of every compiler vendor extension we support,
that's why we do public review in a wide audience. :-) Again, I am not
suggesting the OP do this as part of this patch.

~Aaron

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


[libcxx] r277968 - [libcxx] Add "flag" default arg: basic_regex ptr_size_flag ctor

2016-08-07 Thread Hubert Tong via cfe-commits
Author: hubert.reinterpretcast
Date: Sun Aug  7 17:26:04 2016
New Revision: 277968

URL: http://llvm.org/viewvc/llvm-project?rev=277968=rev
Log:
[libcxx] Add "flag" default arg: basic_regex ptr_size_flag ctor

Summary:
The synopsis in C++11 subclause 28.8 [re.regex] has:
```
basic_regex(const charT* p, size_t len,
flag_type f = regex_constants::ECMAScript);
```

The default argument is added to libc++ by this change.

Reviewers: mclow.lists, rsmith, hubert.reinterpretcast

Subscribers: cfe-commits

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

Reapplies r277966.
Patch by Jason Liu!

Added:
libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp
Modified:
libcxx/trunk/include/regex

Modified: libcxx/trunk/include/regex
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/regex?rev=277968=277967=277968=diff
==
--- libcxx/trunk/include/regex (original)
+++ libcxx/trunk/include/regex Sun Aug  7 17:26:04 2016
@@ -147,7 +147,7 @@ public:
 // construct/copy/destroy:
 basic_regex();
 explicit basic_regex(const charT* p, flag_type f = 
regex_constants::ECMAScript);
-basic_regex(const charT* p, size_t len, flag_type f);
+basic_regex(const charT* p, size_t len, flag_type f = 
regex_constants::ECMAScript);
 basic_regex(const basic_regex&);
 basic_regex(basic_regex&&) noexcept;
 template 
@@ -2519,7 +2519,7 @@ public:
   __end_(0)
 {__parse(__p, __p + __traits_.length(__p));}
 _LIBCPP_INLINE_VISIBILITY
-basic_regex(const value_type* __p, size_t __len, flag_type __f)
+basic_regex(const value_type* __p, size_t __len, flag_type __f = 
regex_constants::ECMAScript)
 : __flags_(__f), __marked_count_(0), __loop_count_(0), 
__open_count_(0),
   __end_(0)
 {__parse(__p, __p + __len);}

Added: libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp?rev=277968=auto
==
--- libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp 
(added)
+++ libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp Sun 
Aug  7 17:26:04 2016
@@ -0,0 +1,39 @@
+//===--===//
+//
+// 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.
+//
+//===--===//
+
+// 
+
+// template > class 
basic_regex;
+
+// basic_regex(const charT* p, size_t len);
+
+#include 
+#include 
+
+template 
+void
+test(const CharT* p, std::size_t len, unsigned mc)
+{
+std::basic_regex r(p, len);
+assert(r.flags() == std::regex_constants::ECMAScript);
+assert(r.mark_count() == mc);
+}
+
+int main()
+{
+test("\\(a\\)", 5, 0);
+test("\\(a[bc]\\)", 9, 0);
+test("\\(a\\([bc]\\)\\)", 13, 0);
+test("(a([bc]))", 9, 2);
+
+test("(\0)(b)(c)(d)", 12, 4);
+test("(\0)(b)(c)(d)", 9, 3);
+test("(\0)(b)(c)(d)", 3, 1);
+test("(\0)(b)(c)(d)", 0, 0);
+}


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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Piotr Padlewski via cfe-commits
Prazek added a comment.

Yea, I also have never heard of it. I don't think it is worth even discussing


https://reviews.llvm.org/D23243



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


[libcxx] r277967 - Revert r277966. Forgot patch attribution.

2016-08-07 Thread Hubert Tong via cfe-commits
Author: hubert.reinterpretcast
Date: Sun Aug  7 17:23:24 2016
New Revision: 277967

URL: http://llvm.org/viewvc/llvm-project?rev=277967=rev
Log:
Revert r277966. Forgot patch attribution.

Removed:
libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp
Modified:
libcxx/trunk/include/regex

Modified: libcxx/trunk/include/regex
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/regex?rev=277967=277966=277967=diff
==
--- libcxx/trunk/include/regex (original)
+++ libcxx/trunk/include/regex Sun Aug  7 17:23:24 2016
@@ -147,7 +147,7 @@ public:
 // construct/copy/destroy:
 basic_regex();
 explicit basic_regex(const charT* p, flag_type f = 
regex_constants::ECMAScript);
-basic_regex(const charT* p, size_t len, flag_type f = 
regex_constants::ECMAScript);
+basic_regex(const charT* p, size_t len, flag_type f);
 basic_regex(const basic_regex&);
 basic_regex(basic_regex&&) noexcept;
 template 
@@ -2519,7 +2519,7 @@ public:
   __end_(0)
 {__parse(__p, __p + __traits_.length(__p));}
 _LIBCPP_INLINE_VISIBILITY
-basic_regex(const value_type* __p, size_t __len, flag_type __f = 
regex_constants::ECMAScript)
+basic_regex(const value_type* __p, size_t __len, flag_type __f)
 : __flags_(__f), __marked_count_(0), __loop_count_(0), 
__open_count_(0),
   __end_(0)
 {__parse(__p, __p + __len);}

Removed: libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp?rev=277966=auto
==
--- libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp 
(original)
+++ libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp 
(removed)
@@ -1,39 +0,0 @@
-//===--===//
-//
-// 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.
-//
-//===--===//
-
-// 
-
-// template > class 
basic_regex;
-
-// basic_regex(const charT* p, size_t len);
-
-#include 
-#include 
-
-template 
-void
-test(const CharT* p, std::size_t len, unsigned mc)
-{
-std::basic_regex r(p, len);
-assert(r.flags() == std::regex_constants::ECMAScript);
-assert(r.mark_count() == mc);
-}
-
-int main()
-{
-test("\\(a\\)", 5, 0);
-test("\\(a[bc]\\)", 9, 0);
-test("\\(a\\([bc]\\)\\)", 13, 0);
-test("(a([bc]))", 9, 2);
-
-test("(\0)(b)(c)(d)", 12, 4);
-test("(\0)(b)(c)(d)", 9, 3);
-test("(\0)(b)(c)(d)", 3, 1);
-test("(\0)(b)(c)(d)", 0, 0);
-}


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


[libcxx] r277966 - [libcxx] Add "flag" default arg: basic_regex ptr_size_flag ctor

2016-08-07 Thread Hubert Tong via cfe-commits
Author: hubert.reinterpretcast
Date: Sun Aug  7 17:18:33 2016
New Revision: 277966

URL: http://llvm.org/viewvc/llvm-project?rev=277966=rev
Log:
[libcxx] Add "flag" default arg: basic_regex ptr_size_flag ctor

Summary:
The synopsis in C++11 subclause 28.8 [re.regex] has:
```
basic_regex(const charT* p, size_t len,
flag_type f = regex_constants::ECMAScript);
```

The default argument is added to libc++ by this change.

Reviewers: mclow.lists, rsmith, hubert.reinterpretcast

Subscribers: cfe-commits

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

Added:
libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp
Modified:
libcxx/trunk/include/regex

Modified: libcxx/trunk/include/regex
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/regex?rev=277966=277965=277966=diff
==
--- libcxx/trunk/include/regex (original)
+++ libcxx/trunk/include/regex Sun Aug  7 17:18:33 2016
@@ -147,7 +147,7 @@ public:
 // construct/copy/destroy:
 basic_regex();
 explicit basic_regex(const charT* p, flag_type f = 
regex_constants::ECMAScript);
-basic_regex(const charT* p, size_t len, flag_type f);
+basic_regex(const charT* p, size_t len, flag_type f = 
regex_constants::ECMAScript);
 basic_regex(const basic_regex&);
 basic_regex(basic_regex&&) noexcept;
 template 
@@ -2519,7 +2519,7 @@ public:
   __end_(0)
 {__parse(__p, __p + __traits_.length(__p));}
 _LIBCPP_INLINE_VISIBILITY
-basic_regex(const value_type* __p, size_t __len, flag_type __f)
+basic_regex(const value_type* __p, size_t __len, flag_type __f = 
regex_constants::ECMAScript)
 : __flags_(__f), __marked_count_(0), __loop_count_(0), 
__open_count_(0),
   __end_(0)
 {__parse(__p, __p + __len);}

Added: libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp?rev=277966=auto
==
--- libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp 
(added)
+++ libcxx/trunk/test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp Sun 
Aug  7 17:18:33 2016
@@ -0,0 +1,39 @@
+//===--===//
+//
+// 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.
+//
+//===--===//
+
+// 
+
+// template > class 
basic_regex;
+
+// basic_regex(const charT* p, size_t len);
+
+#include 
+#include 
+
+template 
+void
+test(const CharT* p, std::size_t len, unsigned mc)
+{
+std::basic_regex r(p, len);
+assert(r.flags() == std::regex_constants::ECMAScript);
+assert(r.mark_count() == mc);
+}
+
+int main()
+{
+test("\\(a\\)", 5, 0);
+test("\\(a[bc]\\)", 9, 0);
+test("\\(a\\([bc]\\)\\)", 13, 0);
+test("(a([bc]))", 9, 2);
+
+test("(\0)(b)(c)(d)", 12, 4);
+test("(\0)(b)(c)(d)", 9, 3);
+test("(\0)(b)(c)(d)", 3, 1);
+test("(\0)(b)(c)(d)", 0, 0);
+}


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


[libcxx] r277964 - Mark LWG 2726 as complete. No code change needed.

2016-08-07 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Sun Aug  7 16:47:06 2016
New Revision: 277964

URL: http://llvm.org/viewvc/llvm-project?rev=277964=rev
Log:
Mark LWG 2726 as complete. No code change needed.


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=277964=277963=277964=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Sun Aug  7 16:47:06 2016
@@ -307,7 +307,7 @@
http://wg21.link/LWG2723;>2723Do 
directory_iterator and recursive_directory_iterator become the end iterator 
upon error?OuluComplete
http://wg21.link/LWG2724;>2724The 
protected virtual member functions of memory_resource should be 
privateOulu
http://wg21.link/LWG2725;>2725filesystem::exists(const 
path&, error_code&) error reportingOuluComplete
-   http://wg21.link/LWG2726;>2726[recursive_]directory_iterator::increment(error_code&)
 is underspecifiedOulu
+   http://wg21.link/LWG2726;>2726[recursive_]directory_iterator::increment(error_code&)
 is underspecifiedOuluComplete
http://wg21.link/LWG2727;>2727Parallel 
algorithms with constexpr specifierOulu
http://wg21.link/LWG2728;>2728status(p).permissions() and 
symlink_status(p).permissions() are not 
specifiedOuluComplete
 


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


Re: [PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

2016-08-07 Thread Joerg Sonnenberger via cfe-commits
On Sun, Aug 07, 2016 at 11:08:22AM +, Amjad Aboud via cfe-commits wrote:
> aaboud marked 3 inline comments as done.
> aaboud added a comment.
> 
> In https://reviews.llvm.org/D22045#506996, @joerg wrote:
> 
> > For what it is worth, this certainly seems to be misnamed. By nature, if it 
> > doesn't preserve at least the stack pointer, there is no way to recover on 
> > return, right?
> 
> 
> I am not sure I understand what you mean!
> When you  said "if it does not preserve the stack pointer", did you mean the 
> "caller"?
> 
> Maybe it need more clarification on that, but stack pointer should be
> saved by the caller (via the call instruction), but even in this case
> the callee must preserve the stack pointer, right? otherwise the return
> will not work. So, from callee point of view it still cannot assume
> that any register is a scratch register and it need to preserve it
> before modifying.

The call instruction itself only saves the return address. But the point
is that the stack pointer must be the same after the function call as
before. As such, the stack pointer is always implicitly caller saved and
must not be clobbered.

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


Re: [PATCH] [clang-format] add AfterMultilineControlStatement

2016-08-07 Thread Rinat Ibragimov via cfe-commits
I've seen couple of projects that have similar opening brace placement
for multiline conditions. Here are links to their style guides:

https://github.com/mpv-player/mpv/blob/master/DOCS/contribute.md

and

http://gem5.org/Coding_Style#Braces


>Воскресенье,  7 августа 2016, 3:04 +03:00 от Rinat Ibragimov via cfe-commits 
>:
>
>Hi.
>
>When indent is four spaces, "if" conditions spanning multiple lines
>could be difficult to discern from the "if" body. Indentation is the
>same, so they are visually blending. (See example below). One of the
>solutions is to place opening brace on a separate line when "if"
>condition spans multiple lines. Always putting it on a separate line
>in undesired, as there are usually no so many "if"s with multiline
>conditions.
>
>To make that possible, proposed patch adds another setting,
>BraceWrapping.AfterMultilineControlStatement which acts like
>BraceWrapping.AfterControlStatement, but only if condition in control
>statement spans over multiple lines.
>
>I didn't see a way to detach brace and move it to the next line once
>unwrapped lines are constructed. So when AfterMultilineControlStatement
>is enabled, all opening braces go to a separate unwrapped line. Then,
>if length of the line is not higher that column limit, code tries
>to reattach brace back.
>
>To make what I said above a bit clearer, here are examples:
>
>if (0 + 1 + 2 + 3 + 4 + 5 +
>6 + 7 + 8 + 9 + 10 + 11 +
>12 + 13 + 14 + 15) {
>some_code();
>some_other_code();
>}
>
>This patch allows to change that to:
>
>if (0 + 1 + 2 + 3 + 4 + 5 +
>6 + 7 + 8 + 9 + 10 + 11 +
>12 + 13 + 14 + 15)
>{
>some_code();
>some_other_code();
>}
>
>while keeping opening brace for short conditions on the same line:
>
>if (0) {
>some_code();
>}
>
>
>---
>Rinat
>___
>cfe-commits mailing list
>cfe-commits@lists.llvm.org
>http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Kirill Bobyrev via cfe-commits
omtcyfz added a comment.

In https://reviews.llvm.org/D23243#508097, @aaron.ballman wrote:

> LGTM! We may want to consider BinaryConditionalOperator as well, but that can 
> be in as a separate patch.


Well, I personally have never seen `BinaryConditionalOperator `in my life.

And honestly I'm not a fan of supporting GNU extensions - what makes sense to 
me is to use `BinaryConditionalOperator` in a check which suggests not using 
GNU extensions.

Anyway, I'd be glad if @alexfh could jump in and take a look.


https://reviews.llvm.org/D23243



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Aaron Ballman via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM! We may want to consider BinaryConditionalOperator as well, but that can 
be in as a separate patch.



Comment at: clang-tidy/modernize/UseBoolLiteralsCheck.cpp:51-52
@@ -34,4 +50,4 @@
 void UseBoolLiteralsCheck::check(const MatchFinder::MatchResult ) {
-  const auto *Literal = Result.Nodes.getNodeAs("literal");
-  const auto *Cast = Result.Nodes.getNodeAs("cast");
-  bool LiteralBooleanValue = Literal->getValue().getBoolValue();
+  for (const auto  :
+   {"literal", "trueBranchLiteral", "falseBranchLiteral"}) {
+const auto *Literal = Result.Nodes.getNodeAs(BindingName);

omtcyfz wrote:
> aaron.ballman wrote:
> > omtcyfz wrote:
> > > aaron.ballman wrote:
> > > > omtcyfz wrote:
> > > > > aaron.ballman wrote:
> > > > > > omtcyfz wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > Any reason not to name the bind "literal" in all three cases? 
> > > > > > > > That eliminates the need for the loop entirely, since `check()` 
> > > > > > > > will trigger for each instance of a match.
> > > > > > > It doesn't make sense to try binding both `TrueExpression` and 
> > > > > > > `FalseExpression` literals to a single value.
> > > > > > Why? In all three cases, you don't care what matched, just that 
> > > > > > *some* case is matched. None of the logic in `check()` relies on 
> > > > > > which part of the expression is matched.
> > > > > Well, in case of second matcher I may have **two** literals matched 
> > > > > upon triggering. I don't understand how I could possibly get **two** 
> > > > > literals bound to **one** value after **one** matcher got triggered.
> > > > > 
> > > > > Am I missing something?
> > > > One matcher isn't what's getting triggered then, is it? I could be 
> > > > wrong on this point, but I thought that in that case, `check()` would 
> > > > be called twice, once for each literal. Is that not the case?
> > > From what I understand about how matchers work, it is not. Plus, I 
> > > checked (just named everything `"literal"` and removed `for (const auto 
> > > ...` just to double check in case I was wrong.
> > Thank you for checking -- I learned something new! :-)
> No problem :)
> 
> One case in which your solution would work is splitting second matcher into 
> two: one with `hasTrueExpression` and one with `hasFalseExpression`, then 
> binding to `"literal"` would work. But it'll be inefficient and three names 
> of bindings don't seem like too much hardcoding after all.
I agree, that would be a step backwards.


https://reviews.llvm.org/D23243



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Aaron Ballman via cfe-commits
aaron.ballman added inline comments.


Comment at: clang-tidy/modernize/UseBoolLiteralsCheck.cpp:51-52
@@ -34,4 +50,4 @@
 void UseBoolLiteralsCheck::check(const MatchFinder::MatchResult ) {
-  const auto *Literal = Result.Nodes.getNodeAs("literal");
-  const auto *Cast = Result.Nodes.getNodeAs("cast");
-  bool LiteralBooleanValue = Literal->getValue().getBoolValue();
+  for (const auto  :
+   {"literal", "trueBranchLiteral", "falseBranchLiteral"}) {
+const auto *Literal = Result.Nodes.getNodeAs(BindingName);

omtcyfz wrote:
> aaron.ballman wrote:
> > omtcyfz wrote:
> > > aaron.ballman wrote:
> > > > omtcyfz wrote:
> > > > > aaron.ballman wrote:
> > > > > > Any reason not to name the bind "literal" in all three cases? That 
> > > > > > eliminates the need for the loop entirely, since `check()` will 
> > > > > > trigger for each instance of a match.
> > > > > It doesn't make sense to try binding both `TrueExpression` and 
> > > > > `FalseExpression` literals to a single value.
> > > > Why? In all three cases, you don't care what matched, just that *some* 
> > > > case is matched. None of the logic in `check()` relies on which part of 
> > > > the expression is matched.
> > > Well, in case of second matcher I may have **two** literals matched upon 
> > > triggering. I don't understand how I could possibly get **two** literals 
> > > bound to **one** value after **one** matcher got triggered.
> > > 
> > > Am I missing something?
> > One matcher isn't what's getting triggered then, is it? I could be wrong on 
> > this point, but I thought that in that case, `check()` would be called 
> > twice, once for each literal. Is that not the case?
> From what I understand about how matchers work, it is not. Plus, I checked 
> (just named everything `"literal"` and removed `for (const auto ...` just to 
> double check in case I was wrong.
Thank you for checking -- I learned something new! :-)


https://reviews.llvm.org/D23243



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Kirill Bobyrev via cfe-commits
omtcyfz added inline comments.


Comment at: clang-tidy/modernize/UseBoolLiteralsCheck.cpp:51-52
@@ -34,4 +50,4 @@
 void UseBoolLiteralsCheck::check(const MatchFinder::MatchResult ) {
-  const auto *Literal = Result.Nodes.getNodeAs("literal");
-  const auto *Cast = Result.Nodes.getNodeAs("cast");
-  bool LiteralBooleanValue = Literal->getValue().getBoolValue();
+  for (const auto  :
+   {"literal", "trueBranchLiteral", "falseBranchLiteral"}) {
+const auto *Literal = Result.Nodes.getNodeAs(BindingName);

aaron.ballman wrote:
> omtcyfz wrote:
> > aaron.ballman wrote:
> > > omtcyfz wrote:
> > > > aaron.ballman wrote:
> > > > > Any reason not to name the bind "literal" in all three cases? That 
> > > > > eliminates the need for the loop entirely, since `check()` will 
> > > > > trigger for each instance of a match.
> > > > It doesn't make sense to try binding both `TrueExpression` and 
> > > > `FalseExpression` literals to a single value.
> > > Why? In all three cases, you don't care what matched, just that *some* 
> > > case is matched. None of the logic in `check()` relies on which part of 
> > > the expression is matched.
> > Well, in case of second matcher I may have **two** literals matched upon 
> > triggering. I don't understand how I could possibly get **two** literals 
> > bound to **one** value after **one** matcher got triggered.
> > 
> > Am I missing something?
> One matcher isn't what's getting triggered then, is it? I could be wrong on 
> this point, but I thought that in that case, `check()` would be called twice, 
> once for each literal. Is that not the case?
From what I understand about how matchers work, it is not. Plus, I checked 
(just named everything `"literal"` and removed `for (const auto ...` just to 
double check in case I was wrong.


https://reviews.llvm.org/D23243



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Kirill Bobyrev via cfe-commits
omtcyfz added inline comments.


Comment at: clang-tidy/modernize/UseBoolLiteralsCheck.cpp:51-52
@@ -34,4 +50,4 @@
 void UseBoolLiteralsCheck::check(const MatchFinder::MatchResult ) {
-  const auto *Literal = Result.Nodes.getNodeAs("literal");
-  const auto *Cast = Result.Nodes.getNodeAs("cast");
-  bool LiteralBooleanValue = Literal->getValue().getBoolValue();
+  for (const auto  :
+   {"literal", "trueBranchLiteral", "falseBranchLiteral"}) {
+const auto *Literal = Result.Nodes.getNodeAs(BindingName);

aaron.ballman wrote:
> omtcyfz wrote:
> > aaron.ballman wrote:
> > > Any reason not to name the bind "literal" in all three cases? That 
> > > eliminates the need for the loop entirely, since `check()` will trigger 
> > > for each instance of a match.
> > It doesn't make sense to try binding both `TrueExpression` and 
> > `FalseExpression` literals to a single value.
> Why? In all three cases, you don't care what matched, just that *some* case 
> is matched. None of the logic in `check()` relies on which part of the 
> expression is matched.
Well, in case of second matcher I may have **two** literals matched upon 
triggering. I don't understand how I could possibly get **two** literals bound 
to **one** value after **one** matcher got triggered.

Am I missing something?


https://reviews.llvm.org/D23243



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Aaron Ballman via cfe-commits
aaron.ballman added inline comments.


Comment at: clang-tidy/modernize/UseBoolLiteralsCheck.cpp:51-52
@@ -34,4 +50,4 @@
 void UseBoolLiteralsCheck::check(const MatchFinder::MatchResult ) {
-  const auto *Literal = Result.Nodes.getNodeAs("literal");
-  const auto *Cast = Result.Nodes.getNodeAs("cast");
-  bool LiteralBooleanValue = Literal->getValue().getBoolValue();
+  for (const auto  :
+   {"literal", "trueBranchLiteral", "falseBranchLiteral"}) {
+const auto *Literal = Result.Nodes.getNodeAs(BindingName);

omtcyfz wrote:
> aaron.ballman wrote:
> > Any reason not to name the bind "literal" in all three cases? That 
> > eliminates the need for the loop entirely, since `check()` will trigger for 
> > each instance of a match.
> It doesn't make sense to try binding both `TrueExpression` and 
> `FalseExpression` literals to a single value.
Why? In all three cases, you don't care what matched, just that *some* case is 
matched. None of the logic in `check()` relies on which part of the expression 
is matched.


https://reviews.llvm.org/D23243



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Kirill Bobyrev via cfe-commits
omtcyfz added inline comments.


Comment at: clang-tidy/modernize/UseBoolLiteralsCheck.cpp:51-52
@@ -34,4 +50,4 @@
 void UseBoolLiteralsCheck::check(const MatchFinder::MatchResult ) {
-  const auto *Literal = Result.Nodes.getNodeAs("literal");
-  const auto *Cast = Result.Nodes.getNodeAs("cast");
-  bool LiteralBooleanValue = Literal->getValue().getBoolValue();
+  for (const auto  :
+   {"literal", "trueBranchLiteral", "falseBranchLiteral"}) {
+const auto *Literal = Result.Nodes.getNodeAs(BindingName);

aaron.ballman wrote:
> Any reason not to name the bind "literal" in all three cases? That eliminates 
> the need for the loop entirely, since `check()` will trigger for each 
> instance of a match.
It doesn't make sense to try binding both `TrueExpression` and 
`FalseExpression` literals to a single value.


https://reviews.llvm.org/D23243



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Aaron Ballman via cfe-commits
aaron.ballman added a comment.

Would it also make sense to support `BinaryConditionalOperator` as well as the 
ternary operator?



Comment at: clang-tidy/modernize/UseBoolLiteralsCheck.cpp:51-52
@@ -34,4 +50,4 @@
 void UseBoolLiteralsCheck::check(const MatchFinder::MatchResult ) {
-  const auto *Literal = Result.Nodes.getNodeAs("literal");
-  const auto *Cast = Result.Nodes.getNodeAs("cast");
-  bool LiteralBooleanValue = Literal->getValue().getBoolValue();
+  for (const auto  :
+   {"literal", "trueBranchLiteral", "falseBranchLiteral"}) {
+const auto *Literal = Result.Nodes.getNodeAs(BindingName);

Any reason not to name the bind "literal" in all three cases? That eliminates 
the need for the loop entirely, since `check()` will trigger for each instance 
of a match.


https://reviews.llvm.org/D23243



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Kirill Bobyrev via cfe-commits
omtcyfz marked 2 inline comments as done.
omtcyfz added a comment.

Thanks.

Yes, sure.


https://reviews.llvm.org/D23243



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Piotr Padlewski via cfe-commits
Prazek accepted this revision.
Prazek added a reviewer: Prazek.
Prazek added a comment.
This revision is now accepted and ready to land.

LGTM, but wait a day, maybe someone will have other comments.


https://reviews.llvm.org/D23243



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


Re: [PATCH] D22702: [libcxx]Missing default argument for flag_type parameter in one of std::basic_regex constructors

2016-08-07 Thread Hubert Tong via cfe-commits
hubert.reinterpretcast accepted this revision.
hubert.reinterpretcast added a comment.
This revision is now accepted and ready to land.

LGTM.


https://reviews.llvm.org/D22702



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


Re: [PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

2016-08-07 Thread Aaron Ballman via cfe-commits
aaron.ballman added inline comments.


Comment at: include/clang/Basic/Attr.td:1674
@@ +1673,3 @@
+   TargetSpecificAttr {
+  let Spellings = [GNU<"no_caller_saved_registers">];
+  let Subjects = SubjectList<[FunctionLike], WarnDiag, "ExpectedFunction">;

aaboud wrote:
> aaron.ballman wrote:
> > Yes, though interrupt should be handled in a separate patch since it's a 
> > logically separate change.
> How about using GCC Spelling instead of GNU and C++?
> 
> 1. These attributes are compatible with GCC.
> 2. This is what is said about GCC class:
> 
> ```
> // The GCC spelling implies GNU and CXX11<"gnu", name> and also
> // sets KnownToGCC to 1. This spelling should be used for any GCC-compatible
> // attributes.
> class GCC : Spelling {
>   let KnownToGCC = 1;
> }
> ```
The GCC spelling should only be used if the attribute is also supported by GCC, 
which this one is not. So the spelling should be 
`GNU<"no_caller_saved_registers">`, and `CXX11<"clang", 
"no_caller_saved_registers">`.


https://reviews.llvm.org/D22045



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


Re: [PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

2016-08-07 Thread Amjad Aboud via cfe-commits
aaboud marked an inline comment as not done.


Comment at: include/clang/Basic/Attr.td:1674
@@ +1673,3 @@
+   TargetSpecificAttr {
+  let Spellings = [GNU<"no_caller_saved_registers">];
+  let Subjects = SubjectList<[FunctionLike], WarnDiag, "ExpectedFunction">;

aaron.ballman wrote:
> Yes, though interrupt should be handled in a separate patch since it's a 
> logically separate change.
How about using GCC Spelling instead of GNU and C++?

1. These attributes are compatible with GCC.
2. This is what is said about GCC class:

```
// The GCC spelling implies GNU and CXX11<"gnu", name> and also
// sets KnownToGCC to 1. This spelling should be used for any GCC-compatible
// attributes.
class GCC : Spelling {
  let KnownToGCC = 1;
}
```


https://reviews.llvm.org/D22045



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


Re: [PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

2016-08-07 Thread Amjad Aboud via cfe-commits
aaboud marked 3 inline comments as done.
aaboud added a comment.

In https://reviews.llvm.org/D22045#506996, @joerg wrote:

> For what it is worth, this certainly seems to be misnamed. By nature, if it 
> doesn't preserve at least the stack pointer, there is no way to recover on 
> return, right?


I am not sure I understand what you mean!
When you  said "if it does not preserve the stack pointer", did you mean the 
"caller"?

Maybe it need more clarification on that, but stack pointer should be saved by 
the caller (via the call instruction), but even in this case the callee must 
preserve the stack pointer, right? otherwise the return will not work. So, from 
callee point of view it still cannot assume that any register is a scratch 
register and it need to preserve it before modifying.


https://reviews.llvm.org/D22045



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


Re: [PATCH] D22212: [X86][AVX512] Constants for integer comparison predicates

2016-08-07 Thread Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL277955: [AVX512] integer comparisions enumeration. (authored 
by abadouh).

Changed prior to commit:
  https://reviews.llvm.org/D22212?vs=63486=67097#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22212

Files:
  cfe/trunk/lib/Headers/avx512fintrin.h
  cfe/trunk/test/CodeGen/avx512f-builtins.c
  cfe/trunk/test/CodeGen/avx512vl-builtins.c

Index: cfe/trunk/lib/Headers/avx512fintrin.h
===
--- cfe/trunk/lib/Headers/avx512fintrin.h
+++ cfe/trunk/lib/Headers/avx512fintrin.h
@@ -54,6 +54,19 @@
 #define _MM_FROUND_TO_ZERO  0x03
 #define _MM_FROUND_CUR_DIRECTION0x04
 
+/* Constants for integer comparison predicates */
+typedef enum {
+_MM_CMPINT_EQ,  /* Equal */
+_MM_CMPINT_LT,  /* Less than */
+_MM_CMPINT_LE,  /* Less than or Equal */
+_MM_CMPINT_UNUSED,
+_MM_CMPINT_NE,  /* Not Equal */
+_MM_CMPINT_NLT, /* Not Less than */
+#define _MM_CMPINT_GE   _MM_CMPINT_NLT  /* Greater than or Equal */
+_MM_CMPINT_NLE  /* Not Less than or Equal */
+#define _MM_CMPINT_GT   _MM_CMPINT_NLE  /* Greater than */
+} _MM_CMPINT_ENUM;
+
 typedef enum
 {
   _MM_PERM_ = 0x00, _MM_PERM_AAAB = 0x01, _MM_PERM_AAAC = 0x02,
Index: cfe/trunk/test/CodeGen/avx512vl-builtins.c
===
--- cfe/trunk/test/CodeGen/avx512vl-builtins.c
+++ cfe/trunk/test/CodeGen/avx512vl-builtins.c
@@ -501,56 +501,56 @@
   return (__mmask8)_mm256_mask_cmpneq_epu64_mask(__u, __a, __b);
 }
 
-__mmask8 test_mm_cmp_epi32_mask(__m128i __a, __m128i __b) {
-  // CHECK-LABEL: @test_mm_cmp_epi32_mask
+__mmask8 test_mm_cmp_eq_epi32_mask(__m128i __a, __m128i __b) {
+  // CHECK-LABEL: @test_mm_cmp_eq_epi32_mask
   // CHECK: icmp eq <4 x i32> %{{.*}}, %{{.*}}
-  return (__mmask8)_mm_cmp_epi32_mask(__a, __b, 0);
+  return (__mmask8)_mm_cmp_epi32_mask(__a, __b, _MM_CMPINT_EQ);
 }
 
-__mmask8 test_mm_mask_cmp_epi32_mask(__mmask8 __u, __m128i __a, __m128i __b) {
-  // CHECK-LABEL: @test_mm_mask_cmp_epi32_mask
-  // CHECK: icmp eq <4 x i32> %{{.*}}, %{{.*}}
+__mmask8 test_mm_mask_cmp_lt_epi32_mask(__mmask8 __u, __m128i __a, __m128i __b) {
+  // CHECK-LABEL: @test_mm_mask_cmp_lt_epi32_mask
+  // CHECK: icmp slt <4 x i32> %{{.*}}, %{{.*}}
   // CHECK: and <4 x i1> %{{.*}}, %{{.*}}
-  return (__mmask8)_mm_mask_cmp_epi32_mask(__u, __a, __b, 0);
+  return (__mmask8)_mm_mask_cmp_epi32_mask(__u, __a, __b, _MM_CMPINT_LT);
 }
 
-__mmask8 test_mm_cmp_epi64_mask(__m128i __a, __m128i __b) {
-  // CHECK-LABEL: @test_mm_cmp_epi64_mask
-  // CHECK: icmp eq <2 x i64> %{{.*}}, %{{.*}}
-  return (__mmask8)_mm_cmp_epi64_mask(__a, __b, 0);
+__mmask8 test_mm_cmp_lt_epi64_mask(__m128i __a, __m128i __b) {
+  // CHECK-LABEL: @test_mm_cmp_lt_epi64_mask
+  // CHECK: icmp slt <2 x i64> %{{.*}}, %{{.*}}
+  return (__mmask8)_mm_cmp_epi64_mask(__a, __b, _MM_CMPINT_LT);
 }
 
-__mmask8 test_mm_mask_cmp_epi64_mask(__mmask8 __u, __m128i __a, __m128i __b) {
-  // CHECK-LABEL: @test_mm_mask_cmp_epi64_mask
+__mmask8 test_mm_mask_cmp_eq_epi64_mask(__mmask8 __u, __m128i __a, __m128i __b) {
+  // CHECK-LABEL: @test_mm_mask_cmp_eq_epi64_mask
   // CHECK: icmp eq <2 x i64> %{{.*}}, %{{.*}}
   // CHECK: and <2 x i1> %{{.*}}, %{{.*}}
-  return (__mmask8)_mm_mask_cmp_epi64_mask(__u, __a, __b, 0);
+  return (__mmask8)_mm_mask_cmp_epi64_mask(__u, __a, __b, _MM_CMPINT_EQ);
 }
 
-__mmask8 test_mm256_cmp_epi32_mask(__m256i __a, __m256i __b) {
-  // CHECK-LABEL: @test_mm256_cmp_epi32_mask
+__mmask8 test_mm256_cmp_eq_epi32_mask(__m256i __a, __m256i __b) {
+  // CHECK-LABEL: @test_mm256_cmp_eq_epi32_mask
   // CHECK: icmp eq <8 x i32> %{{.*}}, %{{.*}}
-  return (__mmask8)_mm256_cmp_epi32_mask(__a, __b, 0);
+  return (__mmask8)_mm256_cmp_epi32_mask(__a, __b, _MM_CMPINT_EQ);
 }
 
-__mmask8 test_mm256_mask_cmp_epi32_mask(__mmask8 __u, __m256i __a, __m256i __b) {
-  // CHECK-LABEL: @test_mm256_mask_cmp_epi32_mask
-  // CHECK: icmp eq <8 x i32> %{{.*}}, %{{.*}}
+__mmask8 test_mm256_mask_cmp_le_epi32_mask(__mmask8 __u, __m256i __a, __m256i __b) {
+  // CHECK-LABEL: @test_mm256_mask_cmp_le_epi32_mask
+  // CHECK: icmp sle <8 x i32> %{{.*}}, %{{.*}}
   // CHECK: and <8 x i1> %{{.*}}, %{{.*}}
-  return (__mmask8)_mm256_mask_cmp_epi32_mask(__u, __a, __b, 0);
+  return (__mmask8)_mm256_mask_cmp_epi32_mask(__u, __a, __b, _MM_CMPINT_LE);
 }
 
-__mmask8 test_mm256_cmp_epi64_mask(__m256i __a, __m256i __b) {
-  // CHECK-LABEL: @test_mm256_cmp_epi64_mask
+__mmask8 test_mm256_cmp_eq_epi64_mask(__m256i __a, __m256i __b) {
+  // CHECK-LABEL: @test_mm256_cmp_eq_epi64_mask
   // CHECK: icmp eq <4 x i64> %{{.*}}, %{{.*}}
-  return (__mmask8)_mm256_cmp_epi64_mask(__a, __b, 0);
+  return (__mmask8)_mm256_cmp_epi64_mask(__a, __b, _MM_CMPINT_EQ);
 }
 
-__mmask8 test_mm256_mask_cmp_epi64_mask(__mmask8 __u, __m256i __a, __m256i __b) {
-  // CHECK-LABEL: 

r277955 - [AVX512] integer comparisions enumeration.

2016-08-07 Thread Asaf Badouh via cfe-commits
Author: abadouh
Date: Sun Aug  7 05:43:04 2016
New Revision: 277955

URL: http://llvm.org/viewvc/llvm-project?rev=277955=rev
Log:
[AVX512] integer comparisions enumeration.

fix Bug 28842 https://llvm.org/bugs/show_bug.cgi?id=28842

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

 

Modified:
cfe/trunk/lib/Headers/avx512fintrin.h
cfe/trunk/test/CodeGen/avx512f-builtins.c
cfe/trunk/test/CodeGen/avx512vl-builtins.c

Modified: cfe/trunk/lib/Headers/avx512fintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512fintrin.h?rev=277955=277954=277955=diff
==
--- cfe/trunk/lib/Headers/avx512fintrin.h (original)
+++ cfe/trunk/lib/Headers/avx512fintrin.h Sun Aug  7 05:43:04 2016
@@ -54,6 +54,19 @@ typedef unsigned short __mmask16;
 #define _MM_FROUND_TO_ZERO  0x03
 #define _MM_FROUND_CUR_DIRECTION0x04
 
+/* Constants for integer comparison predicates */
+typedef enum {
+_MM_CMPINT_EQ,  /* Equal */
+_MM_CMPINT_LT,  /* Less than */
+_MM_CMPINT_LE,  /* Less than or Equal */
+_MM_CMPINT_UNUSED,
+_MM_CMPINT_NE,  /* Not Equal */
+_MM_CMPINT_NLT, /* Not Less than */
+#define _MM_CMPINT_GE   _MM_CMPINT_NLT  /* Greater than or Equal */
+_MM_CMPINT_NLE  /* Not Less than or Equal */
+#define _MM_CMPINT_GT   _MM_CMPINT_NLE  /* Greater than */
+} _MM_CMPINT_ENUM;
+
 typedef enum
 {
   _MM_PERM_ = 0x00, _MM_PERM_AAAB = 0x01, _MM_PERM_AAAC = 0x02,

Modified: cfe/trunk/test/CodeGen/avx512f-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx512f-builtins.c?rev=277955=277954=277955=diff
==
--- cfe/trunk/test/CodeGen/avx512f-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx512f-builtins.c Sun Aug  7 05:43:04 2016
@@ -1342,30 +1342,30 @@ __mmask8 test_mm512_mask_cmpneq_epu64_ma
   return (__mmask8)_mm512_mask_cmpneq_epu64_mask(__u, __a, __b);
 }
 
-__mmask16 test_mm512_cmp_epi32_mask(__m512i __a, __m512i __b) {
-  // CHECK-LABEL: @test_mm512_cmp_epi32_mask
+__mmask16 test_mm512_cmp_eq_epi32_mask(__m512i __a, __m512i __b) {
+  // CHECK-LABEL: @test_mm512_cmp_eq_epi32_mask
   // CHECK: icmp eq <16 x i32> %{{.*}}, %{{.*}}
-  return (__mmask16)_mm512_cmp_epi32_mask(__a, __b, 0);
+  return (__mmask16)_mm512_cmp_epi32_mask(__a, __b, _MM_CMPINT_EQ);
 }
 
-__mmask16 test_mm512_mask_cmp_epi32_mask(__mmask16 __u, __m512i __a, __m512i 
__b) {
-  // CHECK-LABEL: @test_mm512_mask_cmp_epi32_mask
+__mmask16 test_mm512_mask_cmp_eq_epi32_mask(__mmask16 __u, __m512i __a, 
__m512i __b) {
+  // CHECK-LABEL: @test_mm512_mask_cmp_eq_epi32_mask
   // CHECK: icmp eq <16 x i32> %{{.*}}, %{{.*}}
   // CHECK: and <16 x i1> %{{.*}}, %{{.*}}
-  return (__mmask16)_mm512_mask_cmp_epi32_mask(__u, __a, __b, 0);
+  return (__mmask16)_mm512_mask_cmp_epi32_mask(__u, __a, __b, _MM_CMPINT_EQ);
 }
 
-__mmask8 test_mm512_cmp_epi64_mask(__m512i __a, __m512i __b) {
-  // CHECK-LABEL: @test_mm512_cmp_epi64_mask
+__mmask8 test_mm512_cmp_eq_epi64_mask(__m512i __a, __m512i __b) {
+  // CHECK-LABEL: @test_mm512_cmp_eq_epi64_mask
   // CHECK: icmp eq <8 x i64> %{{.*}}, %{{.*}}
-  return (__mmask8)_mm512_cmp_epi64_mask(__a, __b, 0);
+  return (__mmask8)_mm512_cmp_epi64_mask(__a, __b, _MM_CMPINT_EQ);
 }
 
-__mmask8 test_mm512_mask_cmp_epi64_mask(__mmask8 __u, __m512i __a, __m512i 
__b) {
-  // CHECK-LABEL: @test_mm512_mask_cmp_epi64_mask
+__mmask8 test_mm512_mask_cmp_eq_epi64_mask(__mmask8 __u, __m512i __a, __m512i 
__b) {
+  // CHECK-LABEL: @test_mm512_mask_cmp_eq_epi64_mask
   // CHECK: icmp eq <8 x i64> %{{.*}}, %{{.*}}
   // CHECK: and <8 x i1> %{{.*}}, %{{.*}}
-  return (__mmask8)_mm512_mask_cmp_epi64_mask(__u, __a, __b, 0);
+  return (__mmask8)_mm512_mask_cmp_epi64_mask(__u, __a, __b, _MM_CMPINT_EQ);
 }
 
 __mmask16 test_mm512_cmp_epu32_mask(__m512i __a, __m512i __b) {

Modified: cfe/trunk/test/CodeGen/avx512vl-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx512vl-builtins.c?rev=277955=277954=277955=diff
==
--- cfe/trunk/test/CodeGen/avx512vl-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx512vl-builtins.c Sun Aug  7 05:43:04 2016
@@ -501,56 +501,56 @@ __mmask8 test_mm256_mask_cmpneq_epu64_ma
   return (__mmask8)_mm256_mask_cmpneq_epu64_mask(__u, __a, __b);
 }
 
-__mmask8 test_mm_cmp_epi32_mask(__m128i __a, __m128i __b) {
-  // CHECK-LABEL: @test_mm_cmp_epi32_mask
+__mmask8 test_mm_cmp_eq_epi32_mask(__m128i __a, __m128i __b) {
+  // CHECK-LABEL: @test_mm_cmp_eq_epi32_mask
   // CHECK: icmp eq <4 x i32> %{{.*}}, %{{.*}}
-  return (__mmask8)_mm_cmp_epi32_mask(__a, __b, 0);
+  return (__mmask8)_mm_cmp_epi32_mask(__a, __b, _MM_CMPINT_EQ);
 }
 
-__mmask8 test_mm_mask_cmp_epi32_mask(__mmask8 __u, __m128i __a, __m128i __b) {
-  // CHECK-LABEL: @test_mm_mask_cmp_epi32_mask
-  // CHECK: icmp 

Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Kirill Bobyrev via cfe-commits
omtcyfz marked 2 inline comments as done.


Comment at: clang-tidy/modernize/UseBoolLiteralsCheck.cpp:38-43
@@ +37,8 @@
+  unless(isInTemplateInstantiation(,
+  anyOf(hasTrueExpression(ignoringParenImpCasts(
+integerLiteral().bind("trueBranchLiteral"))),
+anything()),
+  anyOf(hasFalseExpression(ignoringParenImpCasts(
+integerLiteral().bind("falseBranchLiteral"))),
+anything())),
+  this);

Prazek wrote:
> Do I understand it correctly, that you have to have this 2 anyOf matchers, 
> because if you would have it in one then because anyOf is lazy, it would not 
> bind to the second branch?
> 
> I think it would be good to write some comment about it, because on the first 
> sight it looks like it could be simplified.
> Do I understand it correctly, that you have to have this 2 anyOf matchers, 
> because if you would have it in one then because anyOf is lazy, it would not 
> bind to the second branch?

Yes, exactly. In order to bind both I do `anyOf()`.

> I think it would be good to write some comment about it, because on the first 
> sight it looks like it could be simplified.

Done.


Comment at: test/clang-tidy/modernize-use-bool-literals.cpp:119
@@ -118,1 +118,3 @@
 }
+
+static int Value = 1;

Prazek wrote:
> Please add a test with only one branch with constant, and none of them.
> Also one test like
> bool Result = Value == 1 ? true : 0;
> or
> bool Result = Value == 1 ? false : bool(0);
Added a bunch of new tests.


https://reviews.llvm.org/D23243



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


Re: [PATCH] D23243: [clang-tidy] enhance modernize-use-bool-literals to check ternary operator

2016-08-07 Thread Kirill Bobyrev via cfe-commits
omtcyfz removed rL LLVM as the repository for this revision.
omtcyfz updated this revision to Diff 67095.
omtcyfz added a comment.

Comment `anyOf()` part in check's matcher and extend testset.


https://reviews.llvm.org/D23243

Files:
  clang-tidy/modernize/UseBoolLiteralsCheck.cpp
  test/clang-tidy/modernize-use-bool-literals.cpp

Index: test/clang-tidy/modernize-use-bool-literals.cpp
===
--- test/clang-tidy/modernize-use-bool-literals.cpp
+++ test/clang-tidy/modernize-use-bool-literals.cpp
@@ -116,3 +116,33 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: {{.*}}
   // CHECK-FIXES: {{^ *}}IntToTrue = true;{{$}}
 }
+
+static int Value = 1;
+
+bool Function1() {
+  bool Result = Value == 1 ? 1 : 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:30: {{.*}}
+  // CHECK-MESSAGES: :[[@LINE-2]]:34: {{.*}}
+  // CHECK-FIXES: {{^ *}}bool Result = Value == 1 ? true : false;{{$}}
+  return Result;
+}
+
+bool Function2() {
+  return Value == 1 ? 1 : 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: {{.*}}
+  // CHECK-MESSAGES: :[[@LINE-2]]:27: {{.*}}
+  // CHECK-FIXES: {{^ *}}return Value == 1 ? true : false;{{$}}
+}
+
+void foo() {
+  bool Result;
+  Result = Value == 1 ? true : 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:32: {{.*}}
+  // CHECK-FIXES: {{^ *}}Result = Value == 1 ? true : false;{{$}}
+  Result = Value == 1 ? false : bool(0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: {{.*}}
+  // CHECK-FIXES: {{^ *}}Result = Value == 1 ? false : false;{{$}}
+  Result = Value == 1 ? (bool)0 : false;
+  // CHECK-MESSAGES: :[[@LINE-1]]:25: {{.*}}
+  // CHECK-FIXES: {{^ *}}Result = Value == 1 ? false : false;{{$}}
+}
Index: clang-tidy/modernize/UseBoolLiteralsCheck.cpp
===
--- clang-tidy/modernize/UseBoolLiteralsCheck.cpp
+++ clang-tidy/modernize/UseBoolLiteralsCheck.cpp
@@ -29,25 +29,46 @@
   unless(isInTemplateInstantiation()),
   anyOf(hasParent(explicitCastExpr().bind("cast")), anything())),
   this);
+
+  Finder->addMatcher(
+  conditionalOperator(
+  hasParent(implicitCastExpr(
+  hasImplicitDestinationType(qualType(booleanType())),
+  unless(isInTemplateInstantiation(,
+  // anyOf() is not evaluating second argument if first is evaluated as
+  // 'true'. We'd like to bind both literals if they are presents. Thus,
+  // using anyOf(BINDLITERAL(), anything()).
+  anyOf(hasTrueExpression(ignoringParenImpCasts(
+integerLiteral().bind("trueBranchLiteral"))),
+anything()),
+  anyOf(hasFalseExpression(ignoringParenImpCasts(
+integerLiteral().bind("falseBranchLiteral"))),
+anything())),
+  this);
 }
 
 void UseBoolLiteralsCheck::check(const MatchFinder::MatchResult ) {
-  const auto *Literal = Result.Nodes.getNodeAs("literal");
-  const auto *Cast = Result.Nodes.getNodeAs("cast");
-  bool LiteralBooleanValue = Literal->getValue().getBoolValue();
+  for (const auto  :
+   {"literal", "trueBranchLiteral", "falseBranchLiteral"}) {
+const auto *Literal = Result.Nodes.getNodeAs(BindingName);
+if (!Literal)
+  continue;
+const auto *Cast = Result.Nodes.getNodeAs("cast");
+bool LiteralBooleanValue = Literal->getValue().getBoolValue();
 
-  if (Literal->isInstantiationDependent())
-return;
+if (Literal->isInstantiationDependent())
+  continue;
 
-  const Expr *Expression = Cast ? Cast : Literal;
+const Expr *Expression = Cast ? Cast : Literal;
 
-  auto Diag =
-  diag(Expression->getExprLoc(),
-   "converting integer literal to bool, use bool literal instead");
+auto Diag =
+diag(Expression->getExprLoc(),
+ "converting integer literal to bool, use bool literal instead");
 
-  if (!Expression->getLocStart().isMacroID())
-Diag << FixItHint::CreateReplacement(
-Expression->getSourceRange(), LiteralBooleanValue ? "true" : "false");
+if (!Expression->getLocStart().isMacroID())
+  Diag << FixItHint::CreateReplacement(
+  Expression->getSourceRange(), LiteralBooleanValue ? "true" : "false");
+  }
 }
 
 } // namespace modernize
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r277953 - Update clang tests for LLVM r277950

2016-08-07 Thread David Majnemer via cfe-commits
Author: majnemer
Date: Sun Aug  7 03:28:58 2016
New Revision: 277953

URL: http://llvm.org/viewvc/llvm-project?rev=277953=rev
Log:
Update clang tests for LLVM r277950

We infer inbounds on GEPs of allocas leading to minor perturbations in
tests.

Modified:
cfe/trunk/test/CodeGenObjCXX/exceptions-legacy.mm

Modified: cfe/trunk/test/CodeGenObjCXX/exceptions-legacy.mm
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjCXX/exceptions-legacy.mm?rev=277953=277952=277953=diff
==
--- cfe/trunk/test/CodeGenObjCXX/exceptions-legacy.mm (original)
+++ cfe/trunk/test/CodeGenObjCXX/exceptions-legacy.mm Sun Aug  7 03:28:58 2016
@@ -16,7 +16,7 @@ void test0(id obj) {
 //   Enter the @synchronized block.
 // CHECK:  call i32 @objc_sync_enter(i8* [[OBJ:%.*]])
 // CHECK:  call void @objc_exception_try_enter([[BUF_T:%.*]]* nonnull 
[[BUF:%.*]])
-// CHECK-NEXT: [[T0:%.*]] = getelementptr [[BUF_T]], [[BUF_T]]* [[BUF]], i32 
0, i32 0, i32 0
+// CHECK-NEXT: [[T0:%.*]] = getelementptr inbounds [[BUF_T]], [[BUF_T]]* 
[[BUF]], i32 0, i32 0, i32 0
 // CHECK-NEXT: [[T1:%.*]] = call i32 @_setjmp(i32* [[T0]])
 // CHECK-NEXT: [[T2:%.*]] = icmp eq i32 [[T1]], 0
 // CHECK-NEXT: br i1 [[T2]],
@@ -55,7 +55,7 @@ void test1(id obj, bool *failed) {
 // CHECK-LABEL:define void @_Z5test1P11objc_objectPb(
 //   Enter the @try block.
 // CHECK:  call void @objc_exception_try_enter([[BUF_T]]* nonnull 
[[BUF:%.*]])
-// CHECK-NEXT: [[T0:%.*]] = getelementptr [[BUF_T]], [[BUF_T]]* [[BUF]], i32 
0, i32 0, i32 0
+// CHECK-NEXT: [[T0:%.*]] = getelementptr inbounds [[BUF_T]], [[BUF_T]]* 
[[BUF]], i32 0, i32 0, i32 0
 // CHECK-NEXT: [[T1:%.*]] = call i32 @_setjmp(i32* [[T0]])
 // CHECK-NEXT: [[T2:%.*]] = icmp eq i32 [[T1]], 0
 // CHECK-NEXT: br i1 [[T2]],


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


Re: [PATCH] D22212: [X86][AVX512] Constants for integer comparison predicates

2016-08-07 Thread Elena Demikhovsky via cfe-commits
delena accepted this revision.
This revision is now accepted and ready to land.


Comment at: ../tunkClang/tools/clang/test/CodeGen/avx512vl-builtins.c:504
@@ -503,3 +503,3 @@
 
 __mmask8 test_mm_cmp_epi32_mask(__m128i __a, __m128i __b) {
   // CHECK-LABEL: @test_mm_cmp_epi32_mask

Please change test name for each case.


Repository:
  rL LLVM

https://reviews.llvm.org/D22212



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