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

2017-12-16 Thread Anton via Phabricator via cfe-commits 
xgsa marked 3 inline comments as done.
xgsa added inline comments.



Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:339
 std::unique_ptr OptionsProvider)
 : DiagEngine(nullptr), OptionsProvider(std::move(OptionsProvider)),
+  Profile(nullptr),

Eugene.Zelenko wrote:
> Please use default members initialization for DiagEngine and Profile.
Actually, it is not necessary, as unique_ptr is initialized with nullptr by 
default. I have just removed initializing them here.


https://reviews.llvm.org/D41326



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

[PATCH] D41217: [Concepts] Concept Specialization Expressions

2017-12-16 Thread Faisal Vali via Phabricator via cfe-commits 
faisalv added inline comments.



Comment at: lib/Parse/ParseExpr.cpp:223
 ExprResult Parser::ParseConstraintExpression() {
-  // FIXME: this may erroneously consume a function-body as the braced
-  // initializer list of a compound literal
-  //
-  // FIXME: this may erroneously consume a parenthesized rvalue reference
-  // declarator as a parenthesized address-of-label expression
-  ExprResult LHS(ParseCastExpression(/*isUnaryExpression=*/false));
-  ExprResult Res(ParseRHSOfBinaryExpression(LHS, prec::LogicalOr));
-
+  ExprResult Res(ParseExpression());
+  if (Res.isUsable() && !Actions.CheckConstraintExpression(Res.get())) {

Are you sure this only accepts logical-or-epxressions? Unlike Hubert's initial 
implementation here, this seems to parse any expression (i.e including 
unparenthesized commas and assignments)? What am I missing?



Repository:
  rC Clang

https://reviews.llvm.org/D41217



___
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

2017-12-16 Thread Eugene Zelenko via Phabricator via cfe-commits 
Eugene.Zelenko added inline comments.



Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:169
+  }
+private:
+  SmallVector CheckNames;

Please separate with empty line.



Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:170
+private:
+  SmallVector CheckNames;
+  size_t NolintIndex = 0;

Please include header for SmallVector.h.



Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:339
 std::unique_ptr OptionsProvider)
 : DiagEngine(nullptr), OptionsProvider(std::move(OptionsProvider)),
+  Profile(nullptr),

Please use default members initialization for DiagEngine and Profile.


https://reviews.llvm.org/D41326



___
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

2017-12-16 Thread Anton via Phabricator via cfe-commits 
xgsa updated this revision to Diff 127260.
xgsa added a comment.

A few minor coding style fixes.


https://reviews.llvm.org/D41326

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

Index: test/clang-tidy/nolintnextline.cpp
===
--- test/clang-tidy/nolintnextline.cpp
+++ test/clang-tidy/nolintnextline.cpp
@@ -24,6 +24,18 @@
 class C5 { C5(int i); };
 
 
+void f() {
+  int i;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: unused variable 'i' [clang-diagnostic-unused-variable]
+  // NOLINTNEXTLINE
+  int j;
+  // NOLINTNEXTLINE(clang-diagnostic-unused-variable)
+  int k;
+  // NOLINTNEXTLINE(clang-diagnostic-literal-conversion)
+  int l;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: unused variable 'l' [clang-diagnostic-unused-variable]
+}
+
 // NOLINTNEXTLINE
 
 class D { D(int i); };
@@ -44,6 +56,6 @@
 // NOLINTNEXTLINE
 MACRO_NOARG
 
-// CHECK-MESSAGES: Suppressed 8 warnings (8 NOLINT)
+// CHECK-MESSAGES: Suppressed 10 warnings (10 NOLINT)
 
-// RUN: %check_clang_tidy %s google-explicit-constructor %t --
+// RUN: %check_clang_tidy %s google-explicit-constructor,clang-diagnostic-unused-variable %t -- -extra-arg=-Wunused-variable --
Index: test/clang-tidy/nolint.cpp
===
--- test/clang-tidy/nolint.cpp
+++ test/clang-tidy/nolint.cpp
@@ -30,6 +30,9 @@
   int i;
 // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: unused variable 'i' [clang-diagnostic-unused-variable]
   int j; // NOLINT
+  int k; // NOLINT(clang-diagnostic-unused-variable)
+  int l; // NOLINT(clang-diagnostic-literal-conversion)
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: unused variable 'l' [clang-diagnostic-unused-variable]
 }
 
 #define MACRO(X) class X { X(int i); };
@@ -46,4 +49,4 @@
 #define DOUBLE_MACRO MACRO(H) // NOLINT
 DOUBLE_MACRO
 
-// CHECK-MESSAGES: Suppressed 12 warnings (12 NOLINT)
+// CHECK-MESSAGES: Suppressed 13 warnings (13 NOLINT)
Index: test/clang-tidy/nolint-usage.cpp
===
--- /dev/null
+++ test/clang-tidy/nolint-usage.cpp
@@ -0,0 +1,171 @@
+// RUN: %check_clang_tidy %s 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 is no diagnostics on this line, the NOLINT comment is redundant
+
+// 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 is no diagnostics for the 'misc-unused-parameters' check on this line, the NOLINT comment is redundant
+
+// 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 is no diagnostics for the 'google-explicit-constructor' check on this line, the NOLINT comment is redundant
+
+// 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' is specified for 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' is specified for NOLINT comment
+
+// Case: NO_LINT with not closed parenthesis without check names.
+class A8 { A8(int i); }; // NOLINT(
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: NOLINT comment has an opening parenthesis and no closing one, so all the diagnostics will be silenced for the 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: NOLINT comment has an opening parenthesis and no closing one, so all the diagnostics will be silenced for the line
+
+// Case: NO_LINT with clang diagnostics
+int f() {
+  int i = 0; // NOLINT
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: there is no diagnostics on this line, the NOLINT comment is redundant
+  int j = 0; // NOLINT(clang-diagnostic-unused-variable)
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: there is no diagnostics for the

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

2017-12-16 Thread Anton via Phabricator via cfe-commits 
xgsa created this revision.
xgsa added reviewers: aaron.ballman, alexfh.
xgsa added a project: clang-tools-extra.
Herald added subscribers: cfe-commits, xazax.hun.

As discussed in the previous review [1], diagnostics about incorrect usage of 
NOLINT comment was added, i.e..:

- usage of NOLINT with unknown check name;
- usage of NOLINT for line, where there is no diagnostics;
- usage of NOLINT without closing parenthesis.

I have covered the implementation with tests, but I haven't updated the 
documentation yet, because I'd like to approve the implemented approach in 
general. If nobody insists, I'd prefer updating the documentation in follow-up 
patches, because this will make the patch even bigger and the review longer.

[1] - https://reviews.llvm.org/D40671


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-usage.cpp
  test/clang-tidy/nolint.cpp
  test/clang-tidy/nolintnextline.cpp

Index: test/clang-tidy/nolintnextline.cpp
===
--- test/clang-tidy/nolintnextline.cpp
+++ test/clang-tidy/nolintnextline.cpp
@@ -24,6 +24,18 @@
 class C5 { C5(int i); };
 
 
+void f() {
+  int i;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: unused variable 'i' [clang-diagnostic-unused-variable]
+  // NOLINTNEXTLINE
+  int j;
+  // NOLINTNEXTLINE(clang-diagnostic-unused-variable)
+  int k;
+  // NOLINTNEXTLINE(clang-diagnostic-literal-conversion)
+  int l;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: unused variable 'l' [clang-diagnostic-unused-variable]
+}
+
 // NOLINTNEXTLINE
 
 class D { D(int i); };
@@ -44,6 +56,6 @@
 // NOLINTNEXTLINE
 MACRO_NOARG
 
-// CHECK-MESSAGES: Suppressed 8 warnings (8 NOLINT)
+// CHECK-MESSAGES: Suppressed 10 warnings (10 NOLINT)
 
-// RUN: %check_clang_tidy %s google-explicit-constructor %t --
+// RUN: %check_clang_tidy %s google-explicit-constructor,clang-diagnostic-unused-variable %t -- -extra-arg=-Wunused-variable --
Index: test/clang-tidy/nolint.cpp
===
--- test/clang-tidy/nolint.cpp
+++ test/clang-tidy/nolint.cpp
@@ -30,6 +30,9 @@
   int i;
 // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: unused variable 'i' [clang-diagnostic-unused-variable]
   int j; // NOLINT
+  int k; // NOLINT(clang-diagnostic-unused-variable)
+  int l; // NOLINT(clang-diagnostic-literal-conversion)
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: unused variable 'l' [clang-diagnostic-unused-variable]
 }
 
 #define MACRO(X) class X { X(int i); };
@@ -46,4 +49,4 @@
 #define DOUBLE_MACRO MACRO(H) // NOLINT
 DOUBLE_MACRO
 
-// CHECK-MESSAGES: Suppressed 12 warnings (12 NOLINT)
+// CHECK-MESSAGES: Suppressed 13 warnings (13 NOLINT)
Index: test/clang-tidy/nolint-usage.cpp
===
--- /dev/null
+++ test/clang-tidy/nolint-usage.cpp
@@ -0,0 +1,171 @@
+// RUN: %check_clang_tidy %s 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 is no diagnostics on this line, the NOLINT comment is redundant
+
+// 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 is no diagnostics for the 'misc-unused-parameters' check on this line, the NOLINT comment is redundant
+
+// 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 is no diagnostics for the 'google-explicit-constructor' check on this line, the NOLINT comment is redundant
+
+// 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' is specified for 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' is specified for NOLINT comment
+
+// Case: NO_LINT with not closed parenthesis without check names.
+class A8 { A8(int i); }; // NOLINT(
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: NOLINT comment has an

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

2017-12-16 Thread Brian Cain via Phabricator via cfe-commits 
bcain added a comment.

In https://reviews.llvm.org/D41316#957598, @jroelofs wrote:

> I'd much rather provide no implementation than one that lies. Broken builds 
> are much safer than problems at runtime.


Agreed!  Especially the problems caused by a predictable random seed.


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] r320925 - [libcxx] Add WebAssembly support

2017-12-16 Thread Sam Clegg via cfe-commits 
Author: sbc
Date: Sat Dec 16 10:59:50 2017
New Revision: 320925

URL: http://llvm.org/viewvc/llvm-project?rev=320925=rev
Log:
[libcxx] Add WebAssembly support

It turns out that this is the only change required in libcxx
for it to compile with the new `wasm32-unknown-unknown-wasm`
target recently added to Clang.

Patch by Nicholas Wilson!

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

Modified:
libcxx/trunk/include/__config
libcxx/trunk/src/include/config_elast.h

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=320925=320924=320925=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Sat Dec 16 10:59:50 2017
@@ -45,6 +45,8 @@
 #define _LIBCPP_OBJECT_FORMAT_MACHO 1
 #elif defined(_WIN32)
 #define _LIBCPP_OBJECT_FORMAT_COFF  1
+#elif defined(__wasm__)
+#define _LIBCPP_OBJECT_FORMAT_WASM  1
 #else
 #error Unknown object file format
 #endif

Modified: libcxx/trunk/src/include/config_elast.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/include/config_elast.h?rev=320925=320924=320925=diff
==
--- libcxx/trunk/src/include/config_elast.h (original)
+++ libcxx/trunk/src/include/config_elast.h Sat Dec 16 10:59:50 2017
@@ -24,7 +24,7 @@
 #define _LIBCPP_ELAST __ELASTERROR
 #elif defined(__Fuchsia__)
 // No _LIBCPP_ELAST needed on Fuchsia
-#elif defined(__linux__)
+#elif defined(__linux__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 #define _LIBCPP_ELAST 4095
 #elif defined(__APPLE__)
 // No _LIBCPP_ELAST needed on Apple


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

[PATCH] D41073: Wasm: add support in libcxx

2017-12-16 Thread Phabricator via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL320925: [libcxx] Add WebAssembly support (authored by sbc, 
committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D41073?vs=127242=127251#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D41073

Files:
  libcxx/trunk/include/__config
  libcxx/trunk/src/include/config_elast.h


Index: libcxx/trunk/src/include/config_elast.h
===
--- libcxx/trunk/src/include/config_elast.h
+++ libcxx/trunk/src/include/config_elast.h
@@ -24,7 +24,7 @@
 #define _LIBCPP_ELAST __ELASTERROR
 #elif defined(__Fuchsia__)
 // No _LIBCPP_ELAST needed on Fuchsia
-#elif defined(__linux__)
+#elif defined(__linux__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 #define _LIBCPP_ELAST 4095
 #elif defined(__APPLE__)
 // No _LIBCPP_ELAST needed on Apple
Index: libcxx/trunk/include/__config
===
--- libcxx/trunk/include/__config
+++ libcxx/trunk/include/__config
@@ -45,6 +45,8 @@
 #define _LIBCPP_OBJECT_FORMAT_MACHO 1
 #elif defined(_WIN32)
 #define _LIBCPP_OBJECT_FORMAT_COFF  1
+#elif defined(__wasm__)
+#define _LIBCPP_OBJECT_FORMAT_WASM  1
 #else
 #error Unknown object file format
 #endif


Index: libcxx/trunk/src/include/config_elast.h
===
--- libcxx/trunk/src/include/config_elast.h
+++ libcxx/trunk/src/include/config_elast.h
@@ -24,7 +24,7 @@
 #define _LIBCPP_ELAST __ELASTERROR
 #elif defined(__Fuchsia__)
 // No _LIBCPP_ELAST needed on Fuchsia
-#elif defined(__linux__)
+#elif defined(__linux__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 #define _LIBCPP_ELAST 4095
 #elif defined(__APPLE__)
 // No _LIBCPP_ELAST needed on Apple
Index: libcxx/trunk/include/__config
===
--- libcxx/trunk/include/__config
+++ libcxx/trunk/include/__config
@@ -45,6 +45,8 @@
 #define _LIBCPP_OBJECT_FORMAT_MACHO 1
 #elif defined(_WIN32)
 #define _LIBCPP_OBJECT_FORMAT_COFF  1
+#elif defined(__wasm__)
+#define _LIBCPP_OBJECT_FORMAT_WASM  1
 #else
 #error Unknown object file format
 #endif
___
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

2017-12-16 Thread Weiming Zhao via Phabricator via cfe-commits 
weimingz added a comment.

Does it make sense to provide an implementation based on C99 rand?
like 
#ifdef _LIBCPP_USING_C99_RANDOM

  srand(0), 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

[PATCH] D40937: [clang-tidy] Infinite loop checker

2017-12-16 Thread Gábor Horváth via Phabricator via cfe-commits 
xazax.hun added a comment.

I think, while the analyzer is more suitable for certain kinds of checks that 
require deep analysis, it is still useful to have quicker syntactic checks that 
can easily identify problems that are the results of typos or incorrectly 
modified copy and pasted code. I think this check is in that category.  Also, 
the original warning Peter mentioned does something similar but has some 
shortcomings.

The current implementation is not path sensitive. It uses flow sensitivity to 
check for escaping values.
If we would try to port this check to the static analyzer, the questions we 
would ask from the analyzer are universally quantified (e.g. for all path this 
variable does not escape and does not change). Unfortunately, it is not that 
easy with the current analyzer to answer such questions. The static analyzer is 
better with existential questions (e.g. there is a path such that the condition 
variables are not escaped and are unchanged in the loop). Using the latter 
formulation we might have a larger number of false positives because the 
analyzer sometimes hit infeasible paths.  In the first approach, the infeasible 
paths are less of a problem (they might cause false negatives but not false 
positives), but we need to be careful with all the peculiarities of the 
analyzer because it does not guarantee to discover all possible paths.

Hopefully, Devin will correct me if I'm wrong :)


https://reviews.llvm.org/D40937



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

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

2017-12-16 Thread Gábor Horváth via Phabricator via cfe-commits 
xazax.hun added a comment.

Just to be sure, this is just a refactoring to make this cleaner or you expect 
this to have other effects as well, like better performance?


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] D40560: [analyzer] WIP: Get construction into `operator new` running in simple cases.

2017-12-16 Thread Gábor Horváth via Phabricator via cfe-commits 
xazax.hun added a comment.

In https://reviews.llvm.org/D40560#947514, @NoQ wrote:

> Replaced the live expression hack with a slightly better approach. It doesn't 
> update the live variables analysis to take `CFGNewAllocator` into account, 
> but at least tests now pass.
>
> In order to keep the return value produced by the `operator new()` call 
> around until `CXXNewExpr` is evaluated, i added a program state trait, 
> `CXXNewAllocatorValueStack`:
>
> 1. Upon evaluating `CFGNewAllocator`, the return `SVal` of the evaluated 
> allocator call is put here;
> 2. Upon evaluating `CXXConstructExpr`, that return value is retrieved from 
> here;
> 3. Upon evaluating `CXXNewExpr`, the return value is retrieved from here 
> again and then wiped.
>
>   In order to support nested allocator calls, this state trait is organized 
> as a stack/FIFO, with push in `CFGNewAllocator` and pop in `CXXNewExpr`. The 
> `llvm::ImmutableList` thing offers some asserts for warning us when we popped 
> more times than we pushed; we might want to add more asserts here to detect 
> other mismatches, but i don't see a need for implementing this as an 
> environment-like map from (`Expr`, `LocationContext`) to SVal.


I think it would be great to have tests for such cases to make it apparent it 
is not trivial to do this only based on the cfg.
Maybe something like:

  A *a = new A(new B, coin ? new C : new D, inlinedCallWithMoreAllocs()); 

Or in case it turns out to be an easy problem to match these from CFG, I prefer 
avoiding the state.

Also having a new expression within an overloaded operator new might be 
interesting.

> Why `SVal` and not `MemRegion`? Because i believe that ideally we want to 
> produce constructor calls with null or undefined `this`-arguments. 
> Constructors into null pointers should be skipped - this is how `operator 
> new(std::nothrow)` works, for instance. Constructors into garbage pointers 
> should be immediately caught by the checkers (to throw a warning and generate 
> a sink), but we still need to produce them so that the checkers could catch 
> them. But for now `CXXConstructorCall` has room only for one pointer, which 
> is currently `const MemRegion *`, so this still remains to be tackled.

Are you sure we need to produce undef vals? Couldn't a checker subscribe to the 
post allocator call and check for the undefined value and generate a sink 
before the constructor call? I am not opposed to using SVals there, just 
curious.

> Also we need to make sure that not only the expression lives, but also its 
> value lives, with all the various traits attached to it. Hence the new 
> facility in `ExprEngine::removeDead()` to mark the values in 
> `CXXNewAllocatorValueStack` as live. Test included in `new-ctor-inlined.cpp` 
> (the one with `s != 0`) covers this situation.
> 
> Some doxygen comments updated.




https://reviews.llvm.org/D40560



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

[PATCH] D41250: [analyzer] Model implied cast around operator new().

2017-12-16 Thread Gábor Horváth via Phabricator via cfe-commits 
xazax.hun accepted this revision.
xazax.hun added a comment.
This revision is now accepted and ready to land.

The code looks good to me. But the best way to verify these kinds of changes to 
see how the results change on large projects after applying the patch.


https://reviews.llvm.org/D41250



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

[PATCH] D41266: [analyzer] With c++-allocator-inlining, fix memory space for operator new pointers.

2017-12-16 Thread Gábor Horváth via Phabricator via cfe-commits 
xazax.hun accepted this revision.
xazax.hun added a comment.
This revision is now accepted and ready to land.

In the future, we might want to model the standard placement new and return a 
symbol with the correct SpaceRegion (i.e.: the space region of the argument).




Comment at: lib/StaticAnalyzer/Core/ExprEngineCXX.cpp:491
+  // Placement forms are considered non-standard.
+  return (FD->getNumParams() == 1);
+}

The parens are redundant here.


Repository:
  rC Clang

https://reviews.llvm.org/D41266



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

[PATCH] D39812: [Driver, CodeGen] pass through and apply -fassociative-math

2017-12-16 Thread Sanjay Patel via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL320920: [Driver, CodeGen] pass through and apply 
-fassociative-math (authored by spatel, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D39812?vs=122158=127245#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D39812

Files:
  cfe/trunk/include/clang/Driver/CC1Options.td
  cfe/trunk/include/clang/Frontend/CodeGenOptions.def
  cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
  cfe/trunk/lib/Driver/ToolChains/Clang.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/CodeGen/finite-math.c
  cfe/trunk/test/Driver/fast-math.c

Index: cfe/trunk/include/clang/Driver/CC1Options.td
===
--- cfe/trunk/include/clang/Driver/CC1Options.td
+++ cfe/trunk/include/clang/Driver/CC1Options.td
@@ -263,6 +263,8 @@
 def menable_unsafe_fp_math : Flag<["-"], "menable-unsafe-fp-math">,
   HelpText<"Allow unsafe floating-point math optimizations which may decrease "
"precision">;
+def mreassociate : Flag<["-"], "mreassociate">,
+  HelpText<"Allow reassociation transformations for floating-point instructions">;
 def mfloat_abi : Separate<["-"], "mfloat-abi">,
   HelpText<"The float ABI to use">;
 def mtp : Separate<["-"], "mtp">,
Index: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
===
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def
@@ -117,6 +117,7 @@
 CODEGENOPT(NoImplicitFloat   , 1, 0) ///< Set when -mno-implicit-float is enabled.
 CODEGENOPT(NoInfsFPMath  , 1, 0) ///< Assume FP arguments, results not +-Inf.
 CODEGENOPT(NoSignedZeros , 1, 0) ///< Allow ignoring the signedness of FP zero
+CODEGENOPT(Reassociate   , 1, 0) ///< Allow reassociation of FP math ops
 CODEGENOPT(ReciprocalMath, 1, 0) ///< Allow FP divisions to be reassociated.
 CODEGENOPT(NoTrappingMath, 1, 0) ///< Set when -fno-trapping-math is enabled.
 CODEGENOPT(NoNaNsFPMath  , 1, 0) ///< Assume FP arguments, results not NaN.
Index: cfe/trunk/test/Driver/fast-math.c
===
--- cfe/trunk/test/Driver/fast-math.c
+++ cfe/trunk/test/Driver/fast-math.c
@@ -121,18 +121,23 @@
 // RUN:   | FileCheck --check-prefix=CHECK-UNSAFE-MATH %s
 // CHECK-UNSAFE-MATH: "-cc1"
 // CHECK-UNSAFE-MATH: "-menable-unsafe-fp-math"
+// CHECK-UNSAFE-MATH: "-mreassociate"
 //
 // RUN: %clang -### -fno-fast-math -fno-math-errno -fassociative-math -freciprocal-math \
 // RUN: -fno-signed-zeros -fno-trapping-math -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-NO-FAST-MATH-UNSAFE-MATH %s
 // CHECK-NO-FAST-MATH-UNSAFE-MATH: "-cc1"
 // CHECK-NO-FAST-MATH-UNSAFE-MATH: "-menable-unsafe-fp-math"
-//
+// CHECK-NO-FAST-MATH-UNSAFE-MATH: "-mreassociate"
+
+// The 2nd -fno-fast-math overrides -fassociative-math.
+
 // RUN: %clang -### -fno-fast-math -fno-math-errno -fassociative-math -freciprocal-math \
 // RUN: -fno-fast-math -fno-signed-zeros -fno-trapping-math -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-UNSAFE-MATH-NO-FAST-MATH %s
 // CHECK-UNSAFE-MATH-NO-FAST-MATH: "-cc1"
 // CHECK-UNSAFE-MATH-NO-FAST-MATH-NOT: "-menable-unsafe-fp-math"
+// CHECK-UNSAFE-MATH-NO-FAST-MATH-NOT: "-mreassociate"
 //
 // Check that various umbrella flags also enable these frontend options.
 // RUN: %clang -### -ffast-math -c %s 2>&1 \
@@ -151,7 +156,7 @@
 // One umbrella flag is *really* weird and also changes the semantics of the
 // program by adding a special preprocessor macro. Check that the frontend flag
 // modeling this semantic change is provided. Also check that the flag is not
-// present if any of the optimization is disabled.
+// present if any of the optimizations are disabled.
 // RUN: %clang -### -ffast-math -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-FAST-MATH %s
 // RUN: %clang -### -fno-fast-math -ffast-math -c %s 2>&1 \
@@ -175,8 +180,11 @@
 // RUN:   | FileCheck --check-prefix=CHECK-NO-FAST-MATH %s
 // RUN: %clang -### -ffast-math -fmath-errno -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-NO-FAST-MATH %s
+// RUN: %clang -### -ffast-math -fno-associative-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-NO-FAST-MATH --check-prefix=CHECK-ASSOC-MATH %s
 // CHECK-NO-FAST-MATH: "-cc1"
 // CHECK-NO-FAST-MATH-NOT: "-ffast-math"
+// CHECK-ASSOC-MATH-NOT: "-mreassociate"
 //
 // Check various means of disabling these flags, including disabling them after
 // they've been enabled via an umbrella flag.
@@ -209,21 +217,16 @@
 // CHECK-NO-NO-NANS-NOT: "-menable-no-nans"
 // CHECK-NO-NO-NANS-NOT: "-ffinite-math-only"
 // CHECK-NO-NO-NANS: "-o"
-//
+
+// A later inverted option overrides an earlier option.
+
 // RUN: %clang -### -fassociative-math -freciprocal-math -fno-signed-zeros \
 // RUN: -fno-trapping-math -fno-associative-math

r320920 - [Driver, CodeGen] pass through and apply -fassociative-math

2017-12-16 Thread Sanjay Patel via cfe-commits 
Author: spatel
Date: Sat Dec 16 08:11:17 2017
New Revision: 320920

URL: http://llvm.org/viewvc/llvm-project?rev=320920=rev
Log:
[Driver, CodeGen] pass through and apply -fassociative-math

There are 2 parts to getting the -fassociative-math command-line flag 
translated to LLVM FMF:

1. In the driver/frontend, we accept the flag and its 'no' inverse and deal 
with the 
   interactions with other flags like -ffast-math -fno-signed-zeros 
-fno-trapping-math. 
   This was mostly already done - we just need to translate the flag as a 
codegen option. 
   The test file is complicated because there are many potential combinations 
of flags here.
   Note that we are matching gcc's behavior that requires 'nsz' and 
no-trapping-math.

2. In codegen, we map the codegen option to FMF in the IR builder. This is 
simple code and 
   corresponding test.

For the motivating example from PR27372:

float foo(float a, float x) { return ((a + x) - x); }

$ ./clang -O2 27372.c -S -o - -ffast-math  -fno-associative-math -emit-llvm  | 
egrep 'fadd|fsub'
  %add = fadd nnan ninf nsz arcp contract float %0, %1
  %sub = fsub nnan ninf nsz arcp contract float %add, %2

So 'reassoc' is off as expected (and so is the new 'afn' but that's a different 
patch). 
This case now works as expected end-to-end although the underlying logic is 
still wrong:

$ ./clang  -O2 27372.c -S -o - -ffast-math  -fno-associative-math | grep xmm
addss   %xmm1, %xmm0
subss   %xmm1, %xmm0

We're not done because the case where 'reassoc' is set is ignored by optimizer 
passes. Example:

$ ./clang  -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros 
-fno-trapping-math -emit-llvm  | grep fadd
  %add = fadd reassoc float %0, %1

$ ./clang -O2  27372.c -S -o - -fassociative-math -fno-signed-zeros 
-fno-trapping-math | grep xmm
addss   %xmm1, %xmm0
subss   %xmm1, %xmm0

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

Modified:
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/CodeGen/finite-math.c
cfe/trunk/test/Driver/fast-math.c

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=320920=320919=320920=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Sat Dec 16 08:11:17 2017
@@ -263,6 +263,8 @@ def menable_no_nans : Flag<["-"], "menab
 def menable_unsafe_fp_math : Flag<["-"], "menable-unsafe-fp-math">,
   HelpText<"Allow unsafe floating-point math optimizations which may decrease "
"precision">;
+def mreassociate : Flag<["-"], "mreassociate">,
+  HelpText<"Allow reassociation transformations for floating-point 
instructions">;
 def mfloat_abi : Separate<["-"], "mfloat-abi">,
   HelpText<"The float ABI to use">;
 def mtp : Separate<["-"], "mtp">,

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=320920=320919=320920=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Sat Dec 16 08:11:17 2017
@@ -117,6 +117,7 @@ CODEGENOPT(EnableSegmentedStacks , 1, 0)
 CODEGENOPT(NoImplicitFloat   , 1, 0) ///< Set when -mno-implicit-float is 
enabled.
 CODEGENOPT(NoInfsFPMath  , 1, 0) ///< Assume FP arguments, results not 
+-Inf.
 CODEGENOPT(NoSignedZeros , 1, 0) ///< Allow ignoring the signedness of FP 
zero
+CODEGENOPT(Reassociate   , 1, 0) ///< Allow reassociation of FP math ops
 CODEGENOPT(ReciprocalMath, 1, 0) ///< Allow FP divisions to be 
reassociated.
 CODEGENOPT(NoTrappingMath, 1, 0) ///< Set when -fno-trapping-math is 
enabled.
 CODEGENOPT(NoNaNsFPMath  , 1, 0) ///< Assume FP arguments, results not NaN.

Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.cpp?rev=320920=320919=320920=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenFunction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenFunction.cpp Sat Dec 16 08:11:17 2017
@@ -103,6 +103,9 @@ CodeGenFunction::CodeGenFunction(CodeGen
   if (CGM.getCodeGenOpts().ReciprocalMath) {
 FMF.setAllowReciprocal();
   }
+  if (CGM.getCodeGenOpts().Reassociate) {
+FMF.setAllowReassoc();
+  }
   Builder.setFastMathFlags(FMF);
 }
 

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL:

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

2017-12-16 Thread Jonathan Roelofs via Phabricator via cfe-commits 
jroelofs added a comment.

I say that because there are contexts where it is **absolutely critical** that 
https://xkcd.com/221/ not be the implementation of an RNG.


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

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

2017-12-16 Thread Jonathan Roelofs via Phabricator via cfe-commits 
jroelofs added a comment.

I'd much rather provide no implementation than one that lies. Broken builds are 
much safer than problems at runtime.


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

[PATCH] D41306: [clangd] Update documentation page with new features, instructions

2017-12-16 Thread Jan Korous via Phabricator via cfe-commits 
jkorous-apple accepted this revision.
jkorous-apple added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D41306



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

[PATCH] D41073: Wasm: add support in libcxx

2017-12-16 Thread Nicholas Wilson via Phabricator via cfe-commits 
ncw updated this revision to Diff 127242.
ncw added a comment.
Herald added a subscriber: krytarowski.

Although Dan has already reviewed, I've sneakily added in another change here 
to help compilation against Musl.

Musl is Linux-only, or rather, provides the linux ABI. For Wasm, `__linux` 
isn't defined but if we're using Musl then we can provide ELAST and get rid of 
the associated warnings. Musl is definitely wedded to the 4096 errno limit 
that's part of the Linux ABI, so I believe this change is safe.


Repository:
  rCXX libc++

https://reviews.llvm.org/D41073

Files:
  include/__config
  src/include/config_elast.h


Index: src/include/config_elast.h
===
--- src/include/config_elast.h
+++ src/include/config_elast.h
@@ -24,7 +24,7 @@
 #define _LIBCPP_ELAST __ELASTERROR
 #elif defined(__Fuchsia__)
 // No _LIBCPP_ELAST needed on Fuchsia
-#elif defined(__linux__)
+#elif defined(__linux__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 #define _LIBCPP_ELAST 4095
 #elif defined(__APPLE__)
 // No _LIBCPP_ELAST needed on Apple
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -45,6 +45,8 @@
 #define _LIBCPP_OBJECT_FORMAT_MACHO 1
 #elif defined(_WIN32)
 #define _LIBCPP_OBJECT_FORMAT_COFF  1
+#elif defined(__wasm__)
+#define _LIBCPP_OBJECT_FORMAT_WASM  1
 #else
 #error Unknown object file format
 #endif


Index: src/include/config_elast.h
===
--- src/include/config_elast.h
+++ src/include/config_elast.h
@@ -24,7 +24,7 @@
 #define _LIBCPP_ELAST __ELASTERROR
 #elif defined(__Fuchsia__)
 // No _LIBCPP_ELAST needed on Fuchsia
-#elif defined(__linux__)
+#elif defined(__linux__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 #define _LIBCPP_ELAST 4095
 #elif defined(__APPLE__)
 // No _LIBCPP_ELAST needed on Apple
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -45,6 +45,8 @@
 #define _LIBCPP_OBJECT_FORMAT_MACHO 1
 #elif defined(_WIN32)
 #define _LIBCPP_OBJECT_FORMAT_COFF  1
+#elif defined(__wasm__)
+#define _LIBCPP_OBJECT_FORMAT_WASM  1
 #else
 #error Unknown object file format
 #endif
___
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

2017-12-16 Thread Arthur O'Dwyer via Phabricator via cfe-commits 
Quuxplusone added a comment.

I keep seeing patches go by for other targets where they're just implementing 
`random_device` for their target. It doesn't *have* to be based on an actual 
/dev/urandom. You can see all the other options under #ifdefs in this file: 
getentropy, /dev/random, nacl_secure_random, arc4random, rand_s,... If you're 
on a target that doesn't have any of these, then IMO the appropriate patch 
would be one of

- #ifdef _LIBCPP_USING_YOURPLATFORM_RANDOM
- #ifdef _LIBCPP_USING_ALWAYSZERO_RANDOM

where the latter provides a "random_device" that yields nothing but zeroes. 
That would still be very slightly better than providing a non-conforming 
implementation. (And notice that the useless `double random_device::entropy()` 
method will for the first time return a *mathematically correct* value for the 
always-zero random_device! ;))


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

[PATCH] D41308: [analyser] different.BitwiseOpBoolArg checker implementation

2017-12-16 Thread Jonas Toth via Phabricator via cfe-commits 
JonasToth added a comment.

That check is similar to 'hicpp-signed-bitwise' in clang-tidy. Maybe it could 
live there and extend it?


Repository:
  rC Clang

https://reviews.llvm.org/D41308



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

r320919 - [X86] Implement kand/kandn/kor/kxor/kxnor/knot intrinsics using native IR.

2017-12-16 Thread Craig Topper via cfe-commits 
Author: ctopper
Date: Sat Dec 16 00:26:22 2017
New Revision: 320919

URL: http://llvm.org/viewvc/llvm-project?rev=320919=rev
Log:
[X86] Implement kand/kandn/kor/kxor/kxnor/knot intrinsics using native IR.

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/avx512f-builtins.c

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=320919=320918=320919=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Sat Dec 16 00:26:22 2017
@@ -7564,6 +7564,19 @@ static Value *EmitX86MaskedLoad(CodeGenF
   return CGF.Builder.CreateMaskedLoad(Ops[0], Align, MaskVec, Ops[1]);
 }
 
+static Value *EmitX86MaskLogic(CodeGenFunction , Instruction::BinaryOps 
Opc,
+  unsigned NumElts, SmallVectorImpl ,
+  bool InvertLHS = false) {
+  Value *LHS = getMaskVecValue(CGF, Ops[0], NumElts);
+  Value *RHS = getMaskVecValue(CGF, Ops[1], NumElts);
+
+  if (InvertLHS)
+LHS = CGF.Builder.CreateNot(LHS);
+
+  return CGF.Builder.CreateBitCast(CGF.Builder.CreateBinOp(Opc, LHS, RHS),
+  CGF.Builder.getIntNTy(std::max(NumElts, 
8U)));
+}
+
 static Value *EmitX86SubVectorBroadcast(CodeGenFunction ,
 SmallVectorImpl ,
 llvm::Type *DstTy,
@@ -8217,6 +8230,22 @@ Value *CodeGenFunction::EmitX86BuiltinEx
 return EmitX86MaskedCompare(*this, CC, false, Ops);
   }
 
+  case X86::BI__builtin_ia32_kandhi:
+return EmitX86MaskLogic(*this, Instruction::And, 16, Ops);
+  case X86::BI__builtin_ia32_kandnhi:
+return EmitX86MaskLogic(*this, Instruction::And, 16, Ops, true);
+  case X86::BI__builtin_ia32_korhi:
+return EmitX86MaskLogic(*this, Instruction::Or, 16, Ops);
+  case X86::BI__builtin_ia32_kxnorhi:
+return EmitX86MaskLogic(*this, Instruction::Xor, 16, Ops, true);
+  case X86::BI__builtin_ia32_kxorhi:
+return EmitX86MaskLogic(*this, Instruction::Xor, 16, Ops);
+  case X86::BI__builtin_ia32_knothi: {
+Ops[0] = getMaskVecValue(*this, Ops[0], 16);
+return Builder.CreateBitCast(Builder.CreateNot(Ops[0]),
+ Builder.getInt16Ty());
+  }
+
   case X86::BI__builtin_ia32_vplzcntd_128_mask:
   case X86::BI__builtin_ia32_vplzcntd_256_mask:
   case X86::BI__builtin_ia32_vplzcntd_512_mask:

Modified: cfe/trunk/test/CodeGen/avx512f-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx512f-builtins.c?rev=320919=320918=320919=diff
==
--- cfe/trunk/test/CodeGen/avx512f-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx512f-builtins.c Sat Dec 16 00:26:22 2017
@@ -385,7 +385,9 @@ __m512d test_mm512_set1_pd(double d)
 __mmask16 test_mm512_knot(__mmask16 a)
 {
   // CHECK-LABEL: @test_mm512_knot
-  // CHECK: @llvm.x86.avx512.knot.w
+  // CHECK: [[IN:%.*]] = bitcast i16 %1 to <16 x i1>
+  // CHECK: [[NOT:%.*]] = xor <16 x i1> [[IN]], 
+  // CHECK: bitcast <16 x i1> [[NOT]] to i16
   return _mm512_knot(a);
 }
 
@@ -6211,22 +6213,38 @@ __m512i test_mm512_mask_permutexvar_epi3
   return _mm512_mask_permutexvar_epi32(__W, __M, __X, __Y); 
 }
 
-__mmask16 test_mm512_kand(__mmask16 __A, __mmask16 __B) {
+__mmask16 test_mm512_kand(__m512i __A, __m512i __B, __m512i __C, __m512i __D, 
__m512i __E, __m512i __F) {
   // CHECK-LABEL: @test_mm512_kand
-  // CHECK: @llvm.x86.avx512.kand.w
-  return _mm512_kand(__A, __B); 
+  // CHECK: [[LHS:%.*]] = bitcast i16 %{{.*}} to <16 x i1>
+  // CHECK: [[RHS:%.*]] = bitcast i16 %{{.*}} to <16 x i1>
+  // CHECK: [[RES:%.*]] = and <16 x i1> [[LHS]], [[RHS]]
+  // CHECK: bitcast <16 x i1> [[RES]] to i16
+  return 
_mm512_mask_cmpneq_epu32_mask(_mm512_kand(_mm512_cmpneq_epu32_mask(__A, __B),
+   
_mm512_cmpneq_epu32_mask(__C, __D)),
+   __E, __F);
 }
 
-__mmask16 test_mm512_kandn(__mmask16 __A, __mmask16 __B) {
+__mmask16 test_mm512_kandn(__m512i __A, __m512i __B, __m512i __C, __m512i __D, 
__m512i __E, __m512i __F) {
   // CHECK-LABEL: @test_mm512_kandn
-  // CHECK: @llvm.x86.avx512.kandn.w
-  return _mm512_kandn(__A, __B); 
+  // CHECK: [[LHS:%.*]] = bitcast i16 %{{.*}} to <16 x i1>
+  // CHECK: [[RHS:%.*]] = bitcast i16 %{{.*}} to <16 x i1>
+  // CHECK: [[NOT:%.*]] = xor <16 x i1> [[LHS]], 
+  // CHECK: [[RES:%.*]] = and <16 x i1> [[NOT]], [[RHS]]
+  // CHECK: bitcast <16 x i1> [[RES]] to i16
+  return 
_mm512_mask_cmpneq_epu32_mask(_mm512_kandn(_mm512_cmpneq_epu32_mask(__A, __B),
+
_mm512_cmpneq_epu32_mask(__C, __D)),
+__E, __F);
 }
 
-__mmask16 test_mm512_kor(__mmask16 __A, __mmask16 __B) {
+__mmask16