[PATCH] D77502: [clang][CodeGen] Handle throw expression in conditional operator constant folding

2020-04-05 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: clang/lib/CodeGen/CGExpr.cpp:4337
+EmitCXXThrowExpr(ThrowExpr);
+return EmitLValue(dead);
+  }

The IR we emit for the dead operand is unreachable; it's a bit wasteful to 
generate it here and (hopefully!) leave it to the optimizer to remove it again. 
Perhaps we could produce an `undef` lvalue instead? See 
`CodeGenFunction::EmitUnsupportedLValue` for an example of how to build such a 
value.



Comment at: clang/test/CodeGenCXX/throw-expressions.cpp:84-87
+  void conditional_throw() {
+int a, b;
+(true ? throw 0 : a) = 0;
+  }

Please add some `CHECK`s in here to make sure we actually emit a call to 
`__cxa_throw`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77502/new/

https://reviews.llvm.org/D77502



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


[PATCH] D77484: [Vector] Pass VectLib to LTO backend so TLI build correct vector function list

2020-04-05 Thread Rui Ueyama via Phabricator via cfe-commits
ruiu added inline comments.



Comment at: lld/ELF/Config.h:132
   callGraphProfile;
+  llvm::TargetLibraryInfoImpl::VectorLibrary VectLib;
   bool allowMultipleDefinition;

We name variables after their corresponding command line flags, so this should 
be `ltoVectorLibrary`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77484/new/

https://reviews.llvm.org/D77484



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


[PATCH] D71227: [cuda][hip] Fix function overload resolution in the global initiailizer.

2020-04-05 Thread Michael Liao via Phabricator via cfe-commits
hliao updated this revision to Diff 255219.
hliao added a comment.

Rebase to the latest trunk.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71227/new/

https://reviews.llvm.org/D71227

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Sema/SemaCUDA.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCUDA/function-overload.cu
  clang/test/SemaCUDA/global-initializers-host.cu
  clang/test/SemaCUDA/hip-pinned-shadow.cu

Index: clang/test/SemaCUDA/hip-pinned-shadow.cu
===
--- clang/test/SemaCUDA/hip-pinned-shadow.cu
+++ clang/test/SemaCUDA/hip-pinned-shadow.cu
@@ -13,13 +13,19 @@
 
 template 
 struct texture : public textureReference {
-texture() { a = 1; }
+  // expected-note@-1{{candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided}}
+  // expected-note@-2{{candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided}}
+  // expected-note@-3{{candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 0 were provided}}
+  // expected-note@-4{{candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 0 were provided}}
+  texture() { a = 1; }
+  // expected-note@-1{{candidate constructor not viable: call to __host__ function from __device__ function}}
+  // expected-note@-2{{candidate constructor not viable: call to __host__ function from __device__ function}}
 };
 
 __hip_pinned_shadow__ texture tex;
-__device__ __hip_pinned_shadow__ texture tex2; // expected-error{{'hip_pinned_shadow' and 'device' attributes are not compatible}}
-// expected-error@-1{{dynamic initialization is not supported for __device__, __constant__, and __shared__ variables}}
-// expected-note@-2{{conflicting attribute is here}}
+__device__ __hip_pinned_shadow__ texture tex2;   // expected-error{{'hip_pinned_shadow' and 'device' attributes are not compatible}}
+  // expected-note@-1{{conflicting attribute is here}}
+  // expected-error@-2{{no matching constructor for initialization of 'texture'}}
 __constant__ __hip_pinned_shadow__ texture tex3; // expected-error{{'hip_pinned_shadow' and 'constant' attributes are not compatible}}
-  // expected-error@-1{{dynamic initialization is not supported for __device__, __constant__, and __shared__ variables}}
-  // expected-note@-2{{conflicting attribute is here}}
+  // expected-note@-1{{conflicting attribute is here}}
+  // expected-error@-2{{no matching constructor for initialization of 'texture'}}
Index: clang/test/SemaCUDA/global-initializers-host.cu
===
--- clang/test/SemaCUDA/global-initializers-host.cu
+++ clang/test/SemaCUDA/global-initializers-host.cu
@@ -6,12 +6,14 @@
 // module initializer.
 
 struct S {
+  // expected-note@-1 {{candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided}}
+  // expected-note@-2 {{candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 0 were provided}}
   __device__ S() {}
-  // expected-note@-1 {{'S' declared here}}
+  // expected-note@-1 {{candidate constructor not viable: call to __device__ function from __host__ function}}
 };
 
 S s;
-// expected-error@-1 {{reference to __device__ function 'S' in global initializer}}
+// expected-error@-1 {{no matching constructor for initialization of 'S'}}
 
 struct T {
   __host__ __device__ T() {}
@@ -19,14 +21,17 @@
 T t;  // No error, this is OK.
 
 struct U {
+  // expected-note@-1 {{candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const U' for 1st argument}}
+  // expected-note@-2 {{candidate constructor (the implicit move constructor) not viable: no known conversion from 'int' to 'U' for 1st argument}}
   __host__ U() {}
+  // expected-note@-1 {{candidate constructor not viable: requires 0 arguments, but 1 was provided}}
   __device__ U(int) {}
-  // expected-note@-1 {{'U' declared here}}
+  // expected-note@-1 {{candidate constructor not viable: call to __device__ function from __host__ function}}
 };
 U u(42);
-// expected-error@-1 {{reference to __device__ function 'U' in global initializer}}
+// expected-error@-1 {{no matching constructor for initialization of 

[PATCH] D77113: [OpenMP][NFC] Move and simplify directive -> allowed clause mapping

2020-04-05 Thread Johannes Doerfert via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG931c0cd713ee: [OpenMP][NFC] Move and simplify directive 
- allowed clause mapping (authored by jdoerfert).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77113/new/

https://reviews.llvm.org/D77113

Files:
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/include/clang/Basic/OpenMPKinds.def
  clang/include/clang/Basic/OpenMPKinds.h
  clang/lib/ASTMatchers/Dynamic/CMakeLists.txt
  clang/lib/Basic/OpenMPKinds.cpp
  clang/lib/Tooling/CMakeLists.txt
  clang/lib/Tooling/Transformer/CMakeLists.txt
  clang/unittests/AST/CMakeLists.txt
  clang/unittests/ASTMatchers/CMakeLists.txt
  clang/unittests/ASTMatchers/Dynamic/CMakeLists.txt
  clang/unittests/Analysis/CMakeLists.txt
  clang/unittests/Rename/CMakeLists.txt
  clang/unittests/Sema/CMakeLists.txt
  clang/unittests/StaticAnalyzer/CMakeLists.txt
  clang/unittests/Tooling/CMakeLists.txt
  llvm/include/llvm/Frontend/OpenMP/OMPConstants.h
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Frontend/OpenMP/OMPConstants.cpp

Index: llvm/lib/Frontend/OpenMP/OMPConstants.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPConstants.cpp
+++ llvm/lib/Frontend/OpenMP/OMPConstants.cpp
@@ -54,6 +54,17 @@
   llvm_unreachable("Invalid OpenMP clause kind");
 }
 
+bool llvm::omp::isAllowedClauseForDirective(Directive D, Clause C,
+unsigned Version) {
+  assert(unsigned(D) <= unsigned(OMPD_unknown));
+  assert(unsigned(C) <= unsigned(OMPC_unknown));
+#define OMP_DIRECTIVE_CLAUSE(Dir, MinVersion, MaxVersion, Cl)  \
+  if (D == Dir && C == Cl && MinVersion <= Version && MaxVersion >= Version)   \
+return true;
+#include "llvm/Frontend/OpenMP/OMPKinds.def"
+  return false;
+}
+
 /// Declarations for LLVM-IR types (simple, array, function and structure) are
 /// generated below. Their names are defined and used in OpenMPKinds.def. Here
 /// we provide the declarations, the initializeTypes function will provide the
Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -710,3 +710,732 @@
 #undef __OMP_REQUIRES_TRAIT
 #undef OMP_REQUIRES_TRAIT
 ///}
+
+
+/// Clauses allowed per directive
+///
+///{
+
+#ifndef OMP_DIRECTIVE_CLAUSE
+#define OMP_DIRECTIVE_CLAUSE(Directive, MinVersion, MaxVersion, Clause)
+#endif
+
+#define __OMP_DIRECTIVE_CLAUSE(Directive, MinVersion, MaxVersion, Clause)  \
+  OMP_DIRECTIVE_CLAUSE(OMPD_##Directive, unsigned(MinVersion), \
+   unsigned(MaxVersion), OMPC_##Clause)
+
+__OMP_DIRECTIVE_CLAUSE(scan, 50, ~0, inclusive)
+__OMP_DIRECTIVE_CLAUSE(scan, 50, ~0, exclusive)
+
+__OMP_DIRECTIVE_CLAUSE(parallel, 1, ~0, if)
+__OMP_DIRECTIVE_CLAUSE(parallel, 1, ~0, num_threads)
+__OMP_DIRECTIVE_CLAUSE(parallel, 1, ~0, default)
+__OMP_DIRECTIVE_CLAUSE(parallel, 1, ~0, proc_bind)
+__OMP_DIRECTIVE_CLAUSE(parallel, 1, ~0, private)
+__OMP_DIRECTIVE_CLAUSE(parallel, 1, ~0, firstprivate)
+__OMP_DIRECTIVE_CLAUSE(parallel, 1, ~0, shared)
+__OMP_DIRECTIVE_CLAUSE(parallel, 1, ~0, reduction)
+__OMP_DIRECTIVE_CLAUSE(parallel, 1, ~0, copyin)
+__OMP_DIRECTIVE_CLAUSE(parallel, 1, ~0, allocate)
+
+__OMP_DIRECTIVE_CLAUSE(simd, 1, ~0, private)
+__OMP_DIRECTIVE_CLAUSE(simd, 1, ~0, lastprivate)
+__OMP_DIRECTIVE_CLAUSE(simd, 1, ~0, linear)
+__OMP_DIRECTIVE_CLAUSE(simd, 1, ~0, aligned)
+__OMP_DIRECTIVE_CLAUSE(simd, 1, ~0, safelen)
+__OMP_DIRECTIVE_CLAUSE(simd, 1, ~0, simdlen)
+__OMP_DIRECTIVE_CLAUSE(simd, 1, ~0, collapse)
+__OMP_DIRECTIVE_CLAUSE(simd, 1, ~0, reduction)
+__OMP_DIRECTIVE_CLAUSE(simd, 1, ~0, allocate)
+__OMP_DIRECTIVE_CLAUSE(simd, 50, ~0, if)
+__OMP_DIRECTIVE_CLAUSE(simd, 50, ~0, nontemporal)
+__OMP_DIRECTIVE_CLAUSE(simd, 50, ~0, order)
+
+__OMP_DIRECTIVE_CLAUSE(for, 1, ~0, private)
+__OMP_DIRECTIVE_CLAUSE(for, 1, ~0, lastprivate)
+__OMP_DIRECTIVE_CLAUSE(for, 1, ~0, firstprivate)
+__OMP_DIRECTIVE_CLAUSE(for, 1, ~0, reduction)
+__OMP_DIRECTIVE_CLAUSE(for, 1, ~0, collapse)
+__OMP_DIRECTIVE_CLAUSE(for, 1, ~0, schedule)
+__OMP_DIRECTIVE_CLAUSE(for, 1, ~0, ordered)
+__OMP_DIRECTIVE_CLAUSE(for, 1, ~0, nowait)
+__OMP_DIRECTIVE_CLAUSE(for, 1, ~0, linear)
+__OMP_DIRECTIVE_CLAUSE(for, 1, ~0, allocate)
+__OMP_DIRECTIVE_CLAUSE(for, 50, ~0, order)
+
+__OMP_DIRECTIVE_CLAUSE(for_simd, 1, ~0, private)
+__OMP_DIRECTIVE_CLAUSE(for_simd, 1, ~0, firstprivate)
+__OMP_DIRECTIVE_CLAUSE(for_simd, 1, ~0, lastprivate)
+__OMP_DIRECTIVE_CLAUSE(for_simd, 1, ~0, reduction)
+__OMP_DIRECTIVE_CLAUSE(for_simd, 1, ~0, schedule)
+__OMP_DIRECTIVE_CLAUSE(for_simd, 1, ~0, collapse)
+__OMP_DIRECTIVE_CLAUSE(for_simd, 1, ~0, nowait)
+__OMP_DIRECTIVE_CLAUSE(for_simd, 1, ~0, safelen)
+__OMP_DIRECTIVE_CLAUSE(for_simd, 1, ~0, simdlen)

[PATCH] D77112: [OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP`

2020-04-05 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D77112#1962936 , @thakis wrote:

> Broke clang-tools-extra again: 
> http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/46759/steps/build%20stage%201/logs/stdio


Fixed in 8ea07f62a6f06bdb7da981425227995423867a4d 
, I might 
have grabbed the wrong commit locally, apologies.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77112/new/

https://reviews.llvm.org/D77112



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


[PATCH] D77520: Treat default values in LangOptions.def in the scope of enums

2020-04-05 Thread Serge Pavlov via Phabricator via cfe-commits
sepavloff created this revision.
sepavloff added reviewers: rjmccall, rnk, arsenm.
Herald added a subscriber: wdng.
Herald added a project: clang.

If an option specified in LangOptions.def is of enum type, its default
value should be a member of that enum, so scope qualifier may always
be added in such cases. It allows to omit the scope qualifiers from
'LangOptions.def', which improves readability.

No functional changes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77520

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/lib/Basic/LangOptions.cpp


Index: clang/lib/Basic/LangOptions.cpp
===
--- clang/lib/Basic/LangOptions.cpp
+++ clang/lib/Basic/LangOptions.cpp
@@ -16,7 +16,8 @@
 
 LangOptions::LangOptions() {
 #define LANGOPT(Name, Bits, Default, Description) Name = Default;
-#define ENUM_LANGOPT(Name, Type, Bits, Default, Description) 
set##Name(Default);
+#define ENUM_LANGOPT(Name, Type, Bits, Default, Description) \
+  set##Name(Type::Default);
 #include "clang/Basic/LangOptions.def"
 }
 
@@ -24,7 +25,7 @@
 #define LANGOPT(Name, Bits, Default, Description)
 #define BENIGN_LANGOPT(Name, Bits, Default, Description) Name = Default;
 #define BENIGN_ENUM_LANGOPT(Name, Type, Bits, Default, Description) \
-  Name = Default;
+  Name = static_cast(Type::Default);
 #include "clang/Basic/LangOptions.def"
 
   // These options do not affect AST generation.
Index: clang/include/clang/Basic/LangOptions.def
===
--- clang/include/clang/Basic/LangOptions.def
+++ clang/include/clang/Basic/LangOptions.def
@@ -121,7 +121,7 @@
 LANGOPT(WritableStrings   , 1, 0, "writable string support")
 LANGOPT(ConstStrings  , 1, 0, "const-qualified string support")
 ENUM_LANGOPT(LaxVectorConversions, LaxVectorConversionKind, 2,
- LaxVectorConversionKind::All, "lax vector conversions")
+ All, "lax vector conversions")
 LANGOPT(ConvergentFunctions, 1, 1, "Assume convergent functions")
 LANGOPT(AltiVec   , 1, 0, "AltiVec-style vector initializers")
 LANGOPT(ZVector   , 1, 0, "System z vector extensions")
@@ -293,7 +293,7 @@
 BENIGN_LANGOPT(SemanticInterposition, 1, 0, "semantic interposition")
 ENUM_LANGOPT(StackProtector, StackProtectorMode, 2, SSPOff,
  "stack protector mode")
-ENUM_LANGOPT(TrivialAutoVarInit, TrivialAutoVarInitKind, 2, 
TrivialAutoVarInitKind::Uninitialized,
+ENUM_LANGOPT(TrivialAutoVarInit, TrivialAutoVarInitKind, 2, Uninitialized,
  "trivial automatic variable initialization")
 ENUM_LANGOPT(SignedOverflowBehavior, SignedOverflowBehaviorTy, 2, 
SOB_Undefined,
  "signed integer overflow handling")
@@ -313,7 +313,7 @@
 BENIGN_LANGOPT(NumLargeByValueCopy, 32, 0,
 "if non-zero, warn about parameter or return Warn if parameter/return 
value is larger in bytes than this setting. 0 is no check.")
 VALUE_LANGOPT(MSCompatibilityVersion, 32, 0, "Microsoft Visual C/C++ Version")
-ENUM_LANGOPT(VtorDispMode, MSVtorDispMode, 2, MSVtorDispMode::ForVBaseOverride,
+ENUM_LANGOPT(VtorDispMode, MSVtorDispMode, 2, ForVBaseOverride,
  "How many vtordisps to insert")
 
 LANGOPT(ApplePragmaPack, 1, 0, "Apple gcc-compatible #pragma pack handling")
@@ -339,7 +339,7 @@
 BENIGN_LANGOPT(AllowEditorPlaceholders, 1, 0,
"allow editor placeholders in source")
 
-ENUM_LANGOPT(ClangABICompat, ClangABI, 4, ClangABI::Latest,
+ENUM_LANGOPT(ClangABICompat, ClangABI, 4, Latest,
  "version of Clang that we should attempt to be ABI-compatible "
  "with")
 
@@ -353,9 +353,9 @@
 
 COMPATIBLE_VALUE_LANGOPT(MaxTokens, 32, 0, "Max number of tokens per TU or 0")
 
-ENUM_LANGOPT(SignReturnAddressScope, SignReturnAddressScopeKind, 2, 
SignReturnAddressScopeKind::None,
+ENUM_LANGOPT(SignReturnAddressScope, SignReturnAddressScopeKind, 2, None,
  "Scope of return address signing")
-ENUM_LANGOPT(SignReturnAddressKey, SignReturnAddressKeyKind, 1, 
SignReturnAddressKeyKind::AKey,
+ENUM_LANGOPT(SignReturnAddressKey, SignReturnAddressKeyKind, 1, AKey,
  "Key used for return address signing")
 LANGOPT(BranchTargetEnforcement, 1, 0, "Branch-target enforcement enabled")
 


Index: clang/lib/Basic/LangOptions.cpp
===
--- clang/lib/Basic/LangOptions.cpp
+++ clang/lib/Basic/LangOptions.cpp
@@ -16,7 +16,8 @@
 
 LangOptions::LangOptions() {
 #define LANGOPT(Name, Bits, Default, Description) Name = Default;
-#define ENUM_LANGOPT(Name, Type, Bits, Default, Description) set##Name(Default);
+#define ENUM_LANGOPT(Name, Type, Bits, Default, Description) \
+  set##Name(Type::Default);
 #include "clang/Basic/LangOptions.def"
 }
 
@@ -24,7 +25,7 @@
 #define LANGOPT(Name, Bits, Default, Description)
 #define BENIGN_LANGOPT(Name, Bits, Default, Description) Name = Default;
 #define 

[clang] 931c0cd - [OpenMP][NFC] Move and simplify directive -> allowed clause mapping

2020-04-05 Thread Johannes Doerfert via cfe-commits

Author: Johannes Doerfert
Date: 2020-04-06T00:04:08-05:00
New Revision: 931c0cd713ee9b082389727bed1b518c6a44344f

URL: 
https://github.com/llvm/llvm-project/commit/931c0cd713ee9b082389727bed1b518c6a44344f
DIFF: 
https://github.com/llvm/llvm-project/commit/931c0cd713ee9b082389727bed1b518c6a44344f.diff

LOG: [OpenMP][NFC] Move and simplify directive -> allowed clause mapping

Move the listing of allowed clauses per OpenMP directive to the new
macro file in `llvm/Frontend/OpenMP`. Also, use a single generic macro
that specifies the directive and one allowed clause explicitly instead
of a dedicated macro per directive.

We save 800 loc and boilerplate for all new directives/clauses with no
functional change. We also need to include the macro file only once and
not once per directive.

Depends on D77112.

Reviewed By: JonChesterfield

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

Added: 


Modified: 
clang/include/clang/ASTMatchers/ASTMatchers.h
clang/include/clang/Basic/OpenMPKinds.def
clang/include/clang/Basic/OpenMPKinds.h
clang/lib/ASTMatchers/Dynamic/CMakeLists.txt
clang/lib/Basic/OpenMPKinds.cpp
clang/lib/Tooling/CMakeLists.txt
clang/lib/Tooling/Transformer/CMakeLists.txt
clang/unittests/AST/CMakeLists.txt
clang/unittests/ASTMatchers/CMakeLists.txt
clang/unittests/ASTMatchers/Dynamic/CMakeLists.txt
clang/unittests/Analysis/CMakeLists.txt
clang/unittests/Rename/CMakeLists.txt
clang/unittests/Sema/CMakeLists.txt
clang/unittests/StaticAnalyzer/CMakeLists.txt
clang/unittests/Tooling/CMakeLists.txt
llvm/include/llvm/Frontend/OpenMP/OMPConstants.h
llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
llvm/lib/Frontend/OpenMP/OMPConstants.cpp

Removed: 




diff  --git a/clang/include/clang/ASTMatchers/ASTMatchers.h 
b/clang/include/clang/ASTMatchers/ASTMatchers.h
index 8d97c32a0d36..9d7b4dcaacfd 100644
--- a/clang/include/clang/ASTMatchers/ASTMatchers.h
+++ b/clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -7119,7 +7119,7 @@ AST_MATCHER(OMPDefaultClause, isSharedKind) {
 /// ``isAllowedToContainClauseKind("OMPC_default").``
 AST_MATCHER_P(OMPExecutableDirective, isAllowedToContainClauseKind,
   OpenMPClauseKind, CKind) {
-  return isAllowedClauseForDirective(
+  return llvm::omp::isAllowedClauseForDirective(
   Node.getDirectiveKind(), CKind,
   Finder->getASTContext().getLangOpts().OpenMP);
 }

diff  --git a/clang/include/clang/Basic/OpenMPKinds.def 
b/clang/include/clang/Basic/OpenMPKinds.def
index 4a4e6c6cb4c3..0ae0bc844e36 100644
--- a/clang/include/clang/Basic/OpenMPKinds.def
+++ b/clang/include/clang/Basic/OpenMPKinds.def
@@ -11,102 +11,6 @@
 ///
 
//===--===//
 
-#ifndef OPENMP_CLAUSE
-#  define OPENMP_CLAUSE(Name, Class)
-#endif
-#ifndef OPENMP_PARALLEL_CLAUSE
-#  define OPENMP_PARALLEL_CLAUSE(Name)
-#endif
-#ifndef OPENMP_SIMD_CLAUSE
-#  define OPENMP_SIMD_CLAUSE(Name)
-#endif
-#ifndef OPENMP_FOR_CLAUSE
-#  define OPENMP_FOR_CLAUSE(Name)
-#endif
-#ifndef OPENMP_FOR_SIMD_CLAUSE
-#  define OPENMP_FOR_SIMD_CLAUSE(Name)
-#endif
-#ifndef OPENMP_SECTIONS_CLAUSE
-#  define OPENMP_SECTIONS_CLAUSE(Name)
-#endif
-#ifndef OPENMP_SINGLE_CLAUSE
-#  define OPENMP_SINGLE_CLAUSE(Name)
-#endif
-#ifndef OPENMP_PARALLEL_FOR_CLAUSE
-#  define OPENMP_PARALLEL_FOR_CLAUSE(Name)
-#endif
-#ifndef OPENMP_PARALLEL_FOR_SIMD_CLAUSE
-#  define OPENMP_PARALLEL_FOR_SIMD_CLAUSE(Name)
-#endif
-#ifndef OPENMP_PARALLEL_MASTER_CLAUSE
-#  define OPENMP_PARALLEL_MASTER_CLAUSE(Name)
-#endif
-#ifndef OPENMP_PARALLEL_SECTIONS_CLAUSE
-#  define OPENMP_PARALLEL_SECTIONS_CLAUSE(Name)
-#endif
-#ifndef OPENMP_TASK_CLAUSE
-#  define OPENMP_TASK_CLAUSE(Name)
-#endif
-#ifndef OPENMP_ATOMIC_CLAUSE
-#  define OPENMP_ATOMIC_CLAUSE(Name)
-#endif
-#ifndef OPENMP_TARGET_CLAUSE
-#  define OPENMP_TARGET_CLAUSE(Name)
-#endif
-#ifndef OPENMP_REQUIRES_CLAUSE
-# define OPENMP_REQUIRES_CLAUSE(Name)
-#endif
-#ifndef OPENMP_TARGET_DATA_CLAUSE
-#  define OPENMP_TARGET_DATA_CLAUSE(Name)
-#endif
-#ifndef OPENMP_TARGET_ENTER_DATA_CLAUSE
-#define OPENMP_TARGET_ENTER_DATA_CLAUSE(Name)
-#endif
-#ifndef OPENMP_TARGET_EXIT_DATA_CLAUSE
-#define OPENMP_TARGET_EXIT_DATA_CLAUSE(Name)
-#endif
-#ifndef OPENMP_TARGET_PARALLEL_CLAUSE
-#  define OPENMP_TARGET_PARALLEL_CLAUSE(Name)
-#endif
-#ifndef OPENMP_TARGET_PARALLEL_FOR_CLAUSE
-#  define OPENMP_TARGET_PARALLEL_FOR_CLAUSE(Name)
-#endif
-#ifndef OPENMP_TARGET_UPDATE_CLAUSE
-#  define OPENMP_TARGET_UPDATE_CLAUSE(Name)
-#endif
-#ifndef OPENMP_TEAMS_CLAUSE
-#  define OPENMP_TEAMS_CLAUSE(Name)
-#endif
-#ifndef OPENMP_CANCEL_CLAUSE
-#  define OPENMP_CANCEL_CLAUSE(Name)
-#endif
-#ifndef OPENMP_ORDERED_CLAUSE
-#  define OPENMP_ORDERED_CLAUSE(Name)
-#endif
-#ifndef OPENMP_TASKLOOP_CLAUSE
-#  define OPENMP_TASKLOOP_CLAUSE(Name)
-#endif
-#ifndef OPENMP_TASKLOOP_SIMD_CLAUSE
-#  define 

[PATCH] D75917: Expose llvm fence instruction as clang intrinsic

2020-04-05 Thread Sameer Sahasrabuddhe via Phabricator via cfe-commits
sameerds requested changes to this revision.
sameerds added inline comments.
This revision now requires changes to proceed.



Comment at: clang/include/clang/Basic/Builtins.def:1583
+// Second argument : target specific sync scope string
+BUILTIN(__builtin_memory_fence, "vUicC*", "n")
+

This should be moved to be near line 786,  where atomic builtins are listed 
under the comment "// GCC does not support these, they are a Clang extension."



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:13630
+
+  // Map C11/C++11 memory ordering to LLVM memory ordering
+  switch (static_cast(ord)) {

There should no mention of any high-level language here. The correct enum to 
validate against is llvm::AtomicOrdering from llvm/Support/AtomicOrdering.h, 
and not the C ABI or any other language ABI.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:13651
+  llvm::getConstantStringInfo(Scope, scp);
+  SSID = getLLVMContext().getOrInsertSyncScopeID(scp);
+

This seems to be creating a new ID for any arbitrary string passed as sync 
scope. This should be validated against LLVMContext::getSyncScopeNames(). 



Comment at: clang/test/CodeGenHIP/builtin_memory_fence.cpp:5
+
+void test_memory_fence_success() {
+// CHECK-LABEL: test_memory_fence_success

There should be a line that tries to do:
  __builtin_memory_fence(__ATOMIC_SEQ_CST, "foobar");



Comment at: clang/test/CodeGenHIP/builtin_memory_fence.cpp:9
+  // CHECK: fence syncscope("workgroup") seq_cst
+  __builtin_memory_fence(__ATOMIC_SEQ_CST,  "workgroup");
+  

Orderings like `__ATOMIC_SEQ_CST` are defined for C/C++ memory models. They 
should not be used with the new builtin because this new builtin does not 
follow any specific language model. For user convenience, the right thing to do 
is to introduce new tokens in the Clang preprocessor, similar to the 
`__ATOMIC_*` tokens. The convenient shortcut is to just tell the user to supply 
numerical values by looking at the LLVM source code.

From llvm/Support/AtomicOrdering.h, note how the numerical value for 
`__ATOMIC_SEQ_CST` is 5, but the numerical value for the LLVM 
SequentiallyConsistent ordering is 7. The numerical value 5 refers to the LLVM 
ordering "release". So, if the implementation were correct, this line should 
result in the following unexpected LLVM IR:
  fence syncscope("workgroup") release


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75917/new/

https://reviews.llvm.org/D75917



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


[PATCH] D77112: [OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP`

2020-04-05 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Broke clang-tools-extra again: 
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/46759/steps/build%20stage%201/logs/stdio


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77112/new/

https://reviews.llvm.org/D77112



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


[clang-tools-extra] 8ea07f6 - [OpenMP] Add extra qualification to OpenMP clause id

2020-04-05 Thread Johannes Doerfert via cfe-commits

Author: Johannes Doerfert
Date: 2020-04-05T23:10:58-05:00
New Revision: 8ea07f62a6f06bdb7da981425227995423867a4d

URL: 
https://github.com/llvm/llvm-project/commit/8ea07f62a6f06bdb7da981425227995423867a4d
DIFF: 
https://github.com/llvm/llvm-project/commit/8ea07f62a6f06bdb7da981425227995423867a4d.diff

LOG: [OpenMP] Add extra qualification to OpenMP clause id

Forgot to adjust this use in 419a559c5a73f13578d891feb1299cada08d581e.

Added: 


Modified: 
clang-tools-extra/clang-tidy/openmp/UseDefaultNoneCheck.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/openmp/UseDefaultNoneCheck.cpp 
b/clang-tools-extra/clang-tidy/openmp/UseDefaultNoneCheck.cpp
index efd70e778c6f..724e9b9b9cbc 100644
--- a/clang-tools-extra/clang-tidy/openmp/UseDefaultNoneCheck.cpp
+++ b/clang-tools-extra/clang-tidy/openmp/UseDefaultNoneCheck.cpp
@@ -24,7 +24,7 @@ namespace openmp {
 void UseDefaultNoneCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(
   ompExecutableDirective(
-  allOf(isAllowedToContainClauseKind(OMPC_default),
+  allOf(isAllowedToContainClauseKind(llvm::omp::OMPC_default),
 anyOf(unless(hasAnyClause(ompDefaultClause())),
   hasAnyClause(ompDefaultClause(unless(isNoneKind()))
.bind("clause")



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


[PATCH] D77028: [NFC] Refactor DeferredDiagsEmitter and skip redundant visit

2020-04-05 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 3 inline comments as done.
yaxunl added inline comments.



Comment at: clang/lib/Sema/Sema.cpp:1508
   void checkFunc(SourceLocation Loc, FunctionDecl *FD) {
+auto DiagsCountIt = DiagsCount.find(FD);
 FunctionDecl *Caller = UseStack.empty() ? nullptr : UseStack.back();

rjmccall wrote:
> yaxunl wrote:
> > rjmccall wrote:
> > > yaxunl wrote:
> > > > rjmccall wrote:
> > > > > yaxunl wrote:
> > > > > > rjmccall wrote:
> > > > > > > yaxunl wrote:
> > > > > > > > rjmccall wrote:
> > > > > > > > > It makes me a little uncomfortable to be holding an iterator 
> > > > > > > > > this long while calling a fair amount of other stuff in the 
> > > > > > > > > meantime.
> > > > > > > > > 
> > > > > > > > > Your use of DiagsCount is subtle enough that it really needs 
> > > > > > > > > to be explained in some comments.  You're doing stuff 
> > > > > > > > > conditionally based on both whether the entry exists but also 
> > > > > > > > > whether it's non-zero.
> > > > > > > > added comments
> > > > > > > Okay, thanks for that.  Two points, then.  First, it looks like 
> > > > > > > the count is really just a boolean for whether the function 
> > > > > > > recursively triggers any diagnostics.   And second, can't it just 
> > > > > > > be as simple as whether we've visited that function at all in a 
> > > > > > > context that's forcing diagnostics to be emitted?  The logic 
> > > > > > > seems to be to try to emit the diagnostics for each use-path, but 
> > > > > > > why would we want that?
> > > > > > For the second comment, we need to visit a function again for each 
> > > > > > use-path because we need to report each use-path that triggers a 
> > > > > > diagnostic, otherwise users will see a new error after they fix one 
> > > > > > error, instead of seeing all the errors at once.
> > > > > > 
> > > > > > For the first comment, I will change the count to two flags: one 
> > > > > > for the case where the function is not in device context, the other 
> > > > > > is for the case where the function is in device context. This will 
> > > > > > allow us to avoid redundant visits whether or not we are in a 
> > > > > > device context.
> > > > > > For the second comment, we need to visit a function again for each 
> > > > > > use-path because we need to report each use-path that triggers a 
> > > > > > diagnostic, otherwise users will see a new error after they fix one 
> > > > > > error, instead of seeing all the errors at once.
> > > > > 
> > > > > This is not what we do in analogous cases where errors are triggered 
> > > > > by a use, like in template instantiation.   The bug might be that the 
> > > > > device program is using a function that it shouldn't be using, or the 
> > > > > bug might be that a function that's supposed  to be usable from the 
> > > > > device is written incorrectly.  In the former case, yes, not 
> > > > > reporting the errors for each use-path may force the programmer to 
> > > > > build multiple times to find all the problematic uses.  However, in 
> > > > > the latter case you can easily end up emitting a massive number of 
> > > > > errors that completely drowns out everything else.  It's also 
> > > > > non-linear: the number of different use-paths of a particular 
> > > > > function can be combinatoric.
> > > > The deferred diagnostics fall into the first case mostly. 
> > > > 
> > > > Not all diagnostic messages happen in device host functions are 
> > > > deferred. Most of diagnostic messages are emitted immediately, 
> > > > disregarding whether the function is emitted or not. 
> > > > 
> > > > Only a few special types of diagnostic messages e.g. inline assembly 
> > > > errors, exceptions, varags are deferred. This is because clang has to 
> > > > use pragmas to make all functions device and host in some system 
> > > > headers to be able to use them in device compilation, whereas some of 
> > > > these functions will cause error only if they are emitted in device 
> > > > compilation. Since we cannot change these headers, we have to defer 
> > > > such diagnostics to the point where they are actually triggered. 
> > > > Therefore we are mostly interested in "who is calling these functions" 
> > > > instead of the diagnostics themselves.
> > > > 
> > > > For normal programs containing no diagnostics, the current approach 
> > > > should sufficiently avoid all redundant visits and all functions will 
> > > > be visited once.
> > > > 
> > > > The functions may be visited multiple times when there are deferred 
> > > > diagnostics, however this should be limited by the maximum number of 
> > > > errors.
> > > Okay.  I understand the point now about being mostly concerned about 
> > > using functions in headers.
> > > 
> > > My concern about visiting things a combinatorial number of times is less 
> > > about generating an excessive number of errors and more about taking an 
> > > excessive amount of time to finish compilation.  The 

[PATCH] D77414: [OpenMP] Add match_{all,any,none} declare variant selector extensions.

2020-04-05 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert marked an inline comment as done.
jdoerfert added a comment.

Will fix the other two nits too.




Comment at: clang/lib/Parse/ParseOpenMP.cpp:1823
 ASTContext  = Actions.getASTContext();
-TI.getAsVariantMatchInfo(ASTCtx, VMI, /* DeviceSetOnly */ true);
+TI.getAsVariantMatchInfo(ASTCtx, VMI);
 OMPContext OMPCtx(ASTCtx.getLangOpts().OpenMPIsDevice,

mikerice wrote:
> One of the lit tests fails because this is called before semantic checks on 
> the score expression.  This function tries to evaluate the score as a 
> constant and if it isn't will crash.  Probably not specific to this change 
> but how can we deal with that?
> 
> ```
> int foo(void);
> #pragma omp begin declare variant match(implementation={vendor(score(foo()) 
> ibm)})
> #pragma omp end declare variant
> ```
Saw that too late but it's fixed now. We will ignore non-constant scores and 
evaluae non-constant user conditions as false. Note that both are not valid 
inputs we will diagnose later anyway.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77414/new/

https://reviews.llvm.org/D77414



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


[PATCH] D77290: [OpenMP] Specialize OpenMP calls after template instantiation

2020-04-05 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert marked an inline comment as done.
jdoerfert added inline comments.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:1693
+ExprResult TemplateInstantiator::TransformCallExpr(CallExpr *E) {
+  ExprResult R = TreeTransform::TransformCallExpr(E);
+  if (!SemaRef.getLangOpts().OpenMP || !R.isUsable() || 
!isa(R.get()))

mikerice wrote:
> Is there a reason you are adding this here as opposed to in the base class 
> RebuildCallExpr?  Are there cases where we rebuild call expressions that we 
> don't want to do this variant processing?
I just didn't know about it. I'll move the code there.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77290/new/

https://reviews.llvm.org/D77290



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


[PATCH] D68115: Zero initialize padding in unions

2020-04-05 Thread JF Bastien via Phabricator via cfe-commits
jfb added a comment.

> That sounds reasonable to me. So the behavior we're looking for is:
> 
> - If `-ftrivial-auto-init` is off, then we guarantee to zero padding when the 
> language spec requires it, and otherwise provide no such guarantee.
> - If `-ftrivial-auto-init=zeroes` then we guarantee to zero padding within 
> structs and unions with automatic storage duration, when that padding would 
> otherwise be left uninitialized.
> - If `-ftrivial-auto-init=pattern` then we guarantee to pattern-fill padding 
> within structs and unions with automatic storage duration, when that padding 
> would otherwise be left uninitialized (and will provide the zeroes required 
> by the language rule when that is the required behavior).

That's exactly what I'd like, yes!

> [One possible tweak: for the `pattern` case, should we guarantee that the 
> uninitialized padding will be pattern-filled? It would be simpler if we 
> guaranteed it to be *either* zero- or pattern-filled; that way we can provide 
> a conservatively-correct approximation by zero-filling whenever we're unsure.]

Not guaranteeing a specific value for "pattern" remains my preferred choice. 
Where feasible, I'd rather we generate the most-repeated pattern so it's 
cheaper to synthesize.

> And we do not initially provide any guarantees as to what happens to padding 
> within objects of other storage durations beyond what the language spec 
> requires. (We might at some point in the future, but that would be behind a 
> separate flag from `-ftrivial-auto-init`.) I'd be happy with that approach. 
> Does that address everyone's concerns?

Yup!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68115/new/

https://reviews.llvm.org/D68115



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


[PATCH] D77194: [clang] Persist Attr::IsPackExpansion into the PCH

2020-04-05 Thread Nathan Ridge via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8b3b7556e9ab: [clang] Persist Attr::IsPackExpansion into the 
PCH (authored by nridge).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77194/new/

https://reviews.llvm.org/D77194

Files:
  clang/test/PCH/cxx-attrs-packexpansion.cpp
  clang/utils/TableGen/ClangAttrEmitter.cpp


Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -2911,6 +2911,7 @@
 if (R.isSubClassOf(InhClass))
   OS << "bool isInherited = Record.readInt();\n";
 OS << "bool isImplicit = Record.readInt();\n";
+OS << "bool isPackExpansion = Record.readInt();\n";
 ArgRecords = R.getValueAsListOfDefs("Args");
 Args.clear();
 for (const auto *Arg : ArgRecords) {
@@ -2926,6 +2927,7 @@
 if (R.isSubClassOf(InhClass))
   OS << "cast(New)->setInherited(isInherited);\n";
 OS << "New->setImplicit(isImplicit);\n";
+OS << "New->setPackExpansion(isPackExpansion);\n";
 OS << "break;\n";
 OS << "  }\n";
   }
@@ -2952,6 +2954,7 @@
 if (R.isSubClassOf(InhClass))
   OS << "Record.push_back(SA->isInherited());\n";
 OS << "Record.push_back(A->isImplicit());\n";
+OS << "Record.push_back(A->isPackExpansion());\n";
 
 for (const auto *Arg : Args)
   createArgument(*Arg, R.getName())->writePCHWrite(OS);
Index: clang/test/PCH/cxx-attrs-packexpansion.cpp
===
--- /dev/null
+++ clang/test/PCH/cxx-attrs-packexpansion.cpp
@@ -0,0 +1,25 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %s -emit-llvm -o - %s
+
+// Test with pch.
+// RUN: %clang_cc1 -emit-pch -o %t %s
+// RUN: %clang_cc1 -include-pch %t -emit-llvm -o - %s
+
+#ifndef HEADER
+#define HEADER
+
+template
+struct static_variant {
+alignas(Types...) T storage[10];
+};
+
+#else
+
+struct A {
+static_variant a;
+};
+struct B {
+static_variant _b;
+};
+
+#endif


Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -2911,6 +2911,7 @@
 if (R.isSubClassOf(InhClass))
   OS << "bool isInherited = Record.readInt();\n";
 OS << "bool isImplicit = Record.readInt();\n";
+OS << "bool isPackExpansion = Record.readInt();\n";
 ArgRecords = R.getValueAsListOfDefs("Args");
 Args.clear();
 for (const auto *Arg : ArgRecords) {
@@ -2926,6 +2927,7 @@
 if (R.isSubClassOf(InhClass))
   OS << "cast(New)->setInherited(isInherited);\n";
 OS << "New->setImplicit(isImplicit);\n";
+OS << "New->setPackExpansion(isPackExpansion);\n";
 OS << "break;\n";
 OS << "  }\n";
   }
@@ -2952,6 +2954,7 @@
 if (R.isSubClassOf(InhClass))
   OS << "Record.push_back(SA->isInherited());\n";
 OS << "Record.push_back(A->isImplicit());\n";
+OS << "Record.push_back(A->isPackExpansion());\n";
 
 for (const auto *Arg : Args)
   createArgument(*Arg, R.getName())->writePCHWrite(OS);
Index: clang/test/PCH/cxx-attrs-packexpansion.cpp
===
--- /dev/null
+++ clang/test/PCH/cxx-attrs-packexpansion.cpp
@@ -0,0 +1,25 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %s -emit-llvm -o - %s
+
+// Test with pch.
+// RUN: %clang_cc1 -emit-pch -o %t %s
+// RUN: %clang_cc1 -include-pch %t -emit-llvm -o - %s
+
+#ifndef HEADER
+#define HEADER
+
+template
+struct static_variant {
+alignas(Types...) T storage[10];
+};
+
+#else
+
+struct A {
+static_variant a;
+};
+struct B {
+static_variant _b;
+};
+
+#endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 8b3b755 - [clang] Persist Attr::IsPackExpansion into the PCH

2020-04-05 Thread Nathan Ridge via cfe-commits

Author: Nathan Ridge
Date: 2020-04-05T23:32:03-04:00
New Revision: 8b3b7556e9ab6084e9fd337d64dac1c165867d32

URL: 
https://github.com/llvm/llvm-project/commit/8b3b7556e9ab6084e9fd337d64dac1c165867d32
DIFF: 
https://github.com/llvm/llvm-project/commit/8b3b7556e9ab6084e9fd337d64dac1c165867d32.diff

LOG: [clang] Persist Attr::IsPackExpansion into the PCH

Summary: Fixes https://github.com/clangd/clangd/issues/309

Subscribers: ilya-biryukov, kadircet, usaxena95, cfe-commits

Tags: #clang

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

Added: 
clang/test/PCH/cxx-attrs-packexpansion.cpp

Modified: 
clang/utils/TableGen/ClangAttrEmitter.cpp

Removed: 




diff  --git a/clang/test/PCH/cxx-attrs-packexpansion.cpp 
b/clang/test/PCH/cxx-attrs-packexpansion.cpp
new file mode 100644
index ..6d292ec1e3e0
--- /dev/null
+++ b/clang/test/PCH/cxx-attrs-packexpansion.cpp
@@ -0,0 +1,25 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %s -emit-llvm -o - %s
+
+// Test with pch.
+// RUN: %clang_cc1 -emit-pch -o %t %s
+// RUN: %clang_cc1 -include-pch %t -emit-llvm -o - %s
+
+#ifndef HEADER
+#define HEADER
+
+template
+struct static_variant {
+alignas(Types...) T storage[10];
+};
+
+#else
+
+struct A {
+static_variant a;
+};
+struct B {
+static_variant _b;
+};
+
+#endif

diff  --git a/clang/utils/TableGen/ClangAttrEmitter.cpp 
b/clang/utils/TableGen/ClangAttrEmitter.cpp
index e9f91c685ee4..486799eb81ba 100644
--- a/clang/utils/TableGen/ClangAttrEmitter.cpp
+++ b/clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -2911,6 +2911,7 @@ void EmitClangAttrPCHRead(RecordKeeper , 
raw_ostream ) {
 if (R.isSubClassOf(InhClass))
   OS << "bool isInherited = Record.readInt();\n";
 OS << "bool isImplicit = Record.readInt();\n";
+OS << "bool isPackExpansion = Record.readInt();\n";
 ArgRecords = R.getValueAsListOfDefs("Args");
 Args.clear();
 for (const auto *Arg : ArgRecords) {
@@ -2926,6 +2927,7 @@ void EmitClangAttrPCHRead(RecordKeeper , 
raw_ostream ) {
 if (R.isSubClassOf(InhClass))
   OS << "cast(New)->setInherited(isInherited);\n";
 OS << "New->setImplicit(isImplicit);\n";
+OS << "New->setPackExpansion(isPackExpansion);\n";
 OS << "break;\n";
 OS << "  }\n";
   }
@@ -2952,6 +2954,7 @@ void EmitClangAttrPCHWrite(RecordKeeper , 
raw_ostream ) {
 if (R.isSubClassOf(InhClass))
   OS << "Record.push_back(SA->isInherited());\n";
 OS << "Record.push_back(A->isImplicit());\n";
+OS << "Record.push_back(A->isPackExpansion());\n";
 
 for (const auto *Arg : Args)
   createArgument(*Arg, R.getName())->writePCHWrite(OS);



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


[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

2020-04-05 Thread Jakub Kuderski via Phabricator via cfe-commits
kuhar added inline comments.



Comment at: llvm/include/llvm/IR/CFGDiff.h:198
 
+namespace {
+template 

kuhar wrote:
> What benefit does an anonymous namespace in a header have over a named one, 
> e.g., `detail`/`impl`? Doesn't it make it more difficult to deduplicate 
> symbols across different translation units? Not sure what the best practices 
> are in C++ now in this area.
Found an article on this matter: 
https://wiki.sei.cmu.edu/confluence/display/cplusplus/DCL59-CPP.+Do+not+define+an+unnamed+namespace+in+a+header+file


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77341/new/

https://reviews.llvm.org/D77341



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


[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

2020-04-05 Thread Jakub Kuderski via Phabricator via cfe-commits
kuhar added a comment.

In D77341#1960854 , @asbirlea wrote:

> Address comments.


Thanks for the changes and explanations. It think with a few more tweaks this 
will be a good refactoring step towards phasing out BUI.




Comment at: llvm/include/llvm/IR/CFGDiff.h:198
 
+namespace {
+template 

What benefit does an anonymous namespace in a header have over a named one, 
e.g., `detail`/`impl`? Doesn't it make it more difficult to deduplicate symbols 
across different translation units? Not sure what the best practices are in C++ 
now in this area.



Comment at: llvm/include/llvm/Support/GenericDomTreeConstruction.h:325
+auto  = BUI ? BUI->PreViewCFG : EmptyGD;
+return !empty(children({, N}));
   }

This pattern repeats a few times. Could it be pushed into a helper function to 
get something like this?

```
return !empty(children(GetGraphDiffNodePair(BUI, N)));
```



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77341/new/

https://reviews.llvm.org/D77341



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


[PATCH] D76646: Rename/refactor isIntegerConstantExpression to getIntegerConstantExpression

2020-04-05 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76646/new/

https://reviews.llvm.org/D76646



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


[PATCH] D77519: Fix __is_pointer builtin type trait to work with Objective-C pointer types.

2020-04-05 Thread Zoe Carver via Phabricator via cfe-commits
zoecarver created this revision.
Herald added projects: clang, libc++.
Herald added subscribers: libcxx-commits, cfe-commits.
Herald added a reviewer: libc++.
zoecarver added reviewers: ldionne, rsmith, EricWF.
Herald added a subscriber: dexonsmith.

5ade17e  
broke __is_pointer for Objective-C pointer types. This patch fixes the builtin 
and re-applies the change to type_traits.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77519

Files:
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/SemaObjC/type-traits-is-pointer.mm
  libcxx/include/type_traits

Index: libcxx/include/type_traits
===
--- libcxx/include/type_traits
+++ libcxx/include/type_traits
@@ -897,6 +897,19 @@
 
 // is_pointer
 
+// In clang 10.0.0 and earlier __is_pointer didn't work with Objective-C types.
+#if __has_keyword(__is_pointer) && _LIBCPP_CLANG_VER > 1000
+
+template
+struct _LIBCPP_TEMPLATE_VIS is_pointer : _BoolConstant<__is_pointer(_Tp)> { };
+
+#if _LIBCPP_STD_VER > 14 && !defined(_LIBCPP_HAS_NO_VARIABLE_TEMPLATES)
+template 
+_LIBCPP_INLINE_VAR _LIBCPP_CONSTEXPR bool is_pointer_v = __is_pointer(_Tp);
+#endif
+
+#else // __has_keyword(__is_pointer)
+
 template  struct __libcpp_is_pointer   : public false_type {};
 template  struct __libcpp_is_pointer<_Tp*> : public true_type {};
 
@@ -917,6 +930,8 @@
 = is_pointer<_Tp>::value;
 #endif
 
+#endif // __has_keyword(__is_pointer)
+
 // is_reference
 
 #if __has_keyword(__is_lvalue_reference) && \
Index: clang/test/SemaObjC/type-traits-is-pointer.mm
===
--- /dev/null
+++ clang/test/SemaObjC/type-traits-is-pointer.mm
@@ -0,0 +1,52 @@
+// RUN: %clang -fobjc-arc %s
+
+template 
+void assert_is_pointer() {
+static_assert(__is_pointer(T), "");
+}
+
+template 
+void test_is_pointer() {
+assert_is_pointer();
+
+assert_is_pointer();
+assert_is_pointer();
+assert_is_pointer();
+assert_is_pointer();
+
+assert_is_pointer();
+assert_is_pointer();
+assert_is_pointer();
+assert_is_pointer();
+
+assert_is_pointer();
+assert_is_pointer();
+assert_is_pointer();
+assert_is_pointer();
+
+assert_is_pointer();
+assert_is_pointer();
+assert_is_pointer();
+assert_is_pointer();
+}
+
+@class Foo;
+
+int main(int, char**) {
+test_is_pointer();
+test_is_pointer();
+test_is_pointer();
+test_is_pointer();
+
+test_is_pointer();
+test_is_pointer();
+test_is_pointer();
+test_is_pointer();
+
+test_is_pointer();
+test_is_pointer();
+test_is_pointer();
+test_is_pointer();
+
+return 0;
+}
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -4692,7 +4692,7 @@
   case UTT_IsArray:
 return T->isArrayType();
   case UTT_IsPointer:
-return T->isPointerType();
+return T->isAnyPointerType();
   case UTT_IsLvalueReference:
 return T->isLValueReferenceType();
   case UTT_IsRvalueReference:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D68115: Zero initialize padding in unions

2020-04-05 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

In D68115#1962863 , @jfb wrote:

> In D68115#1962833 , @rsmith wrote:
>
> > I think the majority opinion expressed on this review at this point favors 
> > not guaranteeing zero-initialization except where required by the relevant 
> > standard. That'd also be consistent with our stance on trivial auto 
> > variable initialization in general.
>
>
> Sorry, I didn't express myself well: if trivial auto-var init is on, then I 
> want initialization of union padding to also be on. I think this is exactly 
> compatible with what you want, as is says nothing of the behavior when 
> trivial auto-var init is not on.
>
> > I'm not yet sure about whether we want separate controls for this and for 
> > `-ftrivial-auto-init`, or whether from a user's perspective there's really 
> > only one question: should bits left uninitialized be `undef`, guaranteed 
> > zero, or guaranteed to be filled with a pattern -- independent of whether 
> > they're padding bits? (And related, do we actually want control over 
> > zeroing union padding in all cases or only for trivial automatic variables? 
> > And do we want control over zeroing or pattern-filling objects allocated 
> > with `new` with trivial initialization?)
>
> Trivial auto-var init should always initialize all stack padding, and should 
> not also initialize heap padding. There should be separate controls for heap 
> padding, in part because this interacts with the allocator (whereas stack 
> initialization does not).


That sounds reasonable to me. So the behavior we're looking for is:

- If `-ftrivial-auto-init` is off, then we guarantee to zero padding when the 
language spec requires it, and otherwise provide no such guarantee.
- If `-ftrivial-auto-init=zeroes` then we guarantee to zero padding within 
structs and unions with automatic storage duration, when that padding would 
otherwise be left uninitialized.
- If `-ftrivial-auto-init=pattern` then we guarantee to pattern-fill padding 
within structs and unions with automatic storage duration, when that padding 
would otherwise be left uninitialized (and will provide the zeroes required by 
the language rule when that is the required behavior).

[One possible tweak: for the `pattern` case, should we guarantee that the 
uninitialized padding will be pattern-filled? It would be simpler if we 
guaranteed it to be *either* zero- or pattern-filled; that way we can provide a 
conservatively-correct approximation by zero-filling whenever we're unsure.]

And we do not initially provide any guarantees as to what happens to padding 
within objects of other storage durations beyond what the language spec 
requires. (We might at some point in the future, but that would be behind a 
separate flag from `-ftrivial-auto-init`.) I'd be happy with that approach. 
Does that address everyone's concerns?

If so, how do we make progress on this? @vitalybuka, are you interested in 
doing the work to track whether padding should be zeroed in `APValue`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68115/new/

https://reviews.llvm.org/D68115



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


[PATCH] D77414: [OpenMP] Add match_{all,any,none} declare variant selector extensions.

2020-04-05 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert updated this revision to Diff 255212.
jdoerfert added a comment.

Rebase and fix a problem with evaluation of non-constants


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77414/new/

https://reviews.llvm.org/D77414

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/lib/AST/OpenMPClause.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/AST/ast-dump-openmp-declare-variant-extensions-messages.c
  clang/test/AST/ast-dump-openmp-declare-variant-extensions.c
  clang/test/OpenMP/declare_variant_ast_print.c
  clang/test/OpenMP/declare_variant_messages.c
  llvm/include/llvm/Frontend/OpenMP/OMPContext.h
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Frontend/OpenMP/OMPContext.cpp

Index: llvm/lib/Frontend/OpenMP/OMPContext.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPContext.cpp
+++ llvm/lib/Frontend/OpenMP/OMPContext.cpp
@@ -137,52 +137,119 @@
 
 static int isVariantApplicableInContextHelper(
 const VariantMatchInfo , const OMPContext ,
-SmallVectorImpl *ConstructMatches) {
+SmallVectorImpl *ConstructMatches, bool DeviceSetOnly) {
+
+  // The match kind determines if we need to match all traits, any of the
+  // traits, or none of the traits for it to be an applicable context.
+  enum MatchKind { MK_ALL, MK_ANY, MK_NONE };
+
+  MatchKind MK = MK_ALL;
+  // Determine the match kind the user wants, "all" is the default and provided
+  // to the user only for completeness.
+  if (VMI.RequiredTraits.test(
+  unsigned(TraitProperty::implementation_extension_match_any)))
+MK = MK_ANY;
+  if (VMI.RequiredTraits.test(
+  unsigned(TraitProperty::implementation_extension_match_none)))
+MK = MK_NONE;
+
+  // Helper to deal with a single property that was (not) found in the OpenMP
+  // context based on the match kind selected by the user via
+  // `implementation={extensions(match_[all,any,none])}'
+  auto HandleTrait = [MK](TraitProperty Property,
+  bool WasFound) -> Optional /* Result */ {
+// For kind "any" a single match is enough but we ignore non-matched properties.
+if (MK == MK_ANY) {
+  if (WasFound)
+return true;
+  return None;
+}
+
+// In "all" or "none" mode we accept a matching or non-matching property
+// respectively and move on. We are not done yet!
+if ((WasFound && MK == MK_ALL) || (!WasFound && MK == MK_NONE))
+  return None;
+
+// We missed a property, provide some debug output and indicate failure.
+LLVM_DEBUG({
+  if (MK == MK_ALL)
+dbgs() << "[" << DEBUG_TYPE << "] Property "
+   << getOpenMPContextTraitPropertyName(Property)
+   << " was not in the OpenMP context but match kind is all.\n";
+  if (MK == MK_NONE)
+dbgs() << "[" << DEBUG_TYPE << "] Property "
+   << getOpenMPContextTraitPropertyName(Property)
+   << " was in the OpenMP context but match kind is none.\n";
+});
+return false;
+  };
 
   for (unsigned Bit : VMI.RequiredTraits.set_bits()) {
 TraitProperty Property = TraitProperty(Bit);
+if (DeviceSetOnly &&
+getOpenMPContextTraitSetForProperty(Property) != TraitSet::device)
+  continue;
+
+// So far all extensions are handled elsewhere, we skip them here as they
+// are not part of the OpenMP context.
+if (getOpenMPContextTraitSelectorForProperty(Property) ==
+TraitSelector::implementation_extension)
+  continue;
 
 bool IsActiveTrait = Ctx.ActiveTraits.test(unsigned(Property));
-if (!IsActiveTrait) {
-  LLVM_DEBUG(dbgs() << "[" << DEBUG_TYPE << "] Property "
-<< getOpenMPContextTraitPropertyName(Property)
-<< " was not in the OpenMP context.\n");
-  return false;
-}
+Optional Result = HandleTrait(Property, IsActiveTrait);
+if (Result.hasValue())
+  return Result.getValue();
   }
 
-  // We could use isSubset here but we also want to record the match locations.
-  unsigned ConstructIdx = 0, NoConstructTraits = Ctx.ConstructTraits.size();
-  for (TraitProperty Property : VMI.ConstructTraits) {
-assert(getOpenMPContextTraitSetForProperty(Property) ==
-   TraitSet::construct &&
-   "Variant context is ill-formed!");
-
-// Verify the nesting.
-bool FoundInOrder = false;
-while (!FoundInOrder && ConstructIdx != NoConstructTraits)
-  FoundInOrder = (Ctx.ConstructTraits[ConstructIdx++] == Property);
-if (ConstructMatches)
-  ConstructMatches->push_back(ConstructIdx - 1);
-
-if (!FoundInOrder) {
-  LLVM_DEBUG(dbgs() << "[" << DEBUG_TYPE << "] Construct property "
-<< getOpenMPContextTraitPropertyName(Property)
-<< " was not 

[PATCH] D68115: Zero initialize padding in unions

2020-04-05 Thread JF Bastien via Phabricator via cfe-commits
jfb added a comment.

In D68115#1962833 , @rsmith wrote:

> In D68115#1946990 , @jfb wrote:
>
> > In D68115#1946757 , @rsmith wrote:
> >
> > > In D68115#1946668 , 
> > > @hubert.reinterpretcast wrote:
> > >
> > > > It sounds like we are looking for `-fzero-union-padding`. That's been 
> > > > where the discussion has left off twice for months.
> > >
> > >
> > > I believe the state of Clang prior to this patch is actually wrong.
> >
> >
> > That's my understanding as well. I'd like it if this patch (or a follow-up) 
> > got us back to standard behavior. In either case, I'd like the proposed 
> > behavior to bee on-by-default when doing initialization of stack variables.
>
>
> Your preference is noted. However, I think the majority opinion expressed on 
> this review at this point favors not guaranteeing zero-initialization except 
> where required by the relevant standard. That'd also be consistent with our 
> stance on trivial auto variable initialization in general.


Sorry, I didn't express myself well: if trivial auto-var init is on, then I 
want initialization of union padding to also be on. I think this is exactly 
compatible with what you want, as is says nothing of the behavior when trivial 
auto-var init is not on.

> I'm not yet sure about whether we want separate controls for this and for 
> `-ftrivial-auto-init`, or whether from a user's perspective there's really 
> only one question: should bits left uninitialized be `undef`, guaranteed 
> zero, or guaranteed to be filled with a pattern -- independent of whether 
> they're padding bits? (And related, do we actually want control over zeroing 
> union padding in all cases or only for trivial automatic variables? And do we 
> want control over zeroing or pattern-filling objects allocated with `new` 
> with trivial initialization?)

Trivial auto-var init should always initialize all stack padding, and should 
not also initialize heap padding. There should be separate controls for heap 
padding, in part because this interacts with the allocator (whereas stack 
initialization does not).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68115/new/

https://reviews.llvm.org/D68115



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


[PATCH] D77290: [OpenMP] Specialize OpenMP calls after template instantiation

2020-04-05 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert updated this revision to Diff 255210.
jdoerfert added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77290/new/

https://reviews.llvm.org/D77290

Files:
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/AST/ast-dump-openmp-begin-declare-variant_template_1.cpp

Index: clang/test/AST/ast-dump-openmp-begin-declare-variant_template_1.cpp
===
--- /dev/null
+++ clang/test/AST/ast-dump-openmp-begin-declare-variant_template_1.cpp
@@ -0,0 +1,170 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fopenmp -verify -ast-dump %s   | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fopenmp -verify -ast-dump %s -x c++| FileCheck %s
+// expected-no-diagnostics
+
+int also_before() {
+  return 1;
+}
+
+#pragma omp begin declare variant match(implementation={vendor(score(100):llvm)})
+int also_after(void) {
+  return 2;
+}
+int also_after(int) {
+  return 3;
+}
+int also_after(double) {
+  return 0;
+}
+#pragma omp end declare variant
+#pragma omp begin declare variant match(implementation={vendor(score(0):llvm)})
+int also_before() {
+  return 0;
+}
+#pragma omp end declare variant
+
+int also_after(void) {
+  return 4;
+}
+int also_after(int) {
+  return 5;
+}
+int also_after(double) {
+  return 6;
+}
+
+template
+int test1() {
+  // Should return 0.
+  return also_after(T(0));
+}
+
+typedef int(*Ty)();
+
+template
+int test2() {
+  // Should return 0.
+  return fn();
+}
+
+int test() {
+  // Should return 0.
+  return test1() + test2();
+}
+
+// CHECK:  |-FunctionDecl [[ADDR_0:0x[a-z0-9]*]] <{{.*}}, line:7:1> line:5:5 used also_before 'int ({{.*}})'
+// CHECK-NEXT: | |-CompoundStmt [[ADDR_1:0x[a-z0-9]*]] 
+// CHECK-NEXT: | | `-ReturnStmt [[ADDR_2:0x[a-z0-9]*]] 
+// CHECK-NEXT: | |   `-IntegerLiteral [[ADDR_3:0x[a-z0-9]*]]  'int' 1
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_4:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(0): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_5:0x[a-z0-9]*]]  'int ({{.*}})' Function [[ADDR_6:0x[a-z0-9]*]] 'also_before[implementation={vendor(llvm)}]' 'int ({{.*}})'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_7:0x[a-z0-9]*]]  col:5 implicit also_after 'int ({{.*}})'
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_8:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(100): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_9:0x[a-z0-9]*]]  'int ({{.*}})' Function [[ADDR_10:0x[a-z0-9]*]] 'also_after[implementation={vendor(llvm)}]' 'int ({{.*}})'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_10]]  line:10:1 also_after[implementation={vendor(llvm)}] 'int ({{.*}})'
+// CHECK-NEXT: | `-CompoundStmt [[ADDR_11:0x[a-z0-9]*]] 
+// CHECK-NEXT: |   `-ReturnStmt [[ADDR_12:0x[a-z0-9]*]] 
+// CHECK-NEXT: | `-IntegerLiteral [[ADDR_13:0x[a-z0-9]*]]  'int' 2
+// CHECK-NEXT: |-FunctionDecl [[ADDR_14:0x[a-z0-9]*]]  col:5 implicit also_after 'int (int)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_15:0x[a-z0-9]*]]  col:19 'int'
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_16:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(100): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_17:0x[a-z0-9]*]]  'int (int)' Function [[ADDR_18:0x[a-z0-9]*]] 'also_after[implementation={vendor(llvm)}]' 'int (int)'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_18]]  line:13:1 also_after[implementation={vendor(llvm)}] 'int (int)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_15]]  col:19 'int'
+// CHECK-NEXT: | `-CompoundStmt [[ADDR_19:0x[a-z0-9]*]] 
+// CHECK-NEXT: |   `-ReturnStmt [[ADDR_20:0x[a-z0-9]*]] 
+// CHECK-NEXT: | `-IntegerLiteral [[ADDR_21:0x[a-z0-9]*]]  'int' 3
+// CHECK-NEXT: |-FunctionDecl [[ADDR_22:0x[a-z0-9]*]]  col:5 implicit used also_after 'int (double)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_23:0x[a-z0-9]*]]  col:22 'double'
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_24:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(100): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_25:0x[a-z0-9]*]]  'int (double)' Function [[ADDR_26:0x[a-z0-9]*]] 'also_after[implementation={vendor(llvm)}]' 'int (double)'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_26]]  line:16:1 also_after[implementation={vendor(llvm)}] 'int (double)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_23]]  col:22 'double'
+// CHECK-NEXT: | `-CompoundStmt [[ADDR_27:0x[a-z0-9]*]] 
+// CHECK-NEXT: |   `-ReturnStmt [[ADDR_28:0x[a-z0-9]*]] 
+// CHECK-NEXT: | `-IntegerLiteral [[ADDR_29:0x[a-z0-9]*]]  'int' 0
+// CHECK-NEXT: |-FunctionDecl [[ADDR_6]]  line:21:1 also_before[implementation={vendor(llvm)}] 'int ({{.*}})'
+// CHECK-NEXT: | `-CompoundStmt [[ADDR_30:0x[a-z0-9]*]] 
+// CHECK-NEXT: |   `-ReturnStmt [[ADDR_31:0x[a-z0-9]*]] 
+// CHECK-NEXT: | `-IntegerLiteral [[ADDR_32:0x[a-z0-9]*]]  'int' 0
+// CHECK-NEXT: |-FunctionDecl [[ADDR_33:0x[a-z0-9]*]] prev [[ADDR_7]]  line:26:5 also_after 'int ({{.*}})'
+// CHECK-NEXT: | |-CompoundStmt [[ADDR_34:0x[a-z0-9]*]] 
+// CHECK-NEXT: | | 

[PATCH] D77414: [OpenMP] Add match_{all,any,none} declare variant selector extensions.

2020-04-05 Thread Mike Rice via Phabricator via cfe-commits
mikerice added inline comments.



Comment at: clang/lib/Parse/ParseOpenMP.cpp:1823
 ASTContext  = Actions.getASTContext();
-TI.getAsVariantMatchInfo(ASTCtx, VMI, /* DeviceSetOnly */ true);
+TI.getAsVariantMatchInfo(ASTCtx, VMI);
 OMPContext OMPCtx(ASTCtx.getLangOpts().OpenMPIsDevice,

One of the lit tests fails because this is called before semantic checks on the 
score expression.  This function tries to evaluate the score as a constant and 
if it isn't will crash.  Probably not specific to this change but how can we 
deal with that?

```
int foo(void);
#pragma omp begin declare variant match(implementation={vendor(score(foo()) 
ibm)})
#pragma omp end declare variant
```



Comment at: llvm/lib/Frontend/OpenMP/OMPContext.cpp:161
+  bool WasFound) -> Optional /* Result */ {
+// For kind "any" a single match is enough but we ignore non-matched 
properties.
+if (MK == MK_ANY) {

Line too long?



Comment at: llvm/lib/Frontend/OpenMP/OMPContext.cpp:252
+ bool DeviceSetOnly) {
+  return isVariantApplicableInContextHelper(VMI, Ctx, nullptr, DeviceSetOnly);
 }

Comment on nullptr would be nice.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77414/new/

https://reviews.llvm.org/D77414



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


[clang] e9644e6 - DebugInfo: Fix default template parameter computation for dependent non-type template parameters

2020-04-05 Thread David Blaikie via cfe-commits

Author: David Blaikie
Date: 2020-04-05T16:31:30-07:00
New Revision: e9644e6f4f21e6b6177ef9085cdc9ed9f44b7783

URL: 
https://github.com/llvm/llvm-project/commit/e9644e6f4f21e6b6177ef9085cdc9ed9f44b7783
DIFF: 
https://github.com/llvm/llvm-project/commit/e9644e6f4f21e6b6177ef9085cdc9ed9f44b7783.diff

LOG: DebugInfo: Fix default template parameter computation for dependent 
non-type template parameters

This addresses the immediate bug, though in theory we could still
produce a default parameter for the DWARF in this test case - but other
cases will be definitely unachievable (you could have a default
parameter that cannot be evaluated - so long as the user overrode it
with another value rather than relying on that default)

Added: 


Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
clang/test/CodeGenCXX/debug-info-template-parameter.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 6d3c2ad66cdc..5f05323f61ef 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -1816,7 +1816,8 @@ CGDebugInfo::CollectTemplateParams(const 
TemplateParameterList *TPList,
   if (TPList && CGM.getCodeGenOpts().DwarfVersion >= 5)
 if (auto *templateType =
 dyn_cast_or_null(TPList->getParam(i)))
-  if (templateType->hasDefaultArgument())
+  if (templateType->hasDefaultArgument() &&
+  !templateType->getDefaultArgument()->isValueDependent())
 defaultParameter = llvm::APSInt::isSameValue(
 templateType->getDefaultArgument()->EvaluateKnownConstInt(
 CGM.getContext()),

diff  --git a/clang/test/CodeGenCXX/debug-info-template-parameter.cpp 
b/clang/test/CodeGenCXX/debug-info-template-parameter.cpp
index c38c535d8b06..fee6dfe8b898 100644
--- a/clang/test/CodeGenCXX/debug-info-template-parameter.cpp
+++ b/clang/test/CodeGenCXX/debug-info-template-parameter.cpp
@@ -8,24 +8,24 @@
 
 // CHECK: DILocalVariable(name: "f1", {{.*}}, type: ![[TEMPLATE_TYPE:[0-9]+]]
 // CHECK: [[TEMPLATE_TYPE]] = {{.*}}!DICompositeType({{.*}}, templateParams: 
![[F1_TYPE:[0-9]+]]
-// CHECK: [[F1_TYPE]] = !{![[FIRST:[0-9]+]], ![[SECOND:[0-9]+]], 
![[THIRD:[0-9]+]]}
+// CHECK: [[F1_TYPE]] = !{![[FIRST:[0-9]+]], ![[SECOND:[0-9]+]], 
![[THIRD:[0-9]+]], ![[FORTH:[0-9]+]]}
 // CHECK: [[FIRST]] = !DITemplateTypeParameter(name: "T", type: !{{[0-9]*}})
 // CHECK: [[SECOND]] = !DITemplateValueParameter(name: "i", type: !{{[0-9]*}}, 
value: i32 6)
 // CHECK: [[THIRD]] = !DITemplateValueParameter(name: "b", type: !{{[0-9]*}}, 
value: i8 0)
 
 // CHECK: DILocalVariable(name: "f2", {{.*}}, type: ![[TEMPLATE_TYPE:[0-9]+]]
 // CHECK: [[TEMPLATE_TYPE]] = {{.*}}!DICompositeType({{.*}}, templateParams: 
![[F2_TYPE:[0-9]+]]
-// CHECK: [[F2_TYPE]] = !{![[FIRST:[0-9]+]], ![[SECOND:[0-9]+]], 
![[THIRD:[0-9]+]]}
+// CHECK: [[F2_TYPE]] = !{![[FIRST:[0-9]+]], ![[SECOND:[0-9]+]], 
![[THIRD:[0-9]+]], ![[FORTH:[0-9]+]]}
 // CHECK: [[FIRST]] = !DITemplateTypeParameter(name: "T", type: !{{[0-9]*}}, 
defaulted: true)
 // CHECK: [[SECOND]] = !DITemplateValueParameter(name: "i", type: !{{[0-9]*}}, 
defaulted: true, value: i32 3)
 // CHECK: [[THIRD]] = !DITemplateValueParameter(name: "b", type: !{{[0-9]*}}, 
defaulted: true, value: i8 1)
 
-template 
+template 
 class foo {
 };
 
 int main() {
-  foo f1;
+  foo f1;
   foo<> f2;
   return 0;
 }



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


[PATCH] D68115: Zero initialize padding in unions

2020-04-05 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

In D68115#1946990 , @jfb wrote:

> In D68115#1946757 , @rsmith wrote:
>
> > In D68115#1946668 , 
> > @hubert.reinterpretcast wrote:
> >
> > > It sounds like we are looking for `-fzero-union-padding`. That's been 
> > > where the discussion has left off twice for months.
> >
> >
> > I believe the state of Clang prior to this patch is actually wrong.
>
>
> That's my understanding as well. I'd like it if this patch (or a follow-up) 
> got us back to standard behavior. In either case, I'd like the proposed 
> behavior to bee on-by-default when doing initialization of stack variables.


Your preference is noted. However, I think the majority opinion expressed on 
this review at this point favors not guaranteeing zero-initialization except 
where required by the relevant standard. That'd also be consistent with our 
stance on trivial auto variable initialization in general.

I'm not yet sure about whether we want separate controls for this and for 
`-ftrivial-auto-init`, or whether from a user's perspective there's really only 
one question: should bits left uninitialized be `undef`, guaranteed zero, or 
guaranteed to be filled with a pattern -- independent of whether they're 
padding bits? (And related, do we actually want control over zeroing union 
padding in all cases or only for trivial automatic variables? And do we want 
control over zeroing or pattern-filling objects allocated with `new` with 
trivial initialization?)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68115/new/

https://reviews.llvm.org/D68115



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


Re: [libcxx-dev] [clang] 4ede887 - PR45402: Make the restrictions on constant evaluation of memcmp and

2020-04-05 Thread Richard Smith via cfe-commits
On Sun, 5 Apr 2020 at 15:41, David Zarzycki via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Subjectively speaking, using char8_t instead of char shouldn’t feel like a
> regression. So yes, making the builtin mem* functions work with char8_t
> again seems right. As for strlen, I can see arguments either way.
> Personally, if you’re concerned about clever macros, then I’d make the
> overload only visible in C++20 mode where char8_t was introduced.
>

I don't think that solves the problem. For example, the glibc headers do
clever things with __builtin_strlen (which they do, at least in some
cases), then this may still result in miscompiles. Eg, consider:

struct microseconds {
  operator const char*() { return "us"; }
  operator const char8_t*() { return "µs"; }
};
char buffer[32];
strcpy(buffer, microseconds());

This should compile, but won't if the implementation of strcpy is a macro
that calls __builtin_strlen (as it sometimes is with glibc). Worse would be
if the char8_t conversion function is preferred over the char conversion
function for some reason, where strcpy might expand to `memcpy(buffer,
microseconds(), __builtin_strlen(microseconds()))`, potentially resulting
in a buffer overflow (copying using the length of the char8_t string but
the content of the char string).

If we want to introduce a strlen builtin for char8_t, I think we should
give it a different name.

I've realized that my suggestion of using __builtin_memchr(p, 0) - p for
strlen doesn't actually work, for the usual reason that memchr is mostly
useless in constant expressions (because it returns a void*). So maybe we
should add a __builtin_memchr_char8_t to parallel the existing
__builtin_memchr_char, or maybe make __builtin_memchr_char overloaded on
character type?

-- 
> Sent from my iPhone
>
> On Apr 5, 2020, at 18:18, Richard Smith  wrote:
>
> 
> On Sun, 5 Apr 2020 at 14:44, David Zarzycki via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> We have overloaded builtins. Can that not solve __builtin_strlen?
>>
>
> I suppose it could, but we generally want __builtin_ to behave
> the same as . (The difference would not be visible most of the
> time, but there's enough pre-existing use of __builtin_strlen through
> "clever" macros and the like that I'd be worried that this would break
> something important.) Maybe we should just make the mem* functions work
> again for char8_t; then you can use __builtin_memchr(p,  0) - p as an
> optimized compile-time strlen.
>
>
>> --
>> Sent from my iPhone
>>
>> On Apr 5, 2020, at 14:53, Richard Smith  wrote:
>>
>> 
>> Thanks. We need to figure out what the right way to support char8_t with
>> string builtins is. These ones could work in principle, whereas things like
>> __builtin_strlen would never work because they take operands of the wrong
>> types (and we can't cast const char8_t* -> const char* in a constant
>> expression).
>>
>> On Sun, 5 Apr 2020 at 04:14, David Zarzycki via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi Richard,
>>>
>>> I'm going to commit a narrow fix to clang to make the libcxx test suite
>>> pass again by allowing char8_t again. If you feel that this is the wrong
>>> long-term solution, please help the libcxx folks with whatever adjustments
>>> they need.
>>>
>>> Thanks!
>>>
>>> Dave
>>>
>>>
>>> On Sat, Apr 4, 2020, at 9:55 AM, David Zarzycki via libcxx-dev wrote:
>>> > Hi Richard,
>>> >
>>> > This breaks libcxx. Can we please revert this or is a quick fix to
>>> > libcxx possible?
>>> >
>>> >
>>> > FAIL: libc++ ::
>>> >
>>> std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp
>>> (58624 of 62672)
>>> >  TEST 'libc++ ::
>>> >
>>> std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp'
>>> FAILED 
>>> > Command: ['/p/tllvm/bin/clang++', '-o',
>>> >
>>> '/tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/Output/compare.pass.cpp.o',
>>> '-x', 'c++',
>>> '/home/dave/s/lp/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp',
>>> '-c', '-v', '-Werror=thread-safety', '-std=c++2a', '-include',
>>> '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', '-nostdinc++',
>>> '-I/home/dave/s/lp/libcxx/include',
>>> '-I/tmp/_update_lc/t/projects/libcxx/include/c++build',
>>> '-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS',
>>> '-D__STDC_CONSTANT_MACROS', '-I/home/dave/s/lp/libcxx/test/support',
>>> '-ftemplate-depth=270', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall',
>>> '-Wextra', '-Werror', '-Wuser-defined-warnings', '-Wshadow',
>>> '-Wno-unused-command-line-argument', '-Wno-attributes',
>>> '-Wno-pessimizing-move', '-Wno-c++11-extensions',
>>> '-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare',
>>> '-Wunused-variable', '-Wunused-parameter', 

Re: [libcxx-dev] [clang] 4ede887 - PR45402: Make the restrictions on constant evaluation of memcmp and

2020-04-05 Thread David Zarzycki via cfe-commits
Subjectively speaking, using char8_t instead of char shouldn’t feel like a 
regression. So yes, making the builtin mem* functions work with char8_t again 
seems right. As for strlen, I can see arguments either way. Personally, if 
you’re concerned about clever macros, then I’d make the overload only visible 
in C++20 mode where char8_t was introduced.

-- 
Sent from my iPhone

> On Apr 5, 2020, at 18:18, Richard Smith  wrote:
> 
> 
>> On Sun, 5 Apr 2020 at 14:44, David Zarzycki via cfe-commits 
>>  wrote:
> 
>> We have overloaded builtins. Can that not solve __builtin_strlen?
> 
> I suppose it could, but we generally want __builtin_ to behave the 
> same as . (The difference would not be visible most of the time, but 
> there's enough pre-existing use of __builtin_strlen through "clever" macros 
> and the like that I'd be worried that this would break something important.) 
> Maybe we should just make the mem* functions work again for char8_t; then you 
> can use __builtin_memchr(p,  0) - p as an optimized compile-time strlen.
>  
>> -- 
>> Sent from my iPhone
>> 
 On Apr 5, 2020, at 14:53, Richard Smith  wrote:
 
>>> 
>>> Thanks. We need to figure out what the right way to support char8_t with 
>>> string builtins is. These ones could work in principle, whereas things like 
>>> __builtin_strlen would never work because they take operands of the wrong 
>>> types (and we can't cast const char8_t* -> const char* in a constant 
>>> expression).
>>> 
 On Sun, 5 Apr 2020 at 04:14, David Zarzycki via cfe-commits 
  wrote:
 Hi Richard,
 
 I'm going to commit a narrow fix to clang to make the libcxx test suite 
 pass again by allowing char8_t again. If you feel that this is the wrong 
 long-term solution, please help the libcxx folks with whatever adjustments 
 they need.
 
 Thanks!
 
 Dave
 
 
 On Sat, Apr 4, 2020, at 9:55 AM, David Zarzycki via libcxx-dev wrote:
 > Hi Richard,
 > 
 > This breaks libcxx. Can we please revert this or is a quick fix to 
 > libcxx possible?
 > 
 > 
 > FAIL: libc++ :: 
 > std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp
 >  (58624 of 62672)
 >  TEST 'libc++ :: 
 > std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp'
 >  FAILED 
 > Command: ['/p/tllvm/bin/clang++', '-o', 
 > '/tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/Output/compare.pass.cpp.o',
 >  '-x', 'c++', 
 > '/home/dave/s/lp/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp',
 >  '-c', '-v', '-Werror=thread-safety', '-std=c++2a', '-include', 
 > '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', '-nostdinc++', 
 > '-I/home/dave/s/lp/libcxx/include', 
 > '-I/tmp/_update_lc/t/projects/libcxx/include/c++build', 
 > '-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS', 
 > '-D__STDC_CONSTANT_MACROS', '-I/home/dave/s/lp/libcxx/test/support', 
 > '-ftemplate-depth=270', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', 
 > '-Wall', '-Wextra', '-Werror', '-Wuser-defined-warnings', '-Wshadow', 
 > '-Wno-unused-command-line-argument', '-Wno-attributes', 
 > '-Wno-pessimizing-move', '-Wno-c++11-extensions', 
 > '-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare', 
 > '-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', '-c']
 > Exit Code: 1
 > Standard Error:
 > --
 > clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
 > 22127da8f17c03c69231f3631472f7f99ad9cb7f)
 > Target: x86_64-unknown-linux-gnu
 > Thread model: posix
 > InstalledDir: /p/tllvm/bin
 > Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
 > Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
 > Candidate multilib: .;@m64
 > Candidate multilib: 32;@m32
 > Selected multilib: .;@m64
 >  (in-process)
 >  "/p/tllvm/bin/clang-11" -cc1 -triple x86_64-unknown-linux-gnu 
 > -emit-obj -mrelax-all -disable-free -disable-llvm-verifier 
 > -discard-value-names -main-file-name compare.pass.cpp 
 > -mrelocation-model static -mthread-model posix -mframe-pointer=all 
 > -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables 
 > -target-cpu x86-64 -dwarf-column-info -fno-split-dwarf-inlining 
 > -debugger-tuning=gdb -v -nostdinc++ -resource-dir 
 > /p/tllvm/lib64/clang/11.0.0 -include 
 > /home/dave/s/lp/libcxx/test/support/nasty_macros.h -I 
 > /home/dave/s/lp/libcxx/include -I 
 > /tmp/_update_lc/t/projects/libcxx/include/c++build -D 
 > __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS 
 > -I 

[clang] 944db8a - Permit constant evaluation of mixed __builtin_memcmp between char and

2020-04-05 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2020-04-05T15:35:32-07:00
New Revision: 944db8a433f591e514219c12fa33b7e8fdd5e883

URL: 
https://github.com/llvm/llvm-project/commit/944db8a433f591e514219c12fa33b7e8fdd5e883
DIFF: 
https://github.com/llvm/llvm-project/commit/944db8a433f591e514219c12fa33b7e8fdd5e883.diff

LOG: Permit constant evaluation of mixed __builtin_memcmp between char and
char8_t.

Added: 


Modified: 
clang/lib/AST/ExprConstant.cpp
clang/test/SemaCXX/constexpr-string.cpp

Removed: 




diff  --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index a10a4dab6dff..35232bebbb3a 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -8319,6 +8319,12 @@ bool PointerExprEvaluator::VisitCallExpr(const CallExpr 
*E) {
   return visitNonBuiltinCallExpr(E);
 }
 
+// Determine if T is a character type for which we guarantee that
+// sizeof(T) == 1.
+static bool isOneByteCharacterType(QualType T) {
+  return T->isCharType() || T->isChar8Type();
+}
+
 bool PointerExprEvaluator::VisitBuiltinCallExpr(const CallExpr *E,
 unsigned BuiltinOp) {
   switch (BuiltinOp) {
@@ -8469,7 +8475,7 @@ bool PointerExprEvaluator::VisitBuiltinCallExpr(const 
CallExpr *E,
 }
 // Give up on byte-oriented matching against multibyte elements.
 // FIXME: We can compare the bytes in the correct order.
-if (IsRawByte && !CharTy->isCharType() && !CharTy->isChar8Type()) {
+if (IsRawByte && !isOneByteCharacterType(CharTy)) {
   Info.FFDiag(E, diag::note_constexpr_memchr_unsupported)
   << (std::string("'") + Info.Ctx.BuiltinInfo.getName(BuiltinOp) + "'")
   << CharTy;
@@ -11156,9 +11162,8 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const 
CallExpr *E,
 
 // For memcmp, allow comparing any arrays of '[[un]signed] char' or
 // 'char8_t', but no other types.
-bool IsChar = CharTy1->isCharType() && CharTy2->isCharType();
-bool IsChar8 = CharTy1->isChar8Type() && CharTy2->isChar8Type();
-if (IsRawByte && !IsChar && !IsChar8) {
+if (IsRawByte &&
+!(isOneByteCharacterType(CharTy1) && isOneByteCharacterType(CharTy2))) 
{
   // FIXME: Consider using our bit_cast implementation to support this.
   Info.FFDiag(E, diag::note_constexpr_memcmp_unsupported)
   << (std::string("'") + Info.Ctx.BuiltinInfo.getName(BuiltinOp) + "'")

diff  --git a/clang/test/SemaCXX/constexpr-string.cpp 
b/clang/test/SemaCXX/constexpr-string.cpp
index b9f90adf7b76..f33627e812b2 100644
--- a/clang/test/SemaCXX/constexpr-string.cpp
+++ b/clang/test/SemaCXX/constexpr-string.cpp
@@ -118,6 +118,9 @@ namespace StrcmpEtc {
   static_assert(__builtin_memcmp(u8"abab\0banana", u8"abab\0canada", 6) == -1);
   static_assert(__builtin_memcmp(u8"abab\0banana", u8"abab\0canada", 5) == 0);
 
+  static_assert(__builtin_memcmp(u8"\u1234", "\xE1\x88\xB4", 4) == 0);
+  static_assert(__builtin_memcmp(u8"\u1234", "\xE1\x88\xB3", 4) == 1);
+
   static_assert(__builtin_bcmp("abaa", "abba", 3) != 0);
   static_assert(__builtin_bcmp("abaa", "abba", 2) == 0);
   static_assert(__builtin_bcmp("a\203", "a", 2) != 0);



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


Re: [libcxx-dev] [clang] 4ede887 - PR45402: Make the restrictions on constant evaluation of memcmp and

2020-04-05 Thread Richard Smith via cfe-commits
On Sun, 5 Apr 2020 at 15:17, Richard Smith  wrote:

> On Sun, 5 Apr 2020 at 14:44, David Zarzycki via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> We have overloaded builtins. Can that not solve __builtin_strlen?
>>
>
> I suppose it could, but we generally want __builtin_ to behave
> the same as . (The difference would not be visible most of the
> time, but there's enough pre-existing use of __builtin_strlen through
> "clever" macros and the like that I'd be worried that this would break
> something important.) Maybe we should just make the mem* functions work
> again for char8_t; then you can use __builtin_memchr(p,  0) - p as an
> optimized compile-time strlen.
>

I see you already did this for memcmp in llvmorg-11-init-7822-g2c88a485c71
:)
I added documentation and testing and extended this to also cover memchr
in llvmorg-11-init-7851-g7f24db01751.


>
>> --
>> Sent from my iPhone
>>
>> On Apr 5, 2020, at 14:53, Richard Smith  wrote:
>>
>> 
>> Thanks. We need to figure out what the right way to support char8_t with
>> string builtins is. These ones could work in principle, whereas things like
>> __builtin_strlen would never work because they take operands of the wrong
>> types (and we can't cast const char8_t* -> const char* in a constant
>> expression).
>>
>> On Sun, 5 Apr 2020 at 04:14, David Zarzycki via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi Richard,
>>>
>>> I'm going to commit a narrow fix to clang to make the libcxx test suite
>>> pass again by allowing char8_t again. If you feel that this is the wrong
>>> long-term solution, please help the libcxx folks with whatever adjustments
>>> they need.
>>>
>>> Thanks!
>>>
>>> Dave
>>>
>>>
>>> On Sat, Apr 4, 2020, at 9:55 AM, David Zarzycki via libcxx-dev wrote:
>>> > Hi Richard,
>>> >
>>> > This breaks libcxx. Can we please revert this or is a quick fix to
>>> > libcxx possible?
>>> >
>>> >
>>> > FAIL: libc++ ::
>>> >
>>> std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp
>>> (58624 of 62672)
>>> >  TEST 'libc++ ::
>>> >
>>> std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp'
>>> FAILED 
>>> > Command: ['/p/tllvm/bin/clang++', '-o',
>>> >
>>> '/tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/Output/compare.pass.cpp.o',
>>> '-x', 'c++',
>>> '/home/dave/s/lp/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp',
>>> '-c', '-v', '-Werror=thread-safety', '-std=c++2a', '-include',
>>> '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', '-nostdinc++',
>>> '-I/home/dave/s/lp/libcxx/include',
>>> '-I/tmp/_update_lc/t/projects/libcxx/include/c++build',
>>> '-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS',
>>> '-D__STDC_CONSTANT_MACROS', '-I/home/dave/s/lp/libcxx/test/support',
>>> '-ftemplate-depth=270', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall',
>>> '-Wextra', '-Werror', '-Wuser-defined-warnings', '-Wshadow',
>>> '-Wno-unused-command-line-argument', '-Wno-attributes',
>>> '-Wno-pessimizing-move', '-Wno-c++11-extensions',
>>> '-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare',
>>> '-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', '-c']
>>> > Exit Code: 1
>>> > Standard Error:
>>> > --
>>> > clang version 11.0.0 (https://github.com/llvm/llvm-project.git
>>> > 22127da8f17c03c69231f3631472f7f99ad9cb7f)
>>> > Target: x86_64-unknown-linux-gnu
>>> > Thread model: posix
>>> > InstalledDir: /p/tllvm/bin
>>> > Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
>>> > Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
>>> > Candidate multilib: .;@m64
>>> > Candidate multilib: 32;@m32
>>> > Selected multilib: .;@m64
>>> >  (in-process)
>>> >  "/p/tllvm/bin/clang-11" -cc1 -triple x86_64-unknown-linux-gnu
>>> > -emit-obj -mrelax-all -disable-free -disable-llvm-verifier
>>> > -discard-value-names -main-file-name compare.pass.cpp
>>> > -mrelocation-model static -mthread-model posix -mframe-pointer=all
>>> > -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables
>>> > -target-cpu x86-64 -dwarf-column-info -fno-split-dwarf-inlining
>>> > -debugger-tuning=gdb -v -nostdinc++ -resource-dir
>>> > /p/tllvm/lib64/clang/11.0.0 -include
>>> > /home/dave/s/lp/libcxx/test/support/nasty_macros.h -I
>>> > /home/dave/s/lp/libcxx/include -I
>>> > /tmp/_update_lc/t/projects/libcxx/include/c++build -D
>>> > __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS
>>> > -I /home/dave/s/lp/libcxx/test/support -D
>>> > _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -internal-isystem
>>> > /usr/local/include -internal-isystem
>>> > /p/tllvm/lib64/clang/11.0.0/include -internal-externc-isystem /include
>>> > -internal-externc-isystem /usr/include -Werror=thread-safety -Wall
>>> > -Wextra -Werror 

[clang] 7f24db0 - Add documentation and testing for

2020-04-05 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2020-04-05T15:24:49-07:00
New Revision: 7f24db01751da6953782630bb42dcca8a111590b

URL: 
https://github.com/llvm/llvm-project/commit/7f24db01751da6953782630bb42dcca8a111590b
DIFF: 
https://github.com/llvm/llvm-project/commit/7f24db01751da6953782630bb42dcca8a111590b.diff

LOG: Add documentation and testing for
2c88a485c71155c19e512f22c54e63ee337282a3.

Also extend it to cover memchr for consistency.

Added: 


Modified: 
clang/docs/LanguageExtensions.rst
clang/lib/AST/ExprConstant.cpp
clang/test/SemaCXX/constexpr-string.cpp

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 6dcfd1a49f06..f83d7cff9c87 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -2368,8 +2368,8 @@ constant expressions in C++11 onwards (where a cast from 
``void*`` to ``char*``
 is disallowed in general).
 
 Constant evaluation support for the ``__builtin_mem*`` functions is provided
-only for arrays of ``char``, ``signed char``, or ``unsigned char``, despite
-these functions accepting an argument of type ``const void*``.
+only for arrays of ``char``, ``signed char``, ``unsigned char``, or 
``char8_t``,
+despite these functions accepting an argument of type ``const void*``.
 
 Support for constant expression evaluation for the above builtins can be 
detected
 with ``__has_feature(cxx_constexpr_string_builtins)``.

diff  --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index 7508bcbc365d..a10a4dab6dff 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -8469,7 +8469,7 @@ bool PointerExprEvaluator::VisitBuiltinCallExpr(const 
CallExpr *E,
 }
 // Give up on byte-oriented matching against multibyte elements.
 // FIXME: We can compare the bytes in the correct order.
-if (IsRawByte && !CharTy->isCharType()) {
+if (IsRawByte && !CharTy->isCharType() && !CharTy->isChar8Type()) {
   Info.FFDiag(E, diag::note_constexpr_memchr_unsupported)
   << (std::string("'") + Info.Ctx.BuiltinInfo.getName(BuiltinOp) + "'")
   << CharTy;

diff  --git a/clang/test/SemaCXX/constexpr-string.cpp 
b/clang/test/SemaCXX/constexpr-string.cpp
index 79ac3bf2cc4d..b9f90adf7b76 100644
--- a/clang/test/SemaCXX/constexpr-string.cpp
+++ b/clang/test/SemaCXX/constexpr-string.cpp
@@ -107,6 +107,17 @@ namespace StrcmpEtc {
   static_assert(__builtin_memcmp("abab\0banana", "abab\0canada", 6) == -1);
   static_assert(__builtin_memcmp("abab\0banana", "abab\0canada", 5) == 0);
 
+  static_assert(__builtin_memcmp(u8"abaa", u8"abba", 3) == -1);
+  static_assert(__builtin_memcmp(u8"abaa", u8"abba", 2) == 0);
+  static_assert(__builtin_memcmp(u8"a\203", u8"a", 2) == 1);
+  static_assert(__builtin_memcmp(u8"a\203", u8"a\003", 2) == 1);
+  static_assert(__builtin_memcmp(0, 0, 0) == 0);
+  static_assert(__builtin_memcmp(u8"abab\0banana", u8"abab\0banana", 100) == 
0); // expected-error {{not an integral constant}} expected-note {{dereferenced 
one-past-the-end}}
+  static_assert(__builtin_memcmp(u8"abab\0banana", u8"abab\0canada", 100) == 
-1); // FIXME: Should we reject this?
+  static_assert(__builtin_memcmp(u8"abab\0banana", u8"abab\0canada", 7) == -1);
+  static_assert(__builtin_memcmp(u8"abab\0banana", u8"abab\0canada", 6) == -1);
+  static_assert(__builtin_memcmp(u8"abab\0banana", u8"abab\0canada", 5) == 0);
+
   static_assert(__builtin_bcmp("abaa", "abba", 3) != 0);
   static_assert(__builtin_bcmp("abaa", "abba", 2) == 0);
   static_assert(__builtin_bcmp("a\203", "a", 2) != 0);
@@ -373,6 +384,20 @@ namespace StrchrEtc {
   static_assert(__builtin_memchr(nullptr, 'x', 3) == nullptr); // 
expected-error {{not an integral constant}} expected-note {{dereferenced null}}
   static_assert(__builtin_memchr(nullptr, 'x', 0) == nullptr); // FIXME: 
Should we reject this?
 
+  constexpr const char8_t *kU8Str = u8"abca\xff\0d";
+  constexpr char8_t kU8Foo[] = {u8'f', u8'o', u8'o'};
+  static_assert(__builtin_memchr(kU8Str, u8'a', 0) == nullptr);
+  static_assert(__builtin_memchr(kU8Str, u8'a', 1) == kU8Str);
+  static_assert(__builtin_memchr(kU8Str, u8'\0', 5) == nullptr);
+  static_assert(__builtin_memchr(kU8Str, u8'\0', 6) == kU8Str + 5);
+  static_assert(__builtin_memchr(kU8Str, u8'\xff', 8) == kU8Str + 4);
+  static_assert(__builtin_memchr(kU8Str, u8'\xff' + 256, 8) == kU8Str + 4);
+  static_assert(__builtin_memchr(kU8Str, u8'\xff' - 256, 8) == kU8Str + 4);
+  static_assert(__builtin_memchr(kU8Foo, u8'x', 3) == nullptr);
+  static_assert(__builtin_memchr(kU8Foo, u8'x', 4) == nullptr); // 
expected-error {{not an integral constant}} expected-note {{dereferenced 
one-past-the-end}}
+  static_assert(__builtin_memchr(nullptr, u8'x', 3) == nullptr); // 
expected-error {{not an integral constant}} expected-note {{dereferenced null}}
+  static_assert(__builtin_memchr(nullptr, u8'x', 

Re: [libcxx-dev] [clang] 4ede887 - PR45402: Make the restrictions on constant evaluation of memcmp and

2020-04-05 Thread Richard Smith via cfe-commits
On Sun, 5 Apr 2020 at 14:44, David Zarzycki via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> We have overloaded builtins. Can that not solve __builtin_strlen?
>

I suppose it could, but we generally want __builtin_ to behave the
same as . (The difference would not be visible most of the time,
but there's enough pre-existing use of __builtin_strlen through "clever"
macros and the like that I'd be worried that this would break something
important.) Maybe we should just make the mem* functions work again for
char8_t; then you can use __builtin_memchr(p,  0) - p as an optimized
compile-time strlen.


> --
> Sent from my iPhone
>
> On Apr 5, 2020, at 14:53, Richard Smith  wrote:
>
> 
> Thanks. We need to figure out what the right way to support char8_t with
> string builtins is. These ones could work in principle, whereas things like
> __builtin_strlen would never work because they take operands of the wrong
> types (and we can't cast const char8_t* -> const char* in a constant
> expression).
>
> On Sun, 5 Apr 2020 at 04:14, David Zarzycki via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Richard,
>>
>> I'm going to commit a narrow fix to clang to make the libcxx test suite
>> pass again by allowing char8_t again. If you feel that this is the wrong
>> long-term solution, please help the libcxx folks with whatever adjustments
>> they need.
>>
>> Thanks!
>>
>> Dave
>>
>>
>> On Sat, Apr 4, 2020, at 9:55 AM, David Zarzycki via libcxx-dev wrote:
>> > Hi Richard,
>> >
>> > This breaks libcxx. Can we please revert this or is a quick fix to
>> > libcxx possible?
>> >
>> >
>> > FAIL: libc++ ::
>> >
>> std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp
>> (58624 of 62672)
>> >  TEST 'libc++ ::
>> >
>> std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp'
>> FAILED 
>> > Command: ['/p/tllvm/bin/clang++', '-o',
>> >
>> '/tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/Output/compare.pass.cpp.o',
>> '-x', 'c++',
>> '/home/dave/s/lp/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp',
>> '-c', '-v', '-Werror=thread-safety', '-std=c++2a', '-include',
>> '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', '-nostdinc++',
>> '-I/home/dave/s/lp/libcxx/include',
>> '-I/tmp/_update_lc/t/projects/libcxx/include/c++build',
>> '-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS',
>> '-D__STDC_CONSTANT_MACROS', '-I/home/dave/s/lp/libcxx/test/support',
>> '-ftemplate-depth=270', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall',
>> '-Wextra', '-Werror', '-Wuser-defined-warnings', '-Wshadow',
>> '-Wno-unused-command-line-argument', '-Wno-attributes',
>> '-Wno-pessimizing-move', '-Wno-c++11-extensions',
>> '-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare',
>> '-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', '-c']
>> > Exit Code: 1
>> > Standard Error:
>> > --
>> > clang version 11.0.0 (https://github.com/llvm/llvm-project.git
>> > 22127da8f17c03c69231f3631472f7f99ad9cb7f)
>> > Target: x86_64-unknown-linux-gnu
>> > Thread model: posix
>> > InstalledDir: /p/tllvm/bin
>> > Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
>> > Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
>> > Candidate multilib: .;@m64
>> > Candidate multilib: 32;@m32
>> > Selected multilib: .;@m64
>> >  (in-process)
>> >  "/p/tllvm/bin/clang-11" -cc1 -triple x86_64-unknown-linux-gnu
>> > -emit-obj -mrelax-all -disable-free -disable-llvm-verifier
>> > -discard-value-names -main-file-name compare.pass.cpp
>> > -mrelocation-model static -mthread-model posix -mframe-pointer=all
>> > -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables
>> > -target-cpu x86-64 -dwarf-column-info -fno-split-dwarf-inlining
>> > -debugger-tuning=gdb -v -nostdinc++ -resource-dir
>> > /p/tllvm/lib64/clang/11.0.0 -include
>> > /home/dave/s/lp/libcxx/test/support/nasty_macros.h -I
>> > /home/dave/s/lp/libcxx/include -I
>> > /tmp/_update_lc/t/projects/libcxx/include/c++build -D
>> > __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS
>> > -I /home/dave/s/lp/libcxx/test/support -D
>> > _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -internal-isystem
>> > /usr/local/include -internal-isystem
>> > /p/tllvm/lib64/clang/11.0.0/include -internal-externc-isystem /include
>> > -internal-externc-isystem /usr/include -Werror=thread-safety -Wall
>> > -Wextra -Werror -Wuser-defined-warnings -Wshadow
>> > -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move
>> > -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type
>> > -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code
>> > -std=c++2a -fdeprecated-macro -fdebug-compilation-dir
>> >
>> 

[PATCH] D77484: [Vector] Pass VectLib to LTO backend so TLI build correct vector function list

2020-04-05 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

In D77484#1962667 , @wenlei wrote:

> > Linking against two vectlibs may cause name conflicts or other issues.
>
> Of all three supported match libraries, all functions from Accelerate are 
> prefixed with `v`; all MASS library functions are suffixed with `_massv`; and 
> all SVML functions are prefixed with `__svml_`. See `VecFuncs.def`. So at 
> least the exported functions don't have name conflicts.


Ok then it does sound like these could be handled on a per-function basis, 
similar to how -fno-builtin* are handled. I.e. a function attribute to indicate 
the veclib, which would then be naturally preserved during LTO even after 
merging/importing across modules. Similar to how -fno-builtin* are handled, 
these would need to be examined when inlining (see the new 
TargetLibraryInfo::areInlineCompatible). Presumably we would want to block 
inlining between functions with different veclib attributes in the LTO backends.

> 
> 
>> What happens today in a non-LTO build if conflicting veclib options are 
>> provided to different TUs?
> 
> I think it will work, as long as used math libraries are all provided to 
> linker. Even if not, I'm not sure if this is something we want to actively 
> prevent from the use of fvectlib switch. fvectlib controls codegen/optimizer, 
> and whether the resulting codegen can leads to linking problem (if any), is 
> kind of orthogonal, and probably no different from a regular linking/symbol 
> resolution problem if there're conflicts in the libraries provide.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77484/new/

https://reviews.llvm.org/D77484



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


Re: [libcxx-dev] [clang] 4ede887 - PR45402: Make the restrictions on constant evaluation of memcmp and

2020-04-05 Thread David Zarzycki via cfe-commits
We have overloaded builtins. Can that not solve __builtin_strlen?

-- 
Sent from my iPhone

> On Apr 5, 2020, at 14:53, Richard Smith  wrote:
> 
> 
> Thanks. We need to figure out what the right way to support char8_t with 
> string builtins is. These ones could work in principle, whereas things like 
> __builtin_strlen would never work because they take operands of the wrong 
> types (and we can't cast const char8_t* -> const char* in a constant 
> expression).
> 
>> On Sun, 5 Apr 2020 at 04:14, David Zarzycki via cfe-commits 
>>  wrote:
>> Hi Richard,
>> 
>> I'm going to commit a narrow fix to clang to make the libcxx test suite pass 
>> again by allowing char8_t again. If you feel that this is the wrong 
>> long-term solution, please help the libcxx folks with whatever adjustments 
>> they need.
>> 
>> Thanks!
>> 
>> Dave
>> 
>> 
>> On Sat, Apr 4, 2020, at 9:55 AM, David Zarzycki via libcxx-dev wrote:
>> > Hi Richard,
>> > 
>> > This breaks libcxx. Can we please revert this or is a quick fix to 
>> > libcxx possible?
>> > 
>> > 
>> > FAIL: libc++ :: 
>> > std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp
>> >  (58624 of 62672)
>> >  TEST 'libc++ :: 
>> > std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp'
>> >  FAILED 
>> > Command: ['/p/tllvm/bin/clang++', '-o', 
>> > '/tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/Output/compare.pass.cpp.o',
>> >  '-x', 'c++', 
>> > '/home/dave/s/lp/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp',
>> >  '-c', '-v', '-Werror=thread-safety', '-std=c++2a', '-include', 
>> > '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', '-nostdinc++', 
>> > '-I/home/dave/s/lp/libcxx/include', 
>> > '-I/tmp/_update_lc/t/projects/libcxx/include/c++build', 
>> > '-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS', 
>> > '-D__STDC_CONSTANT_MACROS', '-I/home/dave/s/lp/libcxx/test/support', 
>> > '-ftemplate-depth=270', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall', 
>> > '-Wextra', '-Werror', '-Wuser-defined-warnings', '-Wshadow', 
>> > '-Wno-unused-command-line-argument', '-Wno-attributes', 
>> > '-Wno-pessimizing-move', '-Wno-c++11-extensions', 
>> > '-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare', 
>> > '-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', '-c']
>> > Exit Code: 1
>> > Standard Error:
>> > --
>> > clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
>> > 22127da8f17c03c69231f3631472f7f99ad9cb7f)
>> > Target: x86_64-unknown-linux-gnu
>> > Thread model: posix
>> > InstalledDir: /p/tllvm/bin
>> > Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
>> > Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
>> > Candidate multilib: .;@m64
>> > Candidate multilib: 32;@m32
>> > Selected multilib: .;@m64
>> >  (in-process)
>> >  "/p/tllvm/bin/clang-11" -cc1 -triple x86_64-unknown-linux-gnu 
>> > -emit-obj -mrelax-all -disable-free -disable-llvm-verifier 
>> > -discard-value-names -main-file-name compare.pass.cpp 
>> > -mrelocation-model static -mthread-model posix -mframe-pointer=all 
>> > -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables 
>> > -target-cpu x86-64 -dwarf-column-info -fno-split-dwarf-inlining 
>> > -debugger-tuning=gdb -v -nostdinc++ -resource-dir 
>> > /p/tllvm/lib64/clang/11.0.0 -include 
>> > /home/dave/s/lp/libcxx/test/support/nasty_macros.h -I 
>> > /home/dave/s/lp/libcxx/include -I 
>> > /tmp/_update_lc/t/projects/libcxx/include/c++build -D 
>> > __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS 
>> > -I /home/dave/s/lp/libcxx/test/support -D 
>> > _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -internal-isystem 
>> > /usr/local/include -internal-isystem 
>> > /p/tllvm/lib64/clang/11.0.0/include -internal-externc-isystem /include 
>> > -internal-externc-isystem /usr/include -Werror=thread-safety -Wall 
>> > -Wextra -Werror -Wuser-defined-warnings -Wshadow 
>> > -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move 
>> > -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type 
>> > -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code 
>> > -std=c++2a -fdeprecated-macro -fdebug-compilation-dir 
>> > /tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t
>> >  -ftemplate-depth 270 -ferror-limit 19 -fgnuc-version=4.2.1 
>> > -fno-implicit-modules -fcxx-exceptions -fexceptions -faddrsig -o 
>> > /tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/Output/compare.pass.cpp.o
>> >  -x c++ 
>> > 

[PATCH] D77507: [clangd] Fix HitMapping assertion in Tokens.cpp

2020-04-05 Thread Vince Bridgers via Phabricator via cfe-commits
vabridgers updated this revision to Diff 255193.
vabridgers added a comment.

Remove extraneous test case


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77507/new/

https://reviews.llvm.org/D77507

Files:
  clang/lib/Tooling/Syntax/Tokens.cpp
  clang/unittests/Tooling/Syntax/TokensTest.cpp


Index: clang/unittests/Tooling/Syntax/TokensTest.cpp
===
--- clang/unittests/Tooling/Syntax/TokensTest.cpp
+++ clang/unittests/Tooling/Syntax/TokensTest.cpp
@@ -484,6 +484,42 @@
 ['EMPTY'_9, 'EMPTY_FUNC'_10) => [''_0, ''_0)
 ['EMPTY_FUNC'_10, ''_18) => [''_0, ''_0)
 )"},
+  // Baseline case, bugz: https://bugs.llvm.org/show_bug.cgi?id=45428
+  {R"cpp(
+#define NUM 42
+#define M2(a1,...) {__VA_ARGS__;}
+#define M1(a2,...) M2(a2,__VA_ARGS__)
+void foo(void) { M1(0, NUM); }
+)cpp",
+   R"(expanded tokens:
+  void foo ( void ) { { 42 ; } ; }
+file './input.cpp'
+  spelled tokens:
+# define NUM 42 # define M2 ( a1 , ... ) { __VA_ARGS__ ; } # define M1 ( 
a2 , ... ) M2 ( a2 , __VA_ARGS__ ) void foo ( void ) { M1 ( 0 , NUM ) ; }
+  mappings:
+['#'_0, 'void'_30) => ['void'_0, 'void'_0)
+['M1'_36, ';'_42) => ['{'_6, ';'_10)
+)"},
+  // Reproducer, bugz: https://bugs.llvm.org/show_bug.cgi?id=45428.
+  // Causes mapping miss when invoking tryConsumeSpelledUntil
+  {R"cpp(
+#define NUM 42
+#define M2(a1,...) {__VA_ARGS__;}
+#define M1(a2,...) M2(a2,__VA_ARGS__)
+#define M0 M1 
+void foo(void) { M0(0, NUM); }
+)cpp",
+   R"(expanded tokens:
+  void foo ( void ) { { 42 ; } ; }
+file './input.cpp'
+  spelled tokens:
+# define NUM 42 # define M2 ( a1 , ... ) { __VA_ARGS__ ; } # define M1 ( 
a2 , ... ) M2 ( a2 , __VA_ARGS__ ) # define M0 M1 void foo ( void ) { M0 ( 0 , 
NUM ) ; }
+  mappings:
+['#'_0, 'void'_34) => ['void'_0, 'void'_0)
+['M0'_40, 'NUM'_44) => ['{'_6, ';'_10)
+['NUM'_44, ')'_45) => [';'_10, ';'_10)
+[')'_45, ';'_46) => [';'_10, ';'_10)
+)"},
   // File ends with a macro replacement.
   {R"cpp(
 #define FOO 10+10;
Index: clang/lib/Tooling/Syntax/Tokens.cpp
===
--- clang/lib/Tooling/Syntax/Tokens.cpp
+++ clang/lib/Tooling/Syntax/Tokens.cpp
@@ -614,10 +614,7 @@
 unsigned MappingBegin = SpelledIndex;
 ++SpelledIndex;
 
-bool HitMapping =
-tryConsumeSpelledUntil(File, EndOffset + 1, SpelledIndex).hasValue();
-(void)HitMapping;
-assert(!HitMapping && "recursive macro expansion?");
+(void)tryConsumeSpelledUntil(File, EndOffset + 1, SpelledIndex).hasValue();
 
 TokenBuffer::Mapping M;
 M.BeginExpanded = BeginExpanded;


Index: clang/unittests/Tooling/Syntax/TokensTest.cpp
===
--- clang/unittests/Tooling/Syntax/TokensTest.cpp
+++ clang/unittests/Tooling/Syntax/TokensTest.cpp
@@ -484,6 +484,42 @@
 ['EMPTY'_9, 'EMPTY_FUNC'_10) => [''_0, ''_0)
 ['EMPTY_FUNC'_10, ''_18) => [''_0, ''_0)
 )"},
+  // Baseline case, bugz: https://bugs.llvm.org/show_bug.cgi?id=45428
+  {R"cpp(
+#define NUM 42
+#define M2(a1,...) {__VA_ARGS__;}
+#define M1(a2,...) M2(a2,__VA_ARGS__)
+void foo(void) { M1(0, NUM); }
+)cpp",
+   R"(expanded tokens:
+  void foo ( void ) { { 42 ; } ; }
+file './input.cpp'
+  spelled tokens:
+# define NUM 42 # define M2 ( a1 , ... ) { __VA_ARGS__ ; } # define M1 ( a2 , ... ) M2 ( a2 , __VA_ARGS__ ) void foo ( void ) { M1 ( 0 , NUM ) ; }
+  mappings:
+['#'_0, 'void'_30) => ['void'_0, 'void'_0)
+['M1'_36, ';'_42) => ['{'_6, ';'_10)
+)"},
+  // Reproducer, bugz: https://bugs.llvm.org/show_bug.cgi?id=45428.
+  // Causes mapping miss when invoking tryConsumeSpelledUntil
+  {R"cpp(
+#define NUM 42
+#define M2(a1,...) {__VA_ARGS__;}
+#define M1(a2,...) M2(a2,__VA_ARGS__)
+#define M0 M1 
+void foo(void) { M0(0, NUM); }
+)cpp",
+   R"(expanded tokens:
+  void foo ( void ) { { 42 ; } ; }
+file './input.cpp'
+  spelled tokens:
+# define NUM 42 # define M2 ( a1 , ... ) { __VA_ARGS__ ; } # define M1 ( a2 , ... ) M2 ( a2 , __VA_ARGS__ ) # define M0 M1 void foo ( void ) { M0 ( 0 , NUM ) ; }
+  mappings:
+['#'_0, 'void'_34) => ['void'_0, 'void'_0)
+['M0'_40, 'NUM'_44) => ['{'_6, ';'_10)
+['NUM'_44, ')'_45) => [';'_10, ';'_10)
+[')'_45, ';'_46) => [';'_10, ';'_10)
+)"},
   // File ends with a macro replacement.
   {R"cpp(
 #define FOO 10+10;
Index: clang/lib/Tooling/Syntax/Tokens.cpp
===
--- clang/lib/Tooling/Syntax/Tokens.cpp
+++ clang/lib/Tooling/Syntax/Tokens.cpp
@@ -614,10 +614,7 @@
 unsigned MappingBegin = SpelledIndex;
 ++SpelledIndex;
 
-bool HitMapping =
-tryConsumeSpelledUntil(File, EndOffset + 1, SpelledIndex).hasValue();
-

[PATCH] D77484: [Vector] Pass VectLib to LTO backend so TLI build correct vector function list

2020-04-05 Thread Wenlei He via Phabricator via cfe-commits
wenlei added a comment.

> Linking against two vectlibs may cause name conflicts or other issues.

Of all three supported match libraries, all functions from Accelerate are 
prefixed with `v`; all MASS library functions are suffixed with `_massv`; and 
all SVML functions are prefixed with `__svml_`. See `VecFuncs.def`. So at least 
the exported functions don't have name conflicts.

> What happens today in a non-LTO build if conflicting veclib options are 
> provided to different TUs?

I think it will work, as long as used math libraries are all provided to 
linker. Even if not, I'm not sure if this is something we want to actively 
prevent from the use of fvectlib switch. fvectlib controls codegen/optimizer, 
and whether the resulting codegen can leads to linking problem (if any), is 
kind of orthogonal, and probably no different from a regular linking/symbol 
resolution problem if there're conflicts in the libraries provide.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77484/new/

https://reviews.llvm.org/D77484



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


[PATCH] D77507: [clangd] Fix HitMapping assertion in Tokens.cpp

2020-04-05 Thread Vince Bridgers via Phabricator via cfe-commits
vabridgers created this revision.
vabridgers added reviewers: ilya-biryukov, sammccall.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman, jkorous, 
MaskRay.
Herald added a project: clang.

Extend test cases for tokens, and remove assertion that is unneeded and
hitting in Tokens.cpp.

Fixes Bugzilla https://bugs.llvm.org/show_bug.cgi?id=45428


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77507

Files:
  clang/lib/Tooling/Syntax/Tokens.cpp
  clang/unittests/Tooling/Syntax/TokensTest.cpp


Index: clang/unittests/Tooling/Syntax/TokensTest.cpp
===
--- clang/unittests/Tooling/Syntax/TokensTest.cpp
+++ clang/unittests/Tooling/Syntax/TokensTest.cpp
@@ -484,6 +484,57 @@
 ['EMPTY'_9, 'EMPTY_FUNC'_10) => [''_0, ''_0)
 ['EMPTY_FUNC'_10, ''_18) => [''_0, ''_0)
 )"},
+  // Baseline case, bugz: https://bugs.llvm.org/show_bug.cgi?id=45428
+  {R"cpp(
+#define NUM 42
+#define M2(a1,...) {__VA_ARGS__;}
+#define M1(a2,...) M2(a2,__VA_ARGS__)
+void foo(void) { M1(0, NUM); }
+)cpp",
+   R"(expanded tokens:
+  void foo ( void ) { { 42 ; } ; }
+file './input.cpp'
+  spelled tokens:
+# define NUM 42 # define M2 ( a1 , ... ) { __VA_ARGS__ ; } # define M1 ( 
a2 , ... ) M2 ( a2 , __VA_ARGS__ ) void foo ( void ) { M1 ( 0 , NUM ) ; }
+  mappings:
+['#'_0, 'void'_30) => ['void'_0, 'void'_0)
+['M1'_36, ';'_42) => ['{'_6, ';'_10)
+)"},
+  // Reproducer, bugz: https://bugs.llvm.org/show_bug.cgi?id=45428.
+  // Causes mapping miss when invoking tryConsumeSpelledUntil
+  {R"cpp(
+#define NUM 42
+#define M2(a1,...) {__VA_ARGS__;}
+#define M1(a2,...) M2(a2,__VA_ARGS__)
+#define M0 M1 
+void foo(void) { M0(0, NUM); }
+)cpp",
+   R"(expanded tokens:
+  void foo ( void ) { { 42 ; } ; }
+file './input.cpp'
+  spelled tokens:
+# define NUM 42 # define M2 ( a1 , ... ) { __VA_ARGS__ ; } # define M1 ( 
a2 , ... ) M2 ( a2 , __VA_ARGS__ ) # define M0 M1 void foo ( void ) { M0 ( 0 , 
NUM ) ; }
+  mappings:
+['#'_0, 'void'_34) => ['void'_0, 'void'_0)
+['M0'_40, 'NUM'_44) => ['{'_6, ';'_10)
+['NUM'_44, ')'_45) => [';'_10, ';'_10)
+[')'_45, ';'_46) => [';'_10, ';'_10)
+)"},
+  // Simplified version of new issue
+  {R"cpp(
+#define N 42 
+#define M0(a1) foo(a1)
+M0(N);
+)cpp",
+   R"(expanded tokens:
+  foo ( 42 ) ;
+file './input.cpp'
+  spelled tokens:
+# define N 42 # define M0 ( a1 ) foo ( a1 ) M0 ( N ) ;
+  mappings:
+['#'_0, 'M0'_14) => ['foo'_0, 'foo'_0)
+['M0'_14, ';'_18) => ['foo'_0, ';'_4)
+)"},
   // File ends with a macro replacement.
   {R"cpp(
 #define FOO 10+10;
Index: clang/lib/Tooling/Syntax/Tokens.cpp
===
--- clang/lib/Tooling/Syntax/Tokens.cpp
+++ clang/lib/Tooling/Syntax/Tokens.cpp
@@ -614,10 +614,7 @@
 unsigned MappingBegin = SpelledIndex;
 ++SpelledIndex;
 
-bool HitMapping =
-tryConsumeSpelledUntil(File, EndOffset + 1, SpelledIndex).hasValue();
-(void)HitMapping;
-assert(!HitMapping && "recursive macro expansion?");
+(void)tryConsumeSpelledUntil(File, EndOffset + 1, SpelledIndex).hasValue();
 
 TokenBuffer::Mapping M;
 M.BeginExpanded = BeginExpanded;


Index: clang/unittests/Tooling/Syntax/TokensTest.cpp
===
--- clang/unittests/Tooling/Syntax/TokensTest.cpp
+++ clang/unittests/Tooling/Syntax/TokensTest.cpp
@@ -484,6 +484,57 @@
 ['EMPTY'_9, 'EMPTY_FUNC'_10) => [''_0, ''_0)
 ['EMPTY_FUNC'_10, ''_18) => [''_0, ''_0)
 )"},
+  // Baseline case, bugz: https://bugs.llvm.org/show_bug.cgi?id=45428
+  {R"cpp(
+#define NUM 42
+#define M2(a1,...) {__VA_ARGS__;}
+#define M1(a2,...) M2(a2,__VA_ARGS__)
+void foo(void) { M1(0, NUM); }
+)cpp",
+   R"(expanded tokens:
+  void foo ( void ) { { 42 ; } ; }
+file './input.cpp'
+  spelled tokens:
+# define NUM 42 # define M2 ( a1 , ... ) { __VA_ARGS__ ; } # define M1 ( a2 , ... ) M2 ( a2 , __VA_ARGS__ ) void foo ( void ) { M1 ( 0 , NUM ) ; }
+  mappings:
+['#'_0, 'void'_30) => ['void'_0, 'void'_0)
+['M1'_36, ';'_42) => ['{'_6, ';'_10)
+)"},
+  // Reproducer, bugz: https://bugs.llvm.org/show_bug.cgi?id=45428.
+  // Causes mapping miss when invoking tryConsumeSpelledUntil
+  {R"cpp(
+#define NUM 42
+#define M2(a1,...) {__VA_ARGS__;}
+#define M1(a2,...) M2(a2,__VA_ARGS__)
+#define M0 M1 
+void foo(void) { M0(0, NUM); }
+)cpp",
+   R"(expanded tokens:
+  void foo ( void ) { { 42 ; } ; }
+file './input.cpp'
+  spelled tokens:
+# define NUM 42 # define M2 ( a1 , ... ) { __VA_ARGS__ ; } # define M1 ( a2 , ... ) M2 ( a2 , __VA_ARGS__ ) # define M0 M1 void foo ( void ) { M0 ( 0 , NUM ) ; }
+  mappings:
+['#'_0, 'void'_34) => ['void'_0, 'void'_0)
+['M0'_40, 'NUM'_44) => ['{'_6, ';'_10)

Re: [libcxx-dev] [clang] 4ede887 - PR45402: Make the restrictions on constant evaluation of memcmp and

2020-04-05 Thread Richard Smith via cfe-commits
Thanks. We need to figure out what the right way to support char8_t with
string builtins is. These ones could work in principle, whereas things like
__builtin_strlen would never work because they take operands of the wrong
types (and we can't cast const char8_t* -> const char* in a constant
expression).

On Sun, 5 Apr 2020 at 04:14, David Zarzycki via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi Richard,
>
> I'm going to commit a narrow fix to clang to make the libcxx test suite
> pass again by allowing char8_t again. If you feel that this is the wrong
> long-term solution, please help the libcxx folks with whatever adjustments
> they need.
>
> Thanks!
>
> Dave
>
>
> On Sat, Apr 4, 2020, at 9:55 AM, David Zarzycki via libcxx-dev wrote:
> > Hi Richard,
> >
> > This breaks libcxx. Can we please revert this or is a quick fix to
> > libcxx possible?
> >
> >
> > FAIL: libc++ ::
> >
> std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp
> (58624 of 62672)
> >  TEST 'libc++ ::
> >
> std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp'
> FAILED 
> > Command: ['/p/tllvm/bin/clang++', '-o',
> >
> '/tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/Output/compare.pass.cpp.o',
> '-x', 'c++',
> '/home/dave/s/lp/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp',
> '-c', '-v', '-Werror=thread-safety', '-std=c++2a', '-include',
> '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', '-nostdinc++',
> '-I/home/dave/s/lp/libcxx/include',
> '-I/tmp/_update_lc/t/projects/libcxx/include/c++build',
> '-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS',
> '-D__STDC_CONSTANT_MACROS', '-I/home/dave/s/lp/libcxx/test/support',
> '-ftemplate-depth=270', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall',
> '-Wextra', '-Werror', '-Wuser-defined-warnings', '-Wshadow',
> '-Wno-unused-command-line-argument', '-Wno-attributes',
> '-Wno-pessimizing-move', '-Wno-c++11-extensions',
> '-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare',
> '-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', '-c']
> > Exit Code: 1
> > Standard Error:
> > --
> > clang version 11.0.0 (https://github.com/llvm/llvm-project.git
> > 22127da8f17c03c69231f3631472f7f99ad9cb7f)
> > Target: x86_64-unknown-linux-gnu
> > Thread model: posix
> > InstalledDir: /p/tllvm/bin
> > Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
> > Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
> > Candidate multilib: .;@m64
> > Candidate multilib: 32;@m32
> > Selected multilib: .;@m64
> >  (in-process)
> >  "/p/tllvm/bin/clang-11" -cc1 -triple x86_64-unknown-linux-gnu
> > -emit-obj -mrelax-all -disable-free -disable-llvm-verifier
> > -discard-value-names -main-file-name compare.pass.cpp
> > -mrelocation-model static -mthread-model posix -mframe-pointer=all
> > -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables
> > -target-cpu x86-64 -dwarf-column-info -fno-split-dwarf-inlining
> > -debugger-tuning=gdb -v -nostdinc++ -resource-dir
> > /p/tllvm/lib64/clang/11.0.0 -include
> > /home/dave/s/lp/libcxx/test/support/nasty_macros.h -I
> > /home/dave/s/lp/libcxx/include -I
> > /tmp/_update_lc/t/projects/libcxx/include/c++build -D
> > __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS
> > -I /home/dave/s/lp/libcxx/test/support -D
> > _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -internal-isystem
> > /usr/local/include -internal-isystem
> > /p/tllvm/lib64/clang/11.0.0/include -internal-externc-isystem /include
> > -internal-externc-isystem /usr/include -Werror=thread-safety -Wall
> > -Wextra -Werror -Wuser-defined-warnings -Wshadow
> > -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move
> > -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type
> > -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code
> > -std=c++2a -fdeprecated-macro -fdebug-compilation-dir
> >
> /tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t
> -ftemplate-depth 270 -ferror-limit 19 -fgnuc-version=4.2.1
> -fno-implicit-modules -fcxx-exceptions -fexceptions -faddrsig -o
> /tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/Output/compare.pass.cpp.o
> -x c++
> /home/dave/s/lp/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp
> > clang -cc1 version 11.0.0 based upon LLVM 11.0.0git default target
> > x86_64-unknown-linux-gnu
> > ignoring nonexistent directory "/include"
> > #include "..." search starts here:
> > #include <...> search starts here:
> >  /home/dave/s/lp/libcxx/include
> >  

[PATCH] D71739: [WIP] Use operand bundles to encode alignment assumptions

2020-04-05 Thread Tyker via Phabricator via cfe-commits
Tyker added a comment.

In D71739#1961508 , @jdoerfert wrote:

> @lebedev.ri  We'd need to identify other uses of the alignment encoding 
> in-tree so we can replace them as well. Also, this patch uses not only the 
> alignment but also the offset in the operand bundle. We can either allow that 
> or encode the offset via a gep in the IR. I guess the latter is easier to 
> implement until we have more reasons to allow more complex operand bundles 
> (which we will need to have eventually).


for now i think we will stay with the current "simple" alignment assumptions in 
operand bundles. but we can improve it later.

> @Tyker Do you want to take this?

i am fine with taking this. but there is a few thing to do before this.

i think that this patch depends on a few things:

- add an API to build assumes from provided knowledge.
- update users of alignment assumptions.

and a few things that i would like to do before:

- finish patches currently in review.
- improve generation of assume with operand bundles to minimize duplicates and 
extra instructions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71739/new/

https://reviews.llvm.org/D71739



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


[PATCH] D77484: [Vector] Pass VectLib to LTO backend so TLI build correct vector function list

2020-04-05 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

In D77484#1962581 , @hoyFB wrote:

> In D77484#1962445 , @tejohnson wrote:
>
> > We're trying to move towards encoding all of this in the IR. And in fact, I 
> > recently implemented a series of patches to make the TLI to be built 
> > per-function, and along with some patches from @gchatelet to encode 
> > -fno-builtin* as function attributes, we now handle that part of the TLII 
> > with IR. See D67923  which is the last 
> > patch in the series. We should encode the vectlib as function attributes 
> > similarly, and just thread that through to the TLI.
>
>
> That's an interesting idea. How does the linkage work if two functions have 
> different vectlib attributes? Linking against two vectlibs may cause name 
> conflicts or other issues.


Actually this may be best encoded in a module metadata that with an error 
merging type, so that conflicting options get flagged. What happens today in a 
non-LTO build if conflicting veclib options are provided to different TUs?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77484/new/

https://reviews.llvm.org/D77484



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


[PATCH] D77028: [NFC] Refactor DeferredDiagsEmitter and skip redundant visit

2020-04-05 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: clang/lib/Sema/Sema.cpp:1508
   void checkFunc(SourceLocation Loc, FunctionDecl *FD) {
+auto DiagsCountIt = DiagsCount.find(FD);
 FunctionDecl *Caller = UseStack.empty() ? nullptr : UseStack.back();

yaxunl wrote:
> rjmccall wrote:
> > yaxunl wrote:
> > > rjmccall wrote:
> > > > yaxunl wrote:
> > > > > rjmccall wrote:
> > > > > > yaxunl wrote:
> > > > > > > rjmccall wrote:
> > > > > > > > It makes me a little uncomfortable to be holding an iterator 
> > > > > > > > this long while calling a fair amount of other stuff in the 
> > > > > > > > meantime.
> > > > > > > > 
> > > > > > > > Your use of DiagsCount is subtle enough that it really needs to 
> > > > > > > > be explained in some comments.  You're doing stuff 
> > > > > > > > conditionally based on both whether the entry exists but also 
> > > > > > > > whether it's non-zero.
> > > > > > > added comments
> > > > > > Okay, thanks for that.  Two points, then.  First, it looks like the 
> > > > > > count is really just a boolean for whether the function recursively 
> > > > > > triggers any diagnostics.   And second, can't it just be as simple 
> > > > > > as whether we've visited that function at all in a context that's 
> > > > > > forcing diagnostics to be emitted?  The logic seems to be to try to 
> > > > > > emit the diagnostics for each use-path, but why would we want that?
> > > > > For the second comment, we need to visit a function again for each 
> > > > > use-path because we need to report each use-path that triggers a 
> > > > > diagnostic, otherwise users will see a new error after they fix one 
> > > > > error, instead of seeing all the errors at once.
> > > > > 
> > > > > For the first comment, I will change the count to two flags: one for 
> > > > > the case where the function is not in device context, the other is 
> > > > > for the case where the function is in device context. This will allow 
> > > > > us to avoid redundant visits whether or not we are in a device 
> > > > > context.
> > > > > For the second comment, we need to visit a function again for each 
> > > > > use-path because we need to report each use-path that triggers a 
> > > > > diagnostic, otherwise users will see a new error after they fix one 
> > > > > error, instead of seeing all the errors at once.
> > > > 
> > > > This is not what we do in analogous cases where errors are triggered by 
> > > > a use, like in template instantiation.   The bug might be that the 
> > > > device program is using a function that it shouldn't be using, or the 
> > > > bug might be that a function that's supposed  to be usable from the 
> > > > device is written incorrectly.  In the former case, yes, not reporting 
> > > > the errors for each use-path may force the programmer to build multiple 
> > > > times to find all the problematic uses.  However, in the latter case 
> > > > you can easily end up emitting a massive number of errors that 
> > > > completely drowns out everything else.  It's also non-linear: the 
> > > > number of different use-paths of a particular function can be 
> > > > combinatoric.
> > > The deferred diagnostics fall into the first case mostly. 
> > > 
> > > Not all diagnostic messages happen in device host functions are deferred. 
> > > Most of diagnostic messages are emitted immediately, disregarding whether 
> > > the function is emitted or not. 
> > > 
> > > Only a few special types of diagnostic messages e.g. inline assembly 
> > > errors, exceptions, varags are deferred. This is because clang has to use 
> > > pragmas to make all functions device and host in some system headers to 
> > > be able to use them in device compilation, whereas some of these 
> > > functions will cause error only if they are emitted in device 
> > > compilation. Since we cannot change these headers, we have to defer such 
> > > diagnostics to the point where they are actually triggered. Therefore we 
> > > are mostly interested in "who is calling these functions" instead of the 
> > > diagnostics themselves.
> > > 
> > > For normal programs containing no diagnostics, the current approach 
> > > should sufficiently avoid all redundant visits and all functions will be 
> > > visited once.
> > > 
> > > The functions may be visited multiple times when there are deferred 
> > > diagnostics, however this should be limited by the maximum number of 
> > > errors.
> > Okay.  I understand the point now about being mostly concerned about using 
> > functions in headers.
> > 
> > My concern about visiting things a combinatorial number of times is less 
> > about generating an excessive number of errors and more about taking an 
> > excessive amount of time to finish compilation.  The compiler really should 
> > not be using any exponential algorithms; a simple visited set will ensure 
> > that, but I think what you're doing does not.  Can you make a case for why 
> > that's not true?
> The current approach 

[PATCH] D77484: [Vector] Pass VectLib to LTO backend so TLI build correct vector function list

2020-04-05 Thread Hongtao Yu via Phabricator via cfe-commits
hoyFB added a comment.

In D77484#1962445 , @tejohnson wrote:

> We're trying to move towards encoding all of this in the IR. And in fact, I 
> recently implemented a series of patches to make the TLI to be built 
> per-function, and along with some patches from @gchatelet to encode 
> -fno-builtin* as function attributes, we now handle that part of the TLII 
> with IR. See D67923  which is the last patch 
> in the series. We should encode the vectlib as function attributes similarly, 
> and just thread that through to the TLI.


That's an interesting idea. How does the linkage work if two functions have 
different vectlib attributes? Linking against two vectlibs may cause name 
conflicts or other issues.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77484/new/

https://reviews.llvm.org/D77484



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


Re: [clang] a8c8b62 - [ObjC generics] Fix not inheriting type bounds in categories/extensions.

2020-04-05 Thread Nico Weber via cfe-commits
The test here flakily fails, maybe 1 in 10 times:
http://45.33.8.238/mac/11180/step_7.txt

error: 'error' diagnostics seen but not expected:
  File
/Users/thakis/src/llvm-project/clang/test/SemaObjC/parameterized_classes_subst.m
Line 479: type argument 'T' (aka 'id') does not satisfy the bound
('id') of type parameter 'T'
error: 'note' diagnostics seen but not expected:
  File
/Users/thakis/src/llvm-project/clang/test/SemaObjC/parameterized_classes_subst.m
Line 475: type parameter 'T' declared here
2 errors generated.

Maybe if this is emitted depends on the order of something in a data
structure that has no deterministic order, or similar?

On Fri, Apr 3, 2020 at 7:29 PM Volodymyr Sapsai via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Volodymyr Sapsai
> Date: 2020-04-03T16:29:02-07:00
> New Revision: a8c8b627f23f204fb621bd2a8c495cfc8bc16ae7
>
> URL:
> https://github.com/llvm/llvm-project/commit/a8c8b627f23f204fb621bd2a8c495cfc8bc16ae7
> DIFF:
> https://github.com/llvm/llvm-project/commit/a8c8b627f23f204fb621bd2a8c495cfc8bc16ae7.diff
>
> LOG: [ObjC generics] Fix not inheriting type bounds in
> categories/extensions.
>
> When a category/extension doesn't repeat a type bound, corresponding
> type parameter is substituted with `id` when used as a type argument. As
> a result, in the added test case it was causing errors like
>
> > type argument 'T' (aka 'id') does not satisfy the bound
> ('id') of type parameter 'T'
>
> We are already checking that type parameters should be consistent
> everywhere (see `checkTypeParamListConsistency`) and update
> `ObjCTypeParamDecl` to have correct underlying type. And when we use the
> type parameter as a method return type or a method parameter type, it is
> substituted to the bounded type. But when we use the type parameter as a
> type argument, we check `ObjCTypeParamType` that wasn't updated and
> remains `id`.
>
> Fix by updating not only `ObjCTypeParamDecl` UnderlyingType but also
> TypeForDecl as we use the underlying type to create a canonical type for
> `ObjCTypeParamType` (see `ASTContext::getObjCTypeParamType`).
>
> This is a different approach to fixing the issue. The previous one was
> 02c2ab3d8872416589bd1a6ca3dfb96ba373a3b9 which was reverted in
> 4c539e8da1b3de38a53ef3f7497f5c45a3243b61. The problem with the previous
> approach was that `ObjCTypeParamType::desugar` was returning underlying
> type for `ObjCTypeParamDecl` without applying any protocols stored in
> `ObjCTypeParamType`. It caused inconsistencies in comparing types before
> and after desugaring.
>
> rdar://problem/54329242
>
> Reviewed By: erik.pilkington
>
> Differential Revision: https://reviews.llvm.org/D72872
>
> Added:
>
>
> Modified:
> clang/include/clang/AST/ASTContext.h
> clang/lib/AST/ASTContext.cpp
> clang/lib/AST/Type.cpp
> clang/lib/Sema/SemaDeclObjC.cpp
> clang/test/SemaObjC/parameterized_classes_collection_literal.m
> clang/test/SemaObjC/parameterized_classes_subst.m
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/include/clang/AST/ASTContext.h
> b/clang/include/clang/AST/ASTContext.h
> index 6813ab58874e..6360f18217c7 100644
> --- a/clang/include/clang/AST/ASTContext.h
> +++ b/clang/include/clang/AST/ASTContext.h
> @@ -1442,6 +1442,8 @@ class ASTContext : public RefCountedBase
> {
>
>QualType getObjCTypeParamType(const ObjCTypeParamDecl *Decl,
>  ArrayRef protocols)
> const;
> +  void adjustObjCTypeParamBoundType(const ObjCTypeParamDecl *Orig,
> +ObjCTypeParamDecl *New) const;
>
>bool ObjCObjectAdoptsQTypeProtocols(QualType QT, ObjCInterfaceDecl
> *Decl);
>
>
> diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
> index 1e81e0a67b4d..06dcb6fa0580 100644
> --- a/clang/lib/AST/ASTContext.cpp
> +++ b/clang/lib/AST/ASTContext.cpp
> @@ -4874,6 +4874,17 @@ ASTContext::getObjCTypeParamType(const
> ObjCTypeParamDecl *Decl,
>return QualType(newType, 0);
>  }
>
> +void ASTContext::adjustObjCTypeParamBoundType(const ObjCTypeParamDecl
> *Orig,
> +  ObjCTypeParamDecl *New)
> const {
> +
> New->setTypeSourceInfo(getTrivialTypeSourceInfo(Orig->getUnderlyingType()));
> +  // Update TypeForDecl after updating TypeSourceInfo.
> +  auto NewTypeParamTy = cast(New->getTypeForDecl());
> +  SmallVector protocols;
> +  protocols.append(NewTypeParamTy->qual_begin(),
> NewTypeParamTy->qual_end());
> +  QualType UpdatedTy = getObjCTypeParamType(New, protocols);
> +  New->setTypeForDecl(UpdatedTy.getTypePtr());
> +}
> +
>  /// ObjCObjectAdoptsQTypeProtocols - Checks that protocols in IC's
>  /// protocol list adopt all protocols in QT's qualified-id protocol
>  /// list.
>
> diff  --git a/clang/lib/AST/Type.cpp b/clang/lib/AST/Type.cpp
> index 3428437c3146..7c65378261ad 100644
> --- a/clang/lib/AST/Type.cpp
> +++ b/clang/lib/AST/Type.cpp
> @@ 

[PATCH] D77502: [clang][CodeGen] Handle throw expression in conditional operator constant folding

2020-04-05 Thread Raul Tambre via Phabricator via cfe-commits
tambre updated this revision to Diff 255175.
tambre added a comment.

Fix formatting


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77502/new/

https://reviews.llvm.org/D77502

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/test/CodeGenCXX/throw-expressions.cpp


Index: clang/test/CodeGenCXX/throw-expressions.cpp
===
--- clang/test/CodeGenCXX/throw-expressions.cpp
+++ clang/test/CodeGenCXX/throw-expressions.cpp
@@ -79,6 +79,12 @@
   // CHECK-NOT: call {{.*}}@_ZN6DR15601AD1Ev
   // CHECK: call {{.*}} @__cxa_atexit({{.*}} @_ZN6DR15601AD1Ev {{.*}} 
@_ZGRN6DR15601rE
   // CHECK-NOT: call {{.*}}@_ZN6DR15601AD1Ev
+
+  // PR28184
+  void conditional_throw() {
+int a, b;
+(true ? throw 0 : a) = 0;
+  }
 }
 
 // CHECK-LABEL: define void @_Z5test7b(
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -4331,6 +4331,11 @@
   // If the true case is live, we need to track its region.
   if (CondExprBool)
 incrementProfileCounter(expr);
+  // If a throw expression we need to return dead as lvalue.
+  if (auto *ThrowExpr = dyn_cast(live->IgnoreParens())) {
+EmitCXXThrowExpr(ThrowExpr);
+return EmitLValue(dead);
+  }
   return EmitLValue(live);
 }
   }


Index: clang/test/CodeGenCXX/throw-expressions.cpp
===
--- clang/test/CodeGenCXX/throw-expressions.cpp
+++ clang/test/CodeGenCXX/throw-expressions.cpp
@@ -79,6 +79,12 @@
   // CHECK-NOT: call {{.*}}@_ZN6DR15601AD1Ev
   // CHECK: call {{.*}} @__cxa_atexit({{.*}} @_ZN6DR15601AD1Ev {{.*}} @_ZGRN6DR15601rE
   // CHECK-NOT: call {{.*}}@_ZN6DR15601AD1Ev
+
+  // PR28184
+  void conditional_throw() {
+int a, b;
+(true ? throw 0 : a) = 0;
+  }
 }
 
 // CHECK-LABEL: define void @_Z5test7b(
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -4331,6 +4331,11 @@
   // If the true case is live, we need to track its region.
   if (CondExprBool)
 incrementProfileCounter(expr);
+  // If a throw expression we need to return dead as lvalue.
+  if (auto *ThrowExpr = dyn_cast(live->IgnoreParens())) {
+EmitCXXThrowExpr(ThrowExpr);
+return EmitLValue(dead);
+  }
   return EmitLValue(live);
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D77484: [Vector] Pass VectLib to LTO backend so TLI build correct vector function list

2020-04-05 Thread Wenlei He via Phabricator via cfe-commits
wenlei added a comment.

In D77484#1962445 , @tejohnson wrote:

> We're trying to move towards encoding all of this in the IR. And in fact, I 
> recently implemented a series of patches to make the TLI to be built 
> per-function, and along with some patches from @gchatelet to encode 
> -fno-builtin* as function attributes, we now handle that part of the TLII 
> with IR. See D67923  which is the last patch 
> in the series. We should encode the vectlib as function attributes similarly, 
> and just thread that through to the TLI.


Thanks for quick look, @tejohnson. Yeah, making vectlib a function attribute 
would be more consistent with other the way other TLI attributes are handled. 
However, unlike some other attributes, which really need to be per-function, 
conceptually, vectlib setting won't be different from function to function in a 
module. Implementation-wise, even though TLI is now built per-function, there's 
a `BaselineInfoImpl` within each `TargetLibraryInfo`, that's still shared among 
functions, and `VectorDescs` which is populated based on vectlib setting 
belongs to the shared baseline. We could also move `VectorDescs` and its 
population into per-function part of TLI, but I felt that's a bit overkill, 
though I don't have a strong opinion on this. So I followed how other module 
level stuff like `lto-sample-profile` is passed to backend..

Alternatively, we could chose to always run `InjectTLIMappings` in pre-LTO 
pipeline, even if we don't run vectorizer pre-LTO for ThinLTO, so we always 
have per-function attribute `vector-function-abi-variant` populated and 
threaded through to LTO time vectorizer. We will have to make sure the vector 
function list in TLI (based on vectlib setting) has no other use case though.

(More on TLI, while this change (or a variant of this) enables vectorization 
that uses math library for ThinLTO w/ legacy PM, there's separate issue with 
new PM as `InjectTLIMappings` is not scheduled before Vectorization for LTO 
pipeline. I will send a separate patch for that once we settle on a good way to 
handle this one.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77484/new/

https://reviews.llvm.org/D77484



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


[PATCH] D77503: [ASTMatchers] Fixed CastKind being parsed incorrectly for dynamic matchers

2020-04-05 Thread Nathan James via Phabricator via cfe-commits
njames93 created this revision.
njames93 added a reviewer: klimek.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Requires hasCastKind arguments to have `CK_` prefixed to bring it in line with 
the documentation and other matchers that take enumerations.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77503

Files:
  clang/lib/ASTMatchers/Dynamic/Marshallers.h


Index: clang/lib/ASTMatchers/Dynamic/Marshallers.h
===
--- clang/lib/ASTMatchers/Dynamic/Marshallers.h
+++ clang/lib/ASTMatchers/Dynamic/Marshallers.h
@@ -147,7 +147,7 @@
 private:
   static Optional getCastKind(llvm::StringRef AttrKind) {
 return llvm::StringSwitch>(AttrKind)
-#define CAST_OPERATION(Name) .Case( #Name, CK_##Name)
+#define CAST_OPERATION(Name) .Case("CK_" #Name, CK_##Name)
 #include "clang/AST/OperationKinds.def"
 .Default(llvm::None);
   }


Index: clang/lib/ASTMatchers/Dynamic/Marshallers.h
===
--- clang/lib/ASTMatchers/Dynamic/Marshallers.h
+++ clang/lib/ASTMatchers/Dynamic/Marshallers.h
@@ -147,7 +147,7 @@
 private:
   static Optional getCastKind(llvm::StringRef AttrKind) {
 return llvm::StringSwitch>(AttrKind)
-#define CAST_OPERATION(Name) .Case( #Name, CK_##Name)
+#define CAST_OPERATION(Name) .Case("CK_" #Name, CK_##Name)
 #include "clang/AST/OperationKinds.def"
 .Default(llvm::None);
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D75917: Expose llvm fence instruction as clang intrinsic

2020-04-05 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam updated this revision to Diff 255173.
saiislam added a comment.

Removed OpenCL specific dependencies

Now it takes target-specific sync scope as an string.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75917/new/

https://reviews.llvm.org/D75917

Files:
  clang/include/clang/Basic/Builtins.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGenHIP/builtin_memory_fence.cpp
  clang/test/Sema/builtins.c

Index: clang/test/Sema/builtins.c
===
--- clang/test/Sema/builtins.c
+++ clang/test/Sema/builtins.c
@@ -320,3 +320,15 @@
   // expected-error@+1 {{use of unknown builtin '__builtin_is_constant_evaluated'}}
   return __builtin_is_constant_evaluated();
 }
+
+void test_memory_fence_errors() {
+  __builtin_memory_fence(__ATOMIC_SEQ_CST + 1, "workgroup");  // expected-warning {{memory order argument to atomic operation is invalid}}
+
+  __builtin_memory_fence(__ATOMIC_ACQUIRE - 1, "workgroup");  // expected-warning {{memory order argument to atomic operation is invalid}}
+
+  __builtin_memory_fence(4);  // expected-error {{too few arguments to function call, expected 2}}
+
+  __builtin_memory_fence(4, 4, 4);  // expected-error {{too many arguments to function call, expected 2}}
+
+  __builtin_memory_fence(3.14, "");  // expected-warning {{implicit conversion from 'double' to 'unsigned int' changes value from 3.14 to 3}}
+}
Index: clang/test/CodeGenHIP/builtin_memory_fence.cpp
===
--- /dev/null
+++ clang/test/CodeGenHIP/builtin_memory_fence.cpp
@@ -0,0 +1,22 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang_cc1 %s -x hip -emit-llvm -O0 -o - \
+// RUN:   -triple=amdgcn-amd-amdhsa  | opt -instnamer -S | FileCheck %s
+
+void test_memory_fence_success() {
+// CHECK-LABEL: test_memory_fence_success
+
+  // CHECK: fence syncscope("workgroup") seq_cst
+  __builtin_memory_fence(__ATOMIC_SEQ_CST,  "workgroup");
+  
+   // CHECK: fence syncscope("agent") acquire
+  __builtin_memory_fence(__ATOMIC_ACQUIRE, "agent");
+
+  // CHECK: fence seq_cst
+  __builtin_memory_fence(__ATOMIC_SEQ_CST, "");
+
+  // CHECK: fence syncscope("agent") acq_rel
+  __builtin_memory_fence(4, "agent");
+
+// CHECK: fence syncscope("workgroup") release
+  __builtin_memory_fence(3, "workgroup");
+}
\ No newline at end of file
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1855,7 +1855,7 @@
   return ExprError();
 break;
   case Builtin::BI__builtin_frame_address:
-  case Builtin::BI__builtin_return_address:
+  case Builtin::BI__builtin_return_address: {
 if (SemaBuiltinConstantArgRange(TheCall, 0, 0, 0x))
   return ExprError();
 
@@ -1869,6 +1869,30 @@
   ? "__builtin_return_address"
   : "__builtin_frame_address")
   << TheCall->getSourceRange();
+  }
+break;
+
+  case Builtin::BI__builtin_memory_fence: {
+ExprResult Arg = TheCall->getArg(0);
+auto ArgExpr = Arg.get();
+Expr::EvalResult ArgResult;
+
+if(!ArgExpr->EvaluateAsInt(ArgResult, Context)) {
+  Diag(ArgExpr->getExprLoc(), diag::err_typecheck_expect_int) <<
+   ArgExpr->getType();
+  return ExprError();
+}
+int ord = ArgResult.Val.getInt().getZExtValue();
+
+// Check valididty of memory ordering as per C11 / C++11's memody model.
+if (ord < static_cast(llvm::AtomicOrderingCABI::acquire) ||
+  ord > static_cast(llvm::AtomicOrderingCABI::seq_cst)) {
+  Diag(ArgExpr->getBeginLoc(),
+  diag::warn_atomic_op_has_invalid_memory_order)
+  << ArgExpr->getSourceRange();
+  return ExprError();
+}
+}
 break;
   }
 
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -28,6 +28,7 @@
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/ADT/StringExtras.h"
+#include "llvm/Analysis/ValueTracking.h"
 #include "llvm/IR/DataLayout.h"
 #include "llvm/IR/InlineAsm.h"
 #include "llvm/IR/Intrinsics.h"
@@ -13616,6 +13617,43 @@
 Function *F = CGM.getIntrinsic(Intrinsic::fshr, Src0->getType());
 return Builder.CreateCall(F, { Src0, Src1, Src2 });
   }
+
+  case Builtin::BI__builtin_memory_fence: {
+llvm::AtomicOrdering AO = llvm::AtomicOrdering::SequentiallyConsistent;
+llvm::SyncScope::ID SSID;
+Value *Order = EmitScalarExpr(E->getArg(0));
+Value *Scope = EmitScalarExpr(E->getArg(1));
+
+if ( isa(Order)) {
+  int ord = cast(Order)->getZExtValue();
+
+  // Map C11/C++11 memory ordering to LLVM memory ordering
+  switch (static_cast(ord)) {
+  case llvm::AtomicOrderingCABI::acquire:
+AO = 

[clang] e01ec11 - make ccabe93298 more robust

2020-04-05 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2020-04-05T13:07:50-04:00
New Revision: e01ec11882d3a2af509ec5caf248ecd79485240c

URL: 
https://github.com/llvm/llvm-project/commit/e01ec11882d3a2af509ec5caf248ecd79485240c
DIFF: 
https://github.com/llvm/llvm-project/commit/e01ec11882d3a2af509ec5caf248ecd79485240c.diff

LOG: make ccabe93298 more robust

Added: 


Modified: 
clang/test/Driver/mingw-sysroot.cpp
clang/test/Driver/riscv32-toolchain-extra.c
clang/test/Driver/riscv64-toolchain-extra.c

Removed: 




diff  --git a/clang/test/Driver/mingw-sysroot.cpp 
b/clang/test/Driver/mingw-sysroot.cpp
index 9c6ded76127d..eb62b6fe5d0c 100644
--- a/clang/test/Driver/mingw-sysroot.cpp
+++ b/clang/test/Driver/mingw-sysroot.cpp
@@ -1,14 +1,14 @@
 // REQUIRES: shell
 // UNSUPPORTED: system-windows
 
-// RUN: rm -rf %T/testroot-gcc/bin
+// RUN: rm -rf %T/testroot-gcc
 // RUN: mkdir -p %T/testroot-gcc/bin
 // RUN: ln -s %clang %T/testroot-gcc/bin/x86_64-w64-mingw32-gcc
 // RUN: ln -s %clang %T/testroot-gcc/bin/x86_64-w64-mingw32-clang
 // RUN: ln -s %S/Inputs/mingw_ubuntu_posix_tree/usr/x86_64-w64-mingw32 
%T/testroot-gcc/x86_64-w64-mingw32
 // RUN: ln -s %S/Inputs/mingw_ubuntu_posix_tree/usr/lib %T/testroot-gcc/lib
 
-// RUN: rm -rf %T/testroot-clang/bin
+// RUN: rm -rf %T/testroot-clang
 // RUN: mkdir -p %T/testroot-clang/bin
 // RUN: ln -s %clang %T/testroot-clang/bin/x86_64-w64-mingw32-clang
 // RUN: ln -s %S/Inputs/mingw_ubuntu_posix_tree/usr/x86_64-w64-mingw32 
%T/testroot-clang/x86_64-w64-mingw32

diff  --git a/clang/test/Driver/riscv32-toolchain-extra.c 
b/clang/test/Driver/riscv32-toolchain-extra.c
index f70092ac0333..8103e55b9aa5 100644
--- a/clang/test/Driver/riscv32-toolchain-extra.c
+++ b/clang/test/Driver/riscv32-toolchain-extra.c
@@ -12,7 +12,7 @@
 // runtime if and only if they exist.
 //
 // REQUIRES: platform-linker
-// RUN: rm -rf %T/testroot-riscv32-baremetal-nogcc/bin
+// RUN: rm -rf %T/testroot-riscv32-baremetal-nogcc
 // RUN: mkdir -p %T/testroot-riscv32-baremetal-nogcc/bin
 // RUN: ln -s %clang %T/testroot-riscv32-baremetal-nogcc/bin/clang
 // RUN: ln -s %S/Inputs/basic_riscv32_nogcc_tree/bin/riscv32-unknown-elf-ld 
%T/testroot-riscv32-baremetal-nogcc/bin/riscv32-unknown-elf-ld

diff  --git a/clang/test/Driver/riscv64-toolchain-extra.c 
b/clang/test/Driver/riscv64-toolchain-extra.c
index 434f2dd2599a..d11f92275f4e 100644
--- a/clang/test/Driver/riscv64-toolchain-extra.c
+++ b/clang/test/Driver/riscv64-toolchain-extra.c
@@ -12,7 +12,7 @@
 // runtime if and only if they exist.
 //
 // REQUIRES: platform-linker
-// RUN: rm -rf %T/testroot-riscv64-baremetal-nogcc/bin
+// RUN: rm -rf %T/testroot-riscv64-baremetal-nogcc
 // RUN: mkdir -p %T/testroot-riscv64-baremetal-nogcc/bin
 // RUN: ln -s %clang %T/testroot-riscv64-baremetal-nogcc/bin/clang
 // RUN: ln -s %S/Inputs/basic_riscv64_nogcc_tree/bin/riscv64-unknown-elf-ld 
%T/testroot-riscv64-baremetal-nogcc/bin/riscv64-unknown-elf-ld



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


[clang] ccabe93 - clang: Make tests using symlinks more consistent.

2020-04-05 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2020-04-05T12:56:41-04:00
New Revision: ccabe9329857141e0b676951ff89092d7f88bed0

URL: 
https://github.com/llvm/llvm-project/commit/ccabe9329857141e0b676951ff89092d7f88bed0
DIFF: 
https://github.com/llvm/llvm-project/commit/ccabe9329857141e0b676951ff89092d7f88bed0.diff

LOG: clang: Make tests using symlinks more consistent.

Instead of checking if each symlink exists before removing it,
remove the whole temp dir housing the symlinks before recreating it.
This is a bit shorter, conceptually simpler (in that the first
and consecutive test runs have more similar behavior), it's what we're
already doing in almost all places where we do it, and it works if the
symlink exists but is a dead link (e.g. when it points into the build
dir but the build dir is renamed).

No intended behavior change.

Added: 


Modified: 
clang/test/Driver/config-file3.c
clang/test/Driver/mingw-sysroot.cpp
clang/test/Driver/riscv32-toolchain-extra.c
clang/test/Driver/riscv64-toolchain-extra.c
clang/test/Driver/target-override.c

Removed: 




diff  --git a/clang/test/Driver/config-file3.c 
b/clang/test/Driver/config-file3.c
index 938411cf0fff..148646c2ebbf 100644
--- a/clang/test/Driver/config-file3.c
+++ b/clang/test/Driver/config-file3.c
@@ -16,8 +16,8 @@
 
 //--- Invocation qqq-clang-g++ tries to find config file qqq-clang-g++.cfg 
first.
 //
+// RUN: rm -rf %T/testdmode
 // RUN: mkdir -p %T/testdmode
-// RUN: [ ! -s %T/testdmode/qqq-clang-g++ ] || rm %T/testdmode/qqq-clang-g++
 // RUN: ln -s %clang %T/testdmode/qqq-clang-g++
 // RUN: echo "-Wundefined-func-template" > %T/testdmode/qqq-clang-g++.cfg
 // RUN: echo "-Werror" > %T/testdmode/qqq.cfg
@@ -53,8 +53,8 @@
 
 //--- Config files are searched for in binary directory as well.
 //
+// RUN: rm -rf %T/testbin
 // RUN: mkdir -p %T/testbin
-// RUN: [ ! -s %T/testbin/clang ] || rm %T/testbin/clang
 // RUN: ln -s %clang %T/testbin/clang
 // RUN: echo "-Werror" > %T/testbin/aaa.cfg
 // RUN: %T/testbin/clang --config-system-dir= --config-user-dir= --config 
aaa.cfg -c -no-canonical-prefixes %s -### 2>&1 | FileCheck %s -check-prefix 
CHECK-BIN
@@ -68,8 +68,8 @@
 
 //--- When reloading config file, x86_64-clang-g++ tries to find config 
i386-clang-g++.cfg first.
 //
+// RUN: rm -rf %T/testreload
 // RUN: mkdir -p %T/testreload
-// RUN: [ ! -s %T/testreload/x86_64-clang-g++ ] || rm 
%T/testreload/x86_64-clang-g++
 // RUN: ln -s %clang %T/testreload/x86_64-clang-g++
 // RUN: echo "-Wundefined-func-template" > %T/testreload/i386-clang-g++.cfg
 // RUN: echo "-Werror" > %T/testreload/i386.cfg

diff  --git a/clang/test/Driver/mingw-sysroot.cpp 
b/clang/test/Driver/mingw-sysroot.cpp
index d477f314195f..9c6ded76127d 100644
--- a/clang/test/Driver/mingw-sysroot.cpp
+++ b/clang/test/Driver/mingw-sysroot.cpp
@@ -1,19 +1,15 @@
 // REQUIRES: shell
 // UNSUPPORTED: system-windows
 
+// RUN: rm -rf %T/testroot-gcc/bin
 // RUN: mkdir -p %T/testroot-gcc/bin
-// RUN: [ ! -s %T/testroot-gcc/bin/x86_64-w64-mingw32-gcc ] || rm 
%T/testroot-gcc/bin/x86_64-w64-mingw32-gcc
-// RUN: [ ! -s %T/testroot-gcc/bin/x86_64-w64-mingw32-clang ] || rm 
%T/testroot-gcc/bin/x86_64-w64-mingw32-clang
-// RUN: [ ! -s %T/testroot-gcc/x86_64-w64-mingw32 ] || rm 
%T/testroot-gcc/x86_64-w64-mingw32
-// RUN: [ ! -s %T/testroot-gcc/lib ] || rm %T/testroot-gcc/lib
 // RUN: ln -s %clang %T/testroot-gcc/bin/x86_64-w64-mingw32-gcc
 // RUN: ln -s %clang %T/testroot-gcc/bin/x86_64-w64-mingw32-clang
 // RUN: ln -s %S/Inputs/mingw_ubuntu_posix_tree/usr/x86_64-w64-mingw32 
%T/testroot-gcc/x86_64-w64-mingw32
 // RUN: ln -s %S/Inputs/mingw_ubuntu_posix_tree/usr/lib %T/testroot-gcc/lib
 
+// RUN: rm -rf %T/testroot-clang/bin
 // RUN: mkdir -p %T/testroot-clang/bin
-// RUN: [ ! -s %T/testroot-clang/bin/x86_64-w64-mingw32-clang ] || rm 
%T/testroot-clang/bin/x86_64-w64-mingw32-clang
-// RUN: [ ! -s %T/testroot-clang/x86_64-w64-mingw32 ] || rm 
%T/testroot-clang/x86_64-w64-mingw32
 // RUN: ln -s %clang %T/testroot-clang/bin/x86_64-w64-mingw32-clang
 // RUN: ln -s %S/Inputs/mingw_ubuntu_posix_tree/usr/x86_64-w64-mingw32 
%T/testroot-clang/x86_64-w64-mingw32
 

diff  --git a/clang/test/Driver/riscv32-toolchain-extra.c 
b/clang/test/Driver/riscv32-toolchain-extra.c
index 3182e0cfc1ae..f70092ac0333 100644
--- a/clang/test/Driver/riscv32-toolchain-extra.c
+++ b/clang/test/Driver/riscv32-toolchain-extra.c
@@ -12,10 +12,8 @@
 // runtime if and only if they exist.
 //
 // REQUIRES: platform-linker
+// RUN: rm -rf %T/testroot-riscv32-baremetal-nogcc/bin
 // RUN: mkdir -p %T/testroot-riscv32-baremetal-nogcc/bin
-// RUN: [ ! -s %T/testroot-riscv32-baremetal-nogcc/bin/clang ] || rm 
%T/testroot-riscv32-baremetal-nogcc/bin/clang
-// RUN: [ ! -s %T/testroot-riscv32-baremetal-nogcc/bin/riscv32-unknown-elf-ld 
] || rm %T/testroot-riscv32-baremetal-nogcc/bin/riscv32-unknown-elf-ld
-// RUN: [ ! -s 

[PATCH] D77028: [NFC] Refactor DeferredDiagsEmitter and skip redundant visit

2020-04-05 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 3 inline comments as done.
yaxunl added inline comments.



Comment at: clang/lib/Sema/Sema.cpp:1508
   void checkFunc(SourceLocation Loc, FunctionDecl *FD) {
+auto DiagsCountIt = DiagsCount.find(FD);
 FunctionDecl *Caller = UseStack.empty() ? nullptr : UseStack.back();

rjmccall wrote:
> yaxunl wrote:
> > rjmccall wrote:
> > > yaxunl wrote:
> > > > rjmccall wrote:
> > > > > yaxunl wrote:
> > > > > > rjmccall wrote:
> > > > > > > It makes me a little uncomfortable to be holding an iterator this 
> > > > > > > long while calling a fair amount of other stuff in the meantime.
> > > > > > > 
> > > > > > > Your use of DiagsCount is subtle enough that it really needs to 
> > > > > > > be explained in some comments.  You're doing stuff conditionally 
> > > > > > > based on both whether the entry exists but also whether it's 
> > > > > > > non-zero.
> > > > > > added comments
> > > > > Okay, thanks for that.  Two points, then.  First, it looks like the 
> > > > > count is really just a boolean for whether the function recursively 
> > > > > triggers any diagnostics.   And second, can't it just be as simple as 
> > > > > whether we've visited that function at all in a context that's 
> > > > > forcing diagnostics to be emitted?  The logic seems to be to try to 
> > > > > emit the diagnostics for each use-path, but why would we want that?
> > > > For the second comment, we need to visit a function again for each 
> > > > use-path because we need to report each use-path that triggers a 
> > > > diagnostic, otherwise users will see a new error after they fix one 
> > > > error, instead of seeing all the errors at once.
> > > > 
> > > > For the first comment, I will change the count to two flags: one for 
> > > > the case where the function is not in device context, the other is for 
> > > > the case where the function is in device context. This will allow us to 
> > > > avoid redundant visits whether or not we are in a device context.
> > > > For the second comment, we need to visit a function again for each 
> > > > use-path because we need to report each use-path that triggers a 
> > > > diagnostic, otherwise users will see a new error after they fix one 
> > > > error, instead of seeing all the errors at once.
> > > 
> > > This is not what we do in analogous cases where errors are triggered by a 
> > > use, like in template instantiation.   The bug might be that the device 
> > > program is using a function that it shouldn't be using, or the bug might 
> > > be that a function that's supposed  to be usable from the device is 
> > > written incorrectly.  In the former case, yes, not reporting the errors 
> > > for each use-path may force the programmer to build multiple times to 
> > > find all the problematic uses.  However, in the latter case you can 
> > > easily end up emitting a massive number of errors that completely drowns 
> > > out everything else.  It's also non-linear: the number of different 
> > > use-paths of a particular function can be combinatoric.
> > The deferred diagnostics fall into the first case mostly. 
> > 
> > Not all diagnostic messages happen in device host functions are deferred. 
> > Most of diagnostic messages are emitted immediately, disregarding whether 
> > the function is emitted or not. 
> > 
> > Only a few special types of diagnostic messages e.g. inline assembly 
> > errors, exceptions, varags are deferred. This is because clang has to use 
> > pragmas to make all functions device and host in some system headers to be 
> > able to use them in device compilation, whereas some of these functions 
> > will cause error only if they are emitted in device compilation. Since we 
> > cannot change these headers, we have to defer such diagnostics to the point 
> > where they are actually triggered. Therefore we are mostly interested in 
> > "who is calling these functions" instead of the diagnostics themselves.
> > 
> > For normal programs containing no diagnostics, the current approach should 
> > sufficiently avoid all redundant visits and all functions will be visited 
> > once.
> > 
> > The functions may be visited multiple times when there are deferred 
> > diagnostics, however this should be limited by the maximum number of errors.
> Okay.  I understand the point now about being mostly concerned about using 
> functions in headers.
> 
> My concern about visiting things a combinatorial number of times is less 
> about generating an excessive number of errors and more about taking an 
> excessive amount of time to finish compilation.  The compiler really should 
> not be using any exponential algorithms; a simple visited set will ensure 
> that, but I think what you're doing does not.  Can you make a case for why 
> that's not true?
The current approach is linear for the number of visits to functions.

Let's assume the number of functions is N.

The current approach already restricted revisiting a node that's already in the 

RE: [clang] b670ab7 - recommit 1b978ddba05c [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

2020-04-05 Thread Liu, Yaxun (Sam) via cfe-commits
[AMD Official Use Only - Internal Distribution Only]

The issue is addressed by https://reviews.llvm.org/D77028

Sam

-Original Message-
From: Joerg Sonnenberger 
Sent: Sunday, April 5, 2020 9:48 AM
To: Liu, Yaxun (Sam) ; Yaxun Liu 
Cc: cfe-commits@lists.llvm.org
Subject: Re: [clang] b670ab7 - recommit 1b978ddba05c [CUDA][HIP][OpenMP] Emit 
deferred diagnostics by a post-parsing AST travese

[CAUTION: External Email]

On Mon, Mar 23, 2020 at 09:09:31AM -0700, Yaxun Liu via cfe-commits wrote:
>
> Author: Yaxun (Sam) Liu
> Date: 2020-03-23T12:09:07-04:00
> New Revision: b670ab7b6b3d2f26179213be1da1d4ba376f50a3
>
> URL: 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fb670ab7b6b3d2f26179213be1da1d4
> ba376f50a3data=02%7C01%7Cyaxun.liu%40amd.com%7Cfc099ddf95594ab17e
> da08d7d968004e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6372169134
> 68808969sdata=WtAm5JbQgR7UDY0FL5AlIvZOSOLPbQTRbKHJvP0Vot8%3D
> reserved=0
> DIFF: 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fb670ab7b6b3d2f26179213be1da1d4
> ba376f50a3.diffdata=02%7C01%7Cyaxun.liu%40amd.com%7Cfc099ddf95594
> ab17eda08d7d968004e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63721
> 6913468808969sdata=wREjtZ%2F5SHC1U4dxGbbSvYYncnhqa%2ByJzHBxv%2FIh
> PlY%3Dreserved=0
>
> LOG: recommit 1b978ddba05c [CUDA][HIP][OpenMP] Emit deferred 
> diagnostics by a post-parsing AST travese

This change is responsible for a significant performance regression.
Somewhat reduced example is attached. With -fopenmp, it needs ~5s, without 
0.02s.

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


[PATCH] D77493: [clang-tidy] Add do-not-refer-atomic-twice check

2020-04-05 Thread Kocsis Ábel via Phabricator via cfe-commits
abelkocsis updated this revision to Diff 255170.
abelkocsis added a comment.

Small fixes in doc and test files.


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77493/new/

https://reviews.llvm.org/D77493

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/DoNotReferAtomicTwiceCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/DoNotReferAtomicTwiceCheck.h
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-do-not-refer-atomic-twice.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-con40-c.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-do-not-refer-atomic-twice.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-do-not-refer-atomic-twice.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-do-not-refer-atomic-twice.cpp
@@ -0,0 +1,77 @@
+// RUN: %check_clang_tidy %s bugprone-do-not-refer-atomic-twice %t
+#define _Bool bool
+typedef _Atomic _Bool atomic_bool;
+typedef _Atomic int atomic_int;
+#define ATOMIC_VAR_INIT(VALUE) (VALUE)
+
+atomic_bool b = ATOMIC_VAR_INIT(false);
+atomic_int n = ATOMIC_VAR_INIT(0);
+_Atomic int n2 = ATOMIC_VAR_INIT(0);
+_Atomic(int) n3 = ATOMIC_VAR_INIT(0);
+
+void warn1() {
+  n = (n + 1) / 2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: Do not refer to 'n' atomic variable twice in an expression [bugprone-do-not-refer-atomic-twice]
+  n2 = (n2 + 1) / 2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: Do not refer to 'n2' atomic variable twice in an expression [bugprone-do-not-refer-atomic-twice]
+  n3 = (n3 + 1) / 2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: Do not refer to 'n3' atomic variable twice in an expression [bugprone-do-not-refer-atomic-twice]
+  b = b && true;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: Do not refer to 'b' atomic variable twice in an expression [bugprone-do-not-refer-atomic-twice]
+}
+
+int warn2_1() {
+  return n * (n + 1) / 2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: Do not refer to 'n' atomic variable twice in an expression [bugprone-do-not-refer-atomic-twice]
+}
+
+int warn2_2() {
+  return n2 * (n2 + 1) / 2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: Do not refer to 'n2' atomic variable twice in an expression [bugprone-do-not-refer-atomic-twice]
+}
+
+int warn2_3() {
+  return n3 * (n3 + 1) / 2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: Do not refer to 'n3' atomic variable twice in an expression [bugprone-do-not-refer-atomic-twice]
+}
+
+int warn2_4() {
+  return (b && true) || b;
+  // CHECK-MESSAGES: :[[@LINE-1]]:25: warning: Do not refer to 'b' atomic variable twice in an expression [bugprone-do-not-refer-atomic-twice]
+}
+
+void good1() {
+  n = 12;
+  n2 = 12;
+  n3 = 12;
+  b = true;
+}
+
+int good2_1() {
+  return n;
+}
+
+int good2_2() {
+  return n2;
+}
+
+int good2_3() {
+  return n3;
+}
+
+bool good2_4() {
+  return b;
+}
+
+void good3() {
+  n += 12;
+  n2 += 12;
+  n3 += 12;
+  b ^= 1;
+}
+
+void good4() {
+  n++;
+  n2++;
+  n3++;
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -52,6 +52,7 @@
`bugprone-branch-clone `_,
`bugprone-copy-constructor-init `_, "Yes"
`bugprone-dangling-handle `_,
+   `bugprone-do-not-refer-atomic-twice `_,
`bugprone-dynamic-static-initializers `_,
`bugprone-exception-escape `_,
`bugprone-fold-init-type `_,
@@ -97,6 +98,7 @@
`bugprone-unused-return-value `_,
`bugprone-use-after-move `_,
`bugprone-virtual-near-miss `_, "Yes"
+   `cert-con40-c `_,
`cert-dcl21-cpp `_,
`cert-dcl50-cpp `_,
`cert-dcl58-cpp `_,
@@ -417,4 +419,3 @@
`hicpp-use-override `_, `modernize-use-override `_, "Yes"
`hicpp-vararg `_, `cppcoreguidelines-pro-type-vararg `_,
`llvm-qualified-auto `_, `readability-qualified-auto `_, "Yes"
-
Index: clang-tools-extra/docs/clang-tidy/checks/cert-con40-c.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/cert-con40-c.rst
@@ -0,0 +1,10 @@
+.. title:: clang-tidy - cert-con40-c
+.. meta::
+   :http-equiv=refresh: 5;URL=bugprone-do-not-refer-atomic-twice.html
+
+cert-con40-c
+
+
+The cert-con40-c check is an alias, please see
+`bugprone-do-not-refer-atomic-twice `_
+for more information.
Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-do-not-refer-atomic-twice.rst
===
--- /dev/null
+++ 

[PATCH] D75229: [clang-tidy] Add signal-in-multithreaded-program check

2020-04-05 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp:33-50
+void SignalInMultithreadedProgramCheck::registerMatchers(MatchFinder *Finder) {
+  auto signalCall =
+  callExpr(
+  ignoringImpCasts(hasDescendant(declRefExpr(hasDeclaration(
+  functionDecl(allOf(hasName("signal"), parameterCountIs(2),
+ hasParameter(0, hasType(isInteger())
+  .bind("signal");

abelkocsis wrote:
> steakhal wrote:
> > I apologize for interrupting the review.
> > Should we use `hasDescendant` for matching like everything in translation 
> > unit?
> > 
> > Wouldn't it be more performant to collect all the `signal` calls in a set 
> > and set a bool variable if a `ThreadList` function seen? 
> > At the end of the analysis of the translation unit, emit warnings for each 
> > recorded `signal` call if the variable was set //(aka. we are in 
> > multithreaded environment)//.
> > 
> > Treat this comment rather a question since I'm not really familiar with 
> > `clang-tidy`.
> I updated the checker not exactly in that way you mentioned, but I think you 
> are right that we should not match for all `translationUnitDecl`.
Every single check runs on the whole `TranslationUnitDecl`, and the matcher 
will try to match on every of the TU's descendant, that is why it emit multiple 
reports in the same single run. There is no need to use `translationUnitDecl()` 
and nor to use `forEachDescendant()`.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp:38
+   functionDecl(hasAnyListedName(ThreadList)))
+  .bind("thread")),
+  hasDescendant(varDecl(hasType(recordDecl(hasName("std::thread")

You can emit the binding of `thread`.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp:56
+  diag(MatchedSignal->getExprLoc(),
+   "singal function should not be called in a multithreaded program");
+}

`singal` -> `signal`


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75229/new/

https://reviews.llvm.org/D75229



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


[PATCH] D66324: clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM

2020-04-05 Thread Ayke via Phabricator via cfe-commits
aykevl added a comment.

@xbolva00 I could, but to me this is not trivial (I'm not familiar with the 
code and I'm not sure what I would break). If it's easy for you, then please do 
(otherwise I can send a patch for review).
I have already worked around this issue in a different way (by running the 
compiler invocation in a separate process).


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66324/new/

https://reviews.llvm.org/D66324



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


[PATCH] D63852: [Clang] Move assembler into a separate file

2020-04-05 Thread Ayke via Phabricator via cfe-commits
aykevl added a comment.

Ping?
I'm not sure who to add as a reviewer.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63852/new/

https://reviews.llvm.org/D63852



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


[PATCH] D75229: [clang-tidy] Add signal-in-multithreaded-program check

2020-04-05 Thread Kocsis Ábel via Phabricator via cfe-commits
abelkocsis updated this revision to Diff 255169.
abelkocsis marked an inline comment as done.

Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75229/new/

https://reviews.llvm.org/D75229

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.h
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-signal-in-multithreaded-program.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-con37-c.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-config-std::thread.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-config-thrd_create.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-noconfig-std::thread.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-noconfig-thrd_create.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-noconfig-thrd_create.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-noconfig-thrd_create.cpp
@@ -0,0 +1,36 @@
+// RUN: %check_clang_tidy %s bugprone-signal-in-multithreaded-program %t
+
+typedef unsigned long int thrd_t;
+typedef int (*thrd_start_t)(void *);
+typedef int sig_atomic_t;
+#define SIGUSR1 30
+#define NULL 0
+
+void (*signal(int sig, void (*handler)(int)))(int);
+
+int thrd_create(thrd_t *thr, thrd_start_t func, void *arg) { return 0; };
+enum {
+  thrd_success = 0,
+};
+
+volatile sig_atomic_t flag = 0;
+
+void handler(int signum) {
+  flag = 1;
+}
+
+int func(void *data) {
+  while (!flag) {
+  }
+  return 0;
+}
+
+int main(void) {
+  signal(SIGUSR1, handler);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: singal function should not be called in a multithreaded program [bugprone-signal-in-multithreaded-program]
+  thrd_t tid;
+
+  if (thrd_success != thrd_create(, func, NULL)) {
+  }
+  return 0;
+}
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-noconfig-std::thread.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-noconfig-std::thread.cpp
@@ -0,0 +1,37 @@
+// RUN: %check_clang_tidy %s bugprone-signal-in-multithreaded-program %t
+
+typedef unsigned long int thrd_t;
+typedef int (*thrd_start_t)(void *);
+typedef int sig_atomic_t;
+#define SIGUSR1 30
+#define NULL 0
+
+void (*signal(int sig, void (*handler)(int)))(int);
+
+volatile sig_atomic_t flag = 0;
+
+void handler(int signum) {
+  flag = 1;
+}
+
+void threadFunction() {}
+
+namespace std {
+class thread {
+public:
+  thread() noexcept;
+  template 
+  explicit thread(Function &, Args &&... args);
+  thread(const thread &) = delete;
+  thread(thread &&) noexcept;
+};
+} // namespace std
+
+int main(void) {
+  signal(SIGUSR1, handler);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: singal function should not be called in a multithreaded program [bugprone-signal-in-multithreaded-program]
+
+  std::thread threadObj(threadFunction);
+
+  return 0;
+}
\ No newline at end of file
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-config-thrd_create.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-config-thrd_create.cpp
@@ -0,0 +1,38 @@
+// RUN: %check_clang_tidy %s bugprone-signal-in-multithreaded-program %t \
+// RUN: -config='{CheckOptions: \
+// RUN:  [{key: bugprone-signal-in-multithreaded-program.ThreadList, value: "thrd_create"}]}'
+
+typedef unsigned long int thrd_t;
+typedef int (*thrd_start_t)(void *);
+typedef int sig_atomic_t;
+#define SIGUSR1 30
+#define NULL 0
+
+void (*signal(int sig, void (*handler)(int)))(int);
+
+int thrd_create(thrd_t *thr, thrd_start_t func, void *arg) { return 0; };
+enum {
+  thrd_success = 0,
+};
+
+volatile sig_atomic_t flag = 0;
+
+void handler(int signum) {
+  flag = 1;
+}
+
+int func(void *data) {
+  while (!flag) {
+  }
+  return 0;
+}
+
+int main(void) {
+  signal(SIGUSR1, handler);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: singal function should not be called in a multithreaded program [bugprone-signal-in-multithreaded-program]
+  thrd_t tid;
+
+  if (thrd_success != thrd_create(, func, NULL)) {
+  }
+  return 0;
+}
Index: 

[PATCH] D75229: [clang-tidy] Add signal-in-multithreaded-program check

2020-04-05 Thread Kocsis Ábel via Phabricator via cfe-commits
abelkocsis marked 2 inline comments as done.
abelkocsis added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp:33-50
+void SignalInMultithreadedProgramCheck::registerMatchers(MatchFinder *Finder) {
+  auto signalCall =
+  callExpr(
+  ignoringImpCasts(hasDescendant(declRefExpr(hasDeclaration(
+  functionDecl(allOf(hasName("signal"), parameterCountIs(2),
+ hasParameter(0, hasType(isInteger())
+  .bind("signal");

steakhal wrote:
> I apologize for interrupting the review.
> Should we use `hasDescendant` for matching like everything in translation 
> unit?
> 
> Wouldn't it be more performant to collect all the `signal` calls in a set and 
> set a bool variable if a `ThreadList` function seen? 
> At the end of the analysis of the translation unit, emit warnings for each 
> recorded `signal` call if the variable was set //(aka. we are in 
> multithreaded environment)//.
> 
> Treat this comment rather a question since I'm not really familiar with 
> `clang-tidy`.
I updated the checker not exactly in that way you mentioned, but I think you 
are right that we should not match for all `translationUnitDecl`.


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75229/new/

https://reviews.llvm.org/D75229



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


[PATCH] D77493: [clang-tidy] Add do-not-refer-atomic-twice check

2020-04-05 Thread Nathan James via Phabricator via cfe-commits
njames93 added a comment.

In my mind this check is definitely in the realm of the static analyser, 
clang-tidy just isn't designed for this.




Comment at: clang-tools-extra/docs/clang-tidy/checks/list.rst:137
`cppcoreguidelines-avoid-goto `_,
+   `cppcoreguidelines-avoid-non-const-global-variables 
`_,
`cppcoreguidelines-init-variables 
`_, "Yes"

All these artefacts from the add-new-check script don't need to be in here.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-do-not-refer-atomic-twice.cpp:79
+
+int main() {}

don't need a main call in the test case


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77493/new/

https://reviews.llvm.org/D77493



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


[PATCH] D77502: [clang][CodeGen] Handle throw expression in conditional operator constant folding

2020-04-05 Thread Raul Tambre via Phabricator via cfe-commits
tambre created this revision.
tambre added a reviewer: rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
tambre edited the summary of this revision.

We're smart and do constant folding when emitting conditional operators.
Thus we emit the live value as a lvalue. This doesn't work if the live value is 
a throw expression.
Handle this by emitting the throw and returning the dead value as the lvalue.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77502

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/test/CodeGenCXX/throw-expressions.cpp


Index: clang/test/CodeGenCXX/throw-expressions.cpp
===
--- clang/test/CodeGenCXX/throw-expressions.cpp
+++ clang/test/CodeGenCXX/throw-expressions.cpp
@@ -79,6 +79,13 @@
   // CHECK-NOT: call {{.*}}@_ZN6DR15601AD1Ev
   // CHECK: call {{.*}} @__cxa_atexit({{.*}} @_ZN6DR15601AD1Ev {{.*}} 
@_ZGRN6DR15601rE
   // CHECK-NOT: call {{.*}}@_ZN6DR15601AD1Ev
+
+  // PR28184
+  void conditional_throw()
+  {
+int a, b;
+(true ? throw 0 : a) = 0;
+  }
 }
 
 // CHECK-LABEL: define void @_Z5test7b(
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -4331,6 +4331,11 @@
   // If the true case is live, we need to track its region.
   if (CondExprBool)
 incrementProfileCounter(expr);
+  // If a throw expression we need to return dead as lvalue.
+  if (auto *ThrowExpr = dyn_cast(live->IgnoreParens())) {
+EmitCXXThrowExpr(ThrowExpr);
+return EmitLValue(dead);
+  }
   return EmitLValue(live);
 }
   }


Index: clang/test/CodeGenCXX/throw-expressions.cpp
===
--- clang/test/CodeGenCXX/throw-expressions.cpp
+++ clang/test/CodeGenCXX/throw-expressions.cpp
@@ -79,6 +79,13 @@
   // CHECK-NOT: call {{.*}}@_ZN6DR15601AD1Ev
   // CHECK: call {{.*}} @__cxa_atexit({{.*}} @_ZN6DR15601AD1Ev {{.*}} @_ZGRN6DR15601rE
   // CHECK-NOT: call {{.*}}@_ZN6DR15601AD1Ev
+
+  // PR28184
+  void conditional_throw()
+  {
+int a, b;
+(true ? throw 0 : a) = 0;
+  }
 }
 
 // CHECK-LABEL: define void @_Z5test7b(
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -4331,6 +4331,11 @@
   // If the true case is live, we need to track its region.
   if (CondExprBool)
 incrementProfileCounter(expr);
+  // If a throw expression we need to return dead as lvalue.
+  if (auto *ThrowExpr = dyn_cast(live->IgnoreParens())) {
+EmitCXXThrowExpr(ThrowExpr);
+return EmitLValue(dead);
+  }
   return EmitLValue(live);
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D77484: [Vector] Pass VectLib to LTO backend so TLI build correct vector function list

2020-04-05 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a subscriber: gchatelet.
tejohnson added a comment.

We're trying to move towards encoding all of this in the IR. And in fact, I 
recently implemented a series of patches to make the TLI to be built 
per-function, and along with some patches from @gchatelet to encode 
-fno-builtin* as function attributes, we now handle that part of the TLII with 
IR. See D67923  which is the last patch in the 
series. We should encode the vectlib as function attributes similarly, and just 
thread that through to the TLI.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77484/new/

https://reviews.llvm.org/D77484



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


[PATCH] D77482: [clang-tools-extra] NFC: Fix trivial typo in documents and comments

2020-04-05 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

In D77482#1962272 , @kiszk wrote:

> I have done in https://reviews.llvm.org/D77458


Just abandon this revision.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77482/new/

https://reviews.llvm.org/D77482



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


[PATCH] D77499: [ASTMatchers] Matchers that take enumerations args provide hints with invalid arguments

2020-04-05 Thread Nathan James via Phabricator via cfe-commits
njames93 created this revision.
njames93 added a reviewer: klimek.
Herald added subscribers: cfe-commits, mgorny.
Herald added a reviewer: jdoerfert.
Herald added a project: clang.
njames93 edited the summary of this revision.
Herald added a subscriber: dexonsmith.

This adds support for giving hints when using dynamic matchers with enum args. 
Take this query, I couldn't figure out why the matcher wasn't working:
(Turns out it needed to be "IntegralToBoolean", but thats another bug itself)

  clang-query> match implicitCastExpr(hasCastKind("CK_IntegralToBoolean"))
  1:1: Error parsing argument 1 for matcher implicitCastExpr.
  1:18: Error building matcher hasCastKind.
  1:30: Incorrect type for arg 1. (Expected = string) != (Actual = String)

With this patch the new behaviour looks like this:

  clang-query> match implicitCastExpr(hasCastKind("CK_IntegralToBoolean"))
  1:1: Error parsing argument 1 for matcher implicitCastExpr.
  1:18: Error building matcher hasCastKind.
  1:30: Unknown value 'CK_IntegralToBoolean' for arg 1; did you mean 
'IntegralToBoolean'

There are no test cases for this yet as there simply isn't any infrastructure 
for testing errors reported when parsing args that I can see.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77499

Files:
  clang/include/clang/ASTMatchers/Dynamic/Diagnostics.h
  clang/lib/ASTMatchers/Dynamic/CMakeLists.txt
  clang/lib/ASTMatchers/Dynamic/Diagnostics.cpp
  clang/lib/ASTMatchers/Dynamic/Marshallers.cpp
  clang/lib/ASTMatchers/Dynamic/Marshallers.h

Index: clang/lib/ASTMatchers/Dynamic/Marshallers.h
===
--- clang/lib/ASTMatchers/Dynamic/Marshallers.h
+++ clang/lib/ASTMatchers/Dynamic/Marshallers.h
@@ -29,6 +29,7 @@
 #include "clang/Basic/OpenMPKinds.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/None.h"
+#include "llvm/ADT/Optional.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSwitch.h"
@@ -64,6 +65,10 @@
   static ArgKind getKind() {
 return ArgKind(ArgKind::AK_String);
   }
+
+  static llvm::Optional getBestGuess(const VariantValue &) {
+return llvm::None;
+  }
 };
 
 template <>
@@ -82,6 +87,10 @@
   static ArgKind getKind() {
 return ArgKind(ASTNodeKind::getFromNodeKind());
   }
+
+  static llvm::Optional getBestGuess(const VariantValue &) {
+return llvm::None;
+  }
 };
 
 template <> struct ArgTypeTraits {
@@ -91,8 +100,10 @@
 return Value.getBoolean();
   }
 
-  static ArgKind getKind() {
-return ArgKind(ArgKind::AK_Boolean);
+  static ArgKind getKind() { return ArgKind(ArgKind::AK_Boolean); }
+
+  static llvm::Optional getBestGuess(const VariantValue &) {
+return llvm::None;
   }
 };
 
@@ -103,8 +114,10 @@
 return Value.getDouble();
   }
 
-  static ArgKind getKind() {
-return ArgKind(ArgKind::AK_Double);
+  static ArgKind getKind() { return ArgKind(ArgKind::AK_Double); }
+
+  static llvm::Optional getBestGuess(const VariantValue &) {
+return llvm::None;
   }
 };
 
@@ -115,8 +128,10 @@
 return Value.getUnsigned();
   }
 
-  static ArgKind getKind() {
-return ArgKind(ArgKind::AK_Unsigned);
+  static ArgKind getKind() { return ArgKind(ArgKind::AK_Unsigned); }
+
+  static llvm::Optional getBestGuess(const VariantValue &) {
+return llvm::None;
   }
 };
 
@@ -141,6 +156,8 @@
   static ArgKind getKind() {
 return ArgKind(ArgKind::AK_String);
   }
+
+  static llvm::Optional getBestGuess(const VariantValue );
 };
 
 template <> struct ArgTypeTraits {
@@ -164,6 +181,8 @@
   static ArgKind getKind() {
 return ArgKind(ArgKind::AK_String);
   }
+
+  static llvm::Optional getBestGuess(const VariantValue );
 };
 
 template <> struct ArgTypeTraits {
@@ -186,6 +205,8 @@
   }
 
   static ArgKind getKind() { return ArgKind(ArgKind::AK_String); }
+
+  static llvm::Optional getBestGuess(const VariantValue );
 };
 
 /// Matcher descriptor interface.
@@ -319,7 +340,7 @@
 /// polymorphic matcher. For the former, we just construct the VariantMatcher.
 /// For the latter, we instantiate all the possible Matcher of the poly
 /// matcher.
-static VariantMatcher outvalueToVariantMatcher(const DynTypedMatcher ) {
+inline VariantMatcher outvalueToVariantMatcher(const DynTypedMatcher ) {
   return VariantMatcher::SingleMatcher(Matcher);
 }
 
@@ -496,9 +517,16 @@
 
 #define CHECK_ARG_TYPE(index, type)\
   if (!ArgTypeTraits::is(Args[index].Value)) {   \
-Error->addError(Args[index].Range, Error->ET_RegistryWrongArgType) \
-<< (index + 1) << ArgTypeTraits::getKind().asString()\
-<< Args[index].Value.getTypeAsString();\
+if (llvm::Optional BestGuess =\
+ArgTypeTraits::getBestGuess(Args[index].Value)) {\
+  Error->addError(Args[index].Range,   \
+   

[PATCH] D77498: [Hexagon] Select lld as the default linker for linux-musl target

2020-04-05 Thread Sid Manning via Phabricator via cfe-commits
sidneym created this revision.
sidneym added reviewers: adasgupt, bcain, kparzysz, bcahoon, shankare.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When the target is hexagon-unknown-linux-musl select lld as the default linker.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77498

Files:
  clang/lib/Driver/ToolChains/Hexagon.h
  clang/test/Driver/hexagon-toolchain-elf.c


Index: clang/test/Driver/hexagon-toolchain-elf.c
===
--- clang/test/Driver/hexagon-toolchain-elf.c
+++ clang/test/Driver/hexagon-toolchain-elf.c
@@ -674,3 +674,15 @@
 // RUN:   | FileCheck -check-prefix=CHECK090 %s
 // CHECK090-NOT:  -fno-use-init-array
 // 
-
+// Check default linker for musl
+// 
-
+// RUN: %clang -### -target hexagon-unknown-linux-musl %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK091 %s
+// CHECK091:  ld.lld
+// 
-
+// Check default linker for elf
+// 
-
+// RUN: %clang -### -target hexagon-unknown-elf %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK092 %s
+// CHECK092:  hexagon-link
+// 
-
Index: clang/lib/Driver/ToolChains/Hexagon.h
===
--- clang/lib/Driver/ToolChains/Hexagon.h
+++ clang/lib/Driver/ToolChains/Hexagon.h
@@ -81,7 +81,9 @@
   const llvm::opt::ArgList ,
   llvm::opt::ArgStringList ) const override;
 
-  const char *getDefaultLinker() const override { return "hexagon-link"; }
+  const char *getDefaultLinker() const override {
+return getTriple().isMusl() ? "ld.lld" : "hexagon-link";
+  }
 
   CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList ) const 
override;
 


Index: clang/test/Driver/hexagon-toolchain-elf.c
===
--- clang/test/Driver/hexagon-toolchain-elf.c
+++ clang/test/Driver/hexagon-toolchain-elf.c
@@ -674,3 +674,15 @@
 // RUN:   | FileCheck -check-prefix=CHECK090 %s
 // CHECK090-NOT:  -fno-use-init-array
 // -
+// Check default linker for musl
+// -
+// RUN: %clang -### -target hexagon-unknown-linux-musl %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK091 %s
+// CHECK091:  ld.lld
+// -
+// Check default linker for elf
+// -
+// RUN: %clang -### -target hexagon-unknown-elf %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK092 %s
+// CHECK092:  hexagon-link
+// -
Index: clang/lib/Driver/ToolChains/Hexagon.h
===
--- clang/lib/Driver/ToolChains/Hexagon.h
+++ clang/lib/Driver/ToolChains/Hexagon.h
@@ -81,7 +81,9 @@
   const llvm::opt::ArgList ,
   llvm::opt::ArgStringList ) const override;
 
-  const char *getDefaultLinker() const override { return "hexagon-link"; }
+  const char *getDefaultLinker() const override {
+return getTriple().isMusl() ? "ld.lld" : "hexagon-link";
+  }
 
   CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList ) const override;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [clang] b670ab7 - recommit 1b978ddba05c [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

2020-04-05 Thread Joerg Sonnenberger via cfe-commits
On Mon, Mar 23, 2020 at 09:09:31AM -0700, Yaxun Liu via cfe-commits wrote:
> 
> Author: Yaxun (Sam) Liu
> Date: 2020-03-23T12:09:07-04:00
> New Revision: b670ab7b6b3d2f26179213be1da1d4ba376f50a3
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/b670ab7b6b3d2f26179213be1da1d4ba376f50a3
> DIFF: 
> https://github.com/llvm/llvm-project/commit/b670ab7b6b3d2f26179213be1da1d4ba376f50a3.diff
> 
> LOG: recommit 1b978ddba05c [CUDA][HIP][OpenMP] Emit deferred diagnostics by a 
> post-parsing AST travese

This change is responsible for a significant performance regression.
Somewhat reduced example is attached. With -fopenmp, it needs ~5s,
without 0.02s.

Joerg
   ;
;
namespace std {
   inline namespace __1 {
  template struct char_traits;
  template  class basic_ostream;
  typedef basic_ostream ostream;
  template basic_ostream<_Traits>& 
operator<<(basic_ostream<_Traits>& __os, const char* __str) ;
  extern ostream cerr;
  }
   ;
   }
template class flet {
   public: flet(T , const T )  ;
   };
;
   template class _scoped_numeral {
   typedef typename Manager::numeral numeral;
   public: _scoped_numeral(Manager ) ;
 operator numeral&() ;


   };
template class 
buffer {
   public: ;
 unsigned size() const ;
 ;
  ;
 T & operator[](unsigned idxT ) ;
 };
template class buffer ;
template class sbuffer : public 
buffer {
   };
class mpz {
public: mpz(int v) ;
   };
  template class mpz_manager {
   public:  ;
 typedef mpz numeral;




  void mul2k(mpz , 
unsigned k, mpz r) ;
  };
typedef mpz_manager unsynch_mpz_manager;
typedef _scoped_numeral scoped_mpz;
class mpq {
};
  template class mpq_manager : public mpz_manager {
public: typedef mpq numeral;
  bool is_zero;
 void mul( mpq b, mpq ) ;



   void set(mpq 
, mpq source) ;



   };
typedef mpq_manager unsynch_mpq_manager;
typedef _scoped_numeral scoped_mpq;
;
template class interval_manager {
   public: ;
   typedef typename C::interval interval;

   bool is_P(interval n) const ;
  void set(interval , interval s);
  void neg(interval 
a, interval );
 void add(interval a, interval b, interval );
   void 
mul(interval a, interval b, interval );

 };
template class _scoped_interval {
   typedef typename Manager::interval interval;
   public: _scoped_interval(Manager ) ;
 operator interval&() ;
   };
namespace realclosure {
   class num;
   ;
   class manager {
  struct imp;
  typedef num numeral;






};
   struct value;
   class num {
  friend class 

[PATCH] D77482: [clang-tools-extra] NFC: Fix trivial typo in documents and comments

2020-04-05 Thread Kazuaki Ishizaki via Phabricator via cfe-commits
kiszk added a comment.

I have done in https://reviews.llvm.org/D77458


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77482/new/

https://reviews.llvm.org/D77482



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


[PATCH] D77474: [analyzer][MallocChecker] Make NewDeleteLeaks depend on DynamicMemoryModeling rather than NewDelete

2020-04-05 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

Btw this branch is about 7 months old, and I just now remembered why I haven't 
rushed publishing it.

My ultimate idea (as opposed to the two detailed in the summary) was to 
introduce a subchecker system in MallocChecker, which also strongly ties into 
D67336 . The core of the checker 
(`unix.DynamicMemoryModeling`) would be responsible for dispatching from 
regular checker callbacks upon seeing a call to a memory management function, 
and providing the general utilities for modeling it. Smaller subcheckers would 
then use this interface to implement the modeling of specific functions. For 
instance, the we could create `NewDeleteChecker`, a subchecker of 
`DynamicMemoryModeling`, which would get control when stumbling upon a call to 
a new/delete operator.

This would allow us to spread the implementation into smaller files, which is 
great, but upon taking a look at D68165 , you 
can see that the bulk of the code isn't really in these modeling functions. For 
such a change to really make sense, the responsibility of bug emission (like 
`ReportFunctionPointerFree`) should be moved into the subcheckers as well. This 
would achieve my goal of smaller, self-contained subcheckers implementing 
something that we previously did with giants like MallocChecker is now.  As to 
how I should //actually// pull this off (make an event about memory being 
deallocated to the subcheckers, make them check for bugs? make an event about 
finding a leak, double delete, etc?) is a different issue, but I'll see what 
makes more sense, if I choose to go forth with this project.

I do now believe that though that all of these changes would be orthogonal to 
this one. Just thought I'd share :^).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77474/new/

https://reviews.llvm.org/D77474



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


[PATCH] D77491: [Sema] Fix incompatible builtin redeclarations in non-global scope

2020-04-05 Thread Raul Tambre via Phabricator via cfe-commits
tambre created this revision.
tambre added a reviewer: rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

We didn't mark them previously as non-builtin in non-global scope if we 
determined they were incompatible redeclarations.
This caused problems down the line with them still being treated as builtins 
and having attributes added and the like.
Fix this by marking them non-builtin in any case. Handle redeclarations of such 
redeclarations as if they were redeclarations of the builtins by checking if 
the previous redeclaration was reverted from being a builtin.

Fixes PR45410.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77491

Files:
  clang/include/clang/Basic/IdentifierTable.h
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CodeGen/builtin-redeclaration.c


Index: clang/test/CodeGen/builtin-redeclaration.c
===
--- /dev/null
+++ clang/test/CodeGen/builtin-redeclaration.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -emit-llvm-only %s
+
+// PR45410
+// Ensure we mark local extern redeclarations with a different type as 
non-builtin.
+void non_builtin() {
+  extern float exp();
+  exp(); // Will crash due to wrong number of arguments if this calls the 
builtin.
+}
+
+// PR45410
+// We mark exp() builtin as const with -fno-math-errno (default).
+// We mustn't do that for extern redeclarations of builtins where the type 
differs.
+float attribute() {
+  extern float exp();
+  return exp(1);
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -3756,24 +3756,21 @@
   // If the previous declaration was an implicitly-generated builtin
   // declaration, then at the very least we should use a specialized note.
   unsigned BuiltinID;
-  if (Old->isImplicit() && (BuiltinID = Old->getBuiltinID())) {
+  bool RevertedBuiltin{Old->getIdentifier()->hasRevertedBuiltin()};
+  if (Old->isImplicit() &&
+  ((BuiltinID = Old->getBuiltinID()) || RevertedBuiltin)) {
 // If it's actually a library-defined builtin function like 'malloc'
 // or 'printf', just warn about the incompatible redeclaration.
-if (Context.BuiltinInfo.isPredefinedLibFunction(BuiltinID)) {
+// Also warn if it's a redeclaration of a builtin redeclaration. We know if
+// it is if the previous declaration is a reverted builtin.
+if (RevertedBuiltin ||
+Context.BuiltinInfo.isPredefinedLibFunction(BuiltinID)) {
   Diag(New->getLocation(), diag::warn_redecl_library_builtin) << New;
   Diag(OldLocation, diag::note_previous_builtin_declaration)
 << Old << Old->getType();
 
-  // If this is a global redeclaration, just forget hereafter
-  // about the "builtin-ness" of the function.
-  //
-  // Doing this for local extern declarations is problematic.  If
-  // the builtin declaration remains visible, a second invalid
-  // local declaration will produce a hard error; if it doesn't
-  // remain visible, a single bogus local redeclaration (which is
-  // actually only a warning) could break all the downstream code.
-  if (!New->getLexicalDeclContext()->isFunctionOrMethod())
-New->getIdentifier()->revertBuiltin();
+  // Forget hereafter about the "builtin-ness" of the function.
+  New->getIdentifier()->revertBuiltin();
 
   return false;
 }
Index: clang/include/clang/Basic/IdentifierTable.h
===
--- clang/include/clang/Basic/IdentifierTable.h
+++ clang/include/clang/Basic/IdentifierTable.h
@@ -223,7 +223,7 @@
   }
   void setObjCKeywordID(tok::ObjCKeywordKind ID) { ObjCOrBuiltinID = ID; }
 
-  /// True if setNotBuiltin() was called.
+  /// True if revertBuiltin() was called.
   bool hasRevertedBuiltin() const {
 return ObjCOrBuiltinID == tok::NUM_OBJC_KEYWORDS;
   }


Index: clang/test/CodeGen/builtin-redeclaration.c
===
--- /dev/null
+++ clang/test/CodeGen/builtin-redeclaration.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -emit-llvm-only %s
+
+// PR45410
+// Ensure we mark local extern redeclarations with a different type as non-builtin.
+void non_builtin() {
+  extern float exp();
+  exp(); // Will crash due to wrong number of arguments if this calls the builtin.
+}
+
+// PR45410
+// We mark exp() builtin as const with -fno-math-errno (default).
+// We mustn't do that for extern redeclarations of builtins where the type differs.
+float attribute() {
+  extern float exp();
+  return exp(1);
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -3756,24 +3756,21 @@
   // If the previous declaration was an implicitly-generated builtin
   // declaration, then at the very least we should use a 

[clang] 2c88a48 - [clang] Make libcxx test suite pass again after memcmp changes

2020-04-05 Thread David Zarzycki via cfe-commits

Author: David Zarzycki
Date: 2020-04-05T07:16:47-04:00
New Revision: 2c88a485c71155c19e512f22c54e63ee337282a3

URL: 
https://github.com/llvm/llvm-project/commit/2c88a485c71155c19e512f22c54e63ee337282a3
DIFF: 
https://github.com/llvm/llvm-project/commit/2c88a485c71155c19e512f22c54e63ee337282a3.diff

LOG: [clang] Make libcxx test suite pass again after memcmp changes

Added: 


Modified: 
clang/lib/AST/ExprConstant.cpp

Removed: 




diff  --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index a83b2e24e17f..7508bcbc365d 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -11154,9 +11154,11 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const 
CallExpr *E,
 CharTy1, E->getArg(0)->getType()->getPointeeType()) &&
 Info.Ctx.hasSameUnqualifiedType(CharTy1, CharTy2)));
 
-// For memcmp, allow comparing any arrays of '[[un]signed] char',
-// but no other types.
-if (IsRawByte && !(CharTy1->isCharType() && CharTy2->isCharType())) {
+// For memcmp, allow comparing any arrays of '[[un]signed] char' or
+// 'char8_t', but no other types.
+bool IsChar = CharTy1->isCharType() && CharTy2->isCharType();
+bool IsChar8 = CharTy1->isChar8Type() && CharTy2->isChar8Type();
+if (IsRawByte && !IsChar && !IsChar8) {
   // FIXME: Consider using our bit_cast implementation to support this.
   Info.FFDiag(E, diag::note_constexpr_memcmp_unsupported)
   << (std::string("'") + Info.Ctx.BuiltinInfo.getName(BuiltinOp) + "'")



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


Re: [libcxx-dev] [clang] 4ede887 - PR45402: Make the restrictions on constant evaluation of memcmp and

2020-04-05 Thread David Zarzycki via cfe-commits
Hi Richard,

I'm going to commit a narrow fix to clang to make the libcxx test suite pass 
again by allowing char8_t again. If you feel that this is the wrong long-term 
solution, please help the libcxx folks with whatever adjustments they need.

Thanks!

Dave


On Sat, Apr 4, 2020, at 9:55 AM, David Zarzycki via libcxx-dev wrote:
> Hi Richard,
> 
> This breaks libcxx. Can we please revert this or is a quick fix to 
> libcxx possible?
> 
> 
> FAIL: libc++ :: 
> std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp
>  (58624 of 62672)
>  TEST 'libc++ :: 
> std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp'
>  FAILED 
> Command: ['/p/tllvm/bin/clang++', '-o', 
> '/tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/Output/compare.pass.cpp.o',
>  '-x', 'c++', 
> '/home/dave/s/lp/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp',
>  '-c', '-v', '-Werror=thread-safety', '-std=c++2a', '-include', 
> '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', '-nostdinc++', 
> '-I/home/dave/s/lp/libcxx/include', 
> '-I/tmp/_update_lc/t/projects/libcxx/include/c++build', 
> '-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS', 
> '-D__STDC_CONSTANT_MACROS', '-I/home/dave/s/lp/libcxx/test/support', 
> '-ftemplate-depth=270', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall', 
> '-Wextra', '-Werror', '-Wuser-defined-warnings', '-Wshadow', 
> '-Wno-unused-command-line-argument', '-Wno-attributes', 
> '-Wno-pessimizing-move', '-Wno-c++11-extensions', 
> '-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare', 
> '-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', '-c']
> Exit Code: 1
> Standard Error:
> --
> clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
> 22127da8f17c03c69231f3631472f7f99ad9cb7f)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /p/tllvm/bin
> Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
> Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
> Candidate multilib: .;@m64
> Candidate multilib: 32;@m32
> Selected multilib: .;@m64
>  (in-process)
>  "/p/tllvm/bin/clang-11" -cc1 -triple x86_64-unknown-linux-gnu 
> -emit-obj -mrelax-all -disable-free -disable-llvm-verifier 
> -discard-value-names -main-file-name compare.pass.cpp 
> -mrelocation-model static -mthread-model posix -mframe-pointer=all 
> -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables 
> -target-cpu x86-64 -dwarf-column-info -fno-split-dwarf-inlining 
> -debugger-tuning=gdb -v -nostdinc++ -resource-dir 
> /p/tllvm/lib64/clang/11.0.0 -include 
> /home/dave/s/lp/libcxx/test/support/nasty_macros.h -I 
> /home/dave/s/lp/libcxx/include -I 
> /tmp/_update_lc/t/projects/libcxx/include/c++build -D 
> __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS 
> -I /home/dave/s/lp/libcxx/test/support -D 
> _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -internal-isystem 
> /usr/local/include -internal-isystem 
> /p/tllvm/lib64/clang/11.0.0/include -internal-externc-isystem /include 
> -internal-externc-isystem /usr/include -Werror=thread-safety -Wall 
> -Wextra -Werror -Wuser-defined-warnings -Wshadow 
> -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move 
> -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type 
> -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code 
> -std=c++2a -fdeprecated-macro -fdebug-compilation-dir 
> /tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t
>  -ftemplate-depth 270 -ferror-limit 19 -fgnuc-version=4.2.1 
> -fno-implicit-modules -fcxx-exceptions -fexceptions -faddrsig -o 
> /tmp/_update_lc/t/projects/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/Output/compare.pass.cpp.o
>  -x c++ 
> /home/dave/s/lp/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp
> clang -cc1 version 11.0.0 based upon LLVM 11.0.0git default target 
> x86_64-unknown-linux-gnu
> ignoring nonexistent directory "/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /home/dave/s/lp/libcxx/include
>  /tmp/_update_lc/t/projects/libcxx/include/c++build
>  /home/dave/s/lp/libcxx/test/support
>  /usr/local/include
>  /p/tllvm/lib64/clang/11.0.0/include
>  /usr/include
> End of search list.
> /home/dave/s/lp/libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char8_t/compare.pass.cpp:53:19:
>  error: static_assert expression is not an integral constant expression
> static_assert(test_constexpr(), "" );
>   ^~~~
> 

[PATCH] D74692: [clang-tidy][bugprone-use-after-move] Warn on std::move for consts

2020-04-05 Thread Zinovy Nis via Phabricator via cfe-commits
zinovy.nis updated this revision to Diff 255128.
zinovy.nis added a comment.

Rebase over the current master.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74692/new/

https://reviews.llvm.org/D74692

Files:
  clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/bugprone-use-after-move.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-use-after-move.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-use-after-move.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-use-after-move.cpp
@@ -129,6 +129,16 @@
   // CHECK-NOTES: [[@LINE-3]]:15: note: move occurred here
 }
 
+void simpleConst() {
+  const A a;
+  a.foo();
+  A other_a = std::move(a);
+  a.foo();
+  // CHECK-NOTES: [[@LINE-1]]:3: warning: 'a' used after it was moved; move of a 'const' argument has no effect
+  // CHECK-NOTES: [[@LINE-3]]:15: note: move occurred here
+  // CHECK-NOTES: [[@LINE-6]]:11: note: variable 'a' declared const here
+}
+
 // A warning should only be emitted for one use-after-move.
 void onlyFlagOneUseAfterMove() {
   A a;
@@ -314,8 +324,21 @@
 auto lambda = [a] {
   std::move(a);
   a.foo();
-  // CHECK-NOTES: [[@LINE-1]]:7: warning: 'a' used after it was moved
+  // CHECK-NOTES: [[@LINE-1]]:7: warning: 'a' used after it was moved; move of a 'const' argument has no effect
   // CHECK-NOTES: [[@LINE-3]]:7: note: move occurred here
+  // CHECK-NOTES: [[@LINE-5]]:20: note: variable 'a' captured const here
+};
+  }
+  // Use-after-moves inside a lambda should be detected.
+  {
+A a;
+// Implicit capture
+auto lambda = [=] {
+  std::move(a);
+  a.foo();
+  // CHECK-NOTES: [[@LINE-1]]:7: warning: 'a' used after it was moved; move of a 'const' argument has no effect
+  // CHECK-NOTES: [[@LINE-3]]:7: note: move occurred here
+  // CHECK-NOTES: [[@LINE-5]]:20: note: variable 'a' implicitly captured const here
 };
   }
   // This is just as true if the variable was declared inside the lambda.
@@ -721,14 +744,16 @@
 const A a;
 std::move(a);
 passByConstPointer();
-// CHECK-NOTES: [[@LINE-1]]:25: warning: 'a' used after it was moved
+// CHECK-NOTES: [[@LINE-1]]:25: warning: 'a' used after it was moved; move of a 'const' argument has no effect
 // CHECK-NOTES: [[@LINE-3]]:5: note: move occurred here
+// CHECK-NOTES: [[@LINE-5]]:13: note: variable 'a' declared const here
   }
   const A a;
   std::move(a);
   passByConstReference(a);
-  // CHECK-NOTES: [[@LINE-1]]:24: warning: 'a' used after it was moved
+  // CHECK-NOTES: [[@LINE-1]]:24: warning: 'a' used after it was moved; move of a 'const' argument has no effect
   // CHECK-NOTES: [[@LINE-3]]:3: note: move occurred here
+  // CHECK-NOTES: [[@LINE-5]]:11: note: variable 'a' declared const here
 }
 
 // Clearing a standard container using clear() is treated as a
Index: clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
@@ -373,14 +373,36 @@
 }
 
 static void emitDiagnostic(const Expr *MovingCall, const DeclRefExpr *MoveArg,
-   const UseAfterMove , ClangTidyCheck *Check,
+   const UseAfterMove ,
+   const LambdaExpr *Lambda, ClangTidyCheck *Check,
ASTContext *Context) {
   SourceLocation UseLoc = Use.DeclRef->getExprLoc();
   SourceLocation MoveLoc = MovingCall->getExprLoc();
+  int MoveArgIsConst = MoveArg->getType().isConstQualified();
 
-  Check->diag(UseLoc, "'%0' used after it was moved")
-  << MoveArg->getDecl()->getName();
+  Check->diag(UseLoc, "'%0' used after it was moved%select{|; move of a "
+  "'const' argument has no effect}1")
+  << MoveArg->getDecl()->getName() << MoveArgIsConst;
   Check->diag(MoveLoc, "move occurred here", DiagnosticIDs::Note);
+  if (MoveArgIsConst) {
+if (Lambda) {
+  for (const auto  : Lambda->captures()) {
+if (MoveArg->getDecl() == Capture.getCapturedVar()) {
+  int IsExplicitCapture = Capture.isExplicit();
+  Check->diag(IsExplicitCapture ? Capture.getLocation()
+: Lambda->getCaptureDefaultLoc(),
+  "variable %0 %select{implicitly|}1 captured const here",
+  DiagnosticIDs::Note)
+  << Capture.getCapturedVar() << IsExplicitCapture;
+  break;
+}
+  }
+} else {
+  Check->diag(MoveArg->getDecl()->getLocation(),
+  "variable '%0' declared const here", DiagnosticIDs::Note);
+}
+  }
+
   if (Use.EvaluationOrderUndefined) {
 Check->diag(UseLoc,
 "the use and move are unsequenced, i.e. 

[PATCH] D77458: [clang-tools-extra] NFC: Fix trivial typo in documents and comments

2020-04-05 Thread Kazuaki Ishizaki via Phabricator via cfe-commits
kiszk updated this revision to Diff 255120.
kiszk added a comment.

This include the fix of the build failure at 
http://lab.llvm.org:8011/builders/clang-cmake-armv7-global-isel/builds/7450/steps/ninja%20check%201/logs/FAIL%3A%20Clang%20Tools%3A%3Afuchsia-multiple-inheritance.cpp


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77458/new/

https://reviews.llvm.org/D77458

Files:
  clang-tools-extra/clang-change-namespace/ChangeNamespace.cpp
  clang-tools-extra/clang-change-namespace/ChangeNamespace.h
  clang-tools-extra/clang-doc/Generators.cpp
  clang-tools-extra/clang-doc/Serialize.cpp
  clang-tools-extra/clang-include-fixer/IncludeFixer.h
  clang-tools-extra/clang-include-fixer/IncludeFixerContext.h
  clang-tools-extra/clang-include-fixer/SymbolIndexManager.cpp
  clang-tools-extra/clang-include-fixer/find-all-symbols/FindAllSymbols.cpp
  
clang-tools-extra/clang-include-fixer/find-all-symbols/tool/run-find-all-symbols.py
  clang-tools-extra/clang-include-fixer/tool/clang-include-fixer.py
  clang-tools-extra/clang-move/Move.cpp
  clang-tools-extra/clang-reorder-fields/ReorderFieldsAction.cpp
  clang-tools-extra/clang-tidy/abseil/DurationFactoryScaleCheck.cpp
  clang-tools-extra/clang-tidy/abseil/DurationRewriter.cpp
  clang-tools-extra/clang-tidy/abseil/TimeSubtractionCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/FoldInitTypeCheck.cpp
  
clang-tools-extra/clang-tidy/bugprone/MisplacedOperatorInStrlenInAllocCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SizeofExpressionCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SuspiciousEnumUsageCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SuspiciousMissingCommaCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/UnusedRaiiCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/OwningMemoryCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
  clang-tools-extra/clang-tidy/fuchsia/MultipleInheritanceCheck.h
  clang-tools-extra/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
  clang-tools-extra/clang-tidy/hicpp/MultiwayPathsCoveredCheck.cpp
  clang-tools-extra/clang-tidy/misc/NoRecursionCheck.cpp
  clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
  clang-tools-extra/clang-tidy/modernize/MakeSmartPtrCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseNullptrCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseTrailingReturnTypeCheck.cpp
  clang-tools-extra/clang-tidy/readability/ConstReturnTypeCheck.cpp
  clang-tools-extra/clang-tidy/readability/ImplicitBoolConversionCheck.cpp
  clang-tools-extra/clang-tidy/readability/IsolateDeclarationCheck.cpp
  clang-tools-extra/clang-tidy/readability/MakeMemberFunctionConstCheck.cpp
  clang-tools-extra/clang-tidy/readability/NamespaceCommentCheck.cpp
  clang-tools-extra/clang-tidy/readability/UppercaseLiteralSuffixCheck.cpp
  clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.cpp
  clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.h
  clang-tools-extra/clangd/AST.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/Diagnostics.cpp
  clang-tools-extra/clangd/FindSymbols.h
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/FindTarget.h
  clang-tools-extra/clangd/FormattedString.cpp
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/Hover.h
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/PathMapping.cpp
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Quality.cpp
  clang-tools-extra/clangd/QueryDriverDatabase.cpp
  clang-tools-extra/clangd/index/Background.cpp
  clang-tools-extra/clangd/index/Serialization.cpp
  clang-tools-extra/clangd/index/SymbolOrigin.h
  clang-tools-extra/clangd/index/dex/Trigram.cpp
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
  clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/tool/ClangdMain.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
  clang-tools-extra/clangd/unittests/FindTargetTests.cpp
  clang-tools-extra/clangd/unittests/HeaderSourceSwitchTests.cpp
  clang-tools-extra/clangd/unittests/PathMappingTests.cpp
  clang-tools-extra/clangd/unittests/RenameTests.cpp
  clang-tools-extra/clangd/unittests/SymbolInfoTests.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-misplaced-pointer-arithmetic-in-alloc.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-virtual-near-miss.rst
  

[clang-tools-extra] dd5571d - [clang-tools-extra] NFC: Fix trivial typo in documents and comments

2020-04-05 Thread Kazuaki Ishizaki via cfe-commits

Author: Kazuaki Ishizaki
Date: 2020-04-05T15:28:40+09:00
New Revision: dd5571d51a0f6164cb66d02c8cd0e7032e42abe4

URL: 
https://github.com/llvm/llvm-project/commit/dd5571d51a0f6164cb66d02c8cd0e7032e42abe4
DIFF: 
https://github.com/llvm/llvm-project/commit/dd5571d51a0f6164cb66d02c8cd0e7032e42abe4.diff

LOG: [clang-tools-extra] NFC: Fix trivial typo in documents and comments

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

Added: 


Modified: 
clang-tools-extra/clang-change-namespace/ChangeNamespace.cpp
clang-tools-extra/clang-change-namespace/ChangeNamespace.h
clang-tools-extra/clang-doc/Generators.cpp
clang-tools-extra/clang-doc/Serialize.cpp
clang-tools-extra/clang-include-fixer/IncludeFixer.h
clang-tools-extra/clang-include-fixer/IncludeFixerContext.h
clang-tools-extra/clang-include-fixer/SymbolIndexManager.cpp
clang-tools-extra/clang-include-fixer/find-all-symbols/FindAllSymbols.cpp

clang-tools-extra/clang-include-fixer/find-all-symbols/tool/run-find-all-symbols.py
clang-tools-extra/clang-include-fixer/tool/clang-include-fixer.py
clang-tools-extra/clang-move/Move.cpp
clang-tools-extra/clang-reorder-fields/ReorderFieldsAction.cpp
clang-tools-extra/clang-tidy/abseil/DurationFactoryScaleCheck.cpp
clang-tools-extra/clang-tidy/abseil/DurationRewriter.cpp
clang-tools-extra/clang-tidy/abseil/TimeSubtractionCheck.cpp
clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
clang-tools-extra/clang-tidy/bugprone/FoldInitTypeCheck.cpp

clang-tools-extra/clang-tidy/bugprone/MisplacedOperatorInStrlenInAllocCheck.cpp
clang-tools-extra/clang-tidy/bugprone/SizeofExpressionCheck.cpp
clang-tools-extra/clang-tidy/bugprone/SuspiciousEnumUsageCheck.cpp
clang-tools-extra/clang-tidy/bugprone/SuspiciousMissingCommaCheck.cpp
clang-tools-extra/clang-tidy/bugprone/UnusedRaiiCheck.cpp
clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
clang-tools-extra/clang-tidy/cppcoreguidelines/OwningMemoryCheck.cpp
clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
clang-tools-extra/clang-tidy/fuchsia/MultipleInheritanceCheck.h
clang-tools-extra/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
clang-tools-extra/clang-tidy/hicpp/MultiwayPathsCoveredCheck.cpp
clang-tools-extra/clang-tidy/misc/NoRecursionCheck.cpp
clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
clang-tools-extra/clang-tidy/modernize/MakeSmartPtrCheck.cpp
clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
clang-tools-extra/clang-tidy/modernize/UseNullptrCheck.cpp
clang-tools-extra/clang-tidy/modernize/UseTrailingReturnTypeCheck.cpp
clang-tools-extra/clang-tidy/readability/ConstReturnTypeCheck.cpp
clang-tools-extra/clang-tidy/readability/ImplicitBoolConversionCheck.cpp
clang-tools-extra/clang-tidy/readability/IsolateDeclarationCheck.cpp
clang-tools-extra/clang-tidy/readability/MakeMemberFunctionConstCheck.cpp
clang-tools-extra/clang-tidy/readability/NamespaceCommentCheck.cpp
clang-tools-extra/clang-tidy/readability/UppercaseLiteralSuffixCheck.cpp
clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.cpp
clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.h
clang-tools-extra/clangd/AST.cpp
clang-tools-extra/clangd/ClangdLSPServer.h
clang-tools-extra/clangd/Diagnostics.cpp
clang-tools-extra/clangd/FindSymbols.h
clang-tools-extra/clangd/FindTarget.cpp
clang-tools-extra/clangd/FindTarget.h
clang-tools-extra/clangd/FormattedString.cpp
clang-tools-extra/clangd/Hover.cpp
clang-tools-extra/clangd/Hover.h
clang-tools-extra/clangd/ParsedAST.cpp
clang-tools-extra/clangd/PathMapping.cpp
clang-tools-extra/clangd/Preamble.cpp
clang-tools-extra/clangd/Quality.cpp
clang-tools-extra/clangd/QueryDriverDatabase.cpp
clang-tools-extra/clangd/index/Background.cpp
clang-tools-extra/clangd/index/Serialization.cpp
clang-tools-extra/clangd/index/SymbolOrigin.h
clang-tools-extra/clangd/index/dex/Trigram.cpp
clang-tools-extra/clangd/refactor/Rename.cpp
clang-tools-extra/clangd/refactor/Rename.h
clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
clang-tools-extra/clangd/tool/ClangdMain.cpp
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
clang-tools-extra/clangd/unittests/FindTargetTests.cpp
clang-tools-extra/clangd/unittests/HeaderSourceSwitchTests.cpp
clang-tools-extra/clangd/unittests/PathMappingTests.cpp
clang-tools-extra/clangd/unittests/RenameTests.cpp
clang-tools-extra/clangd/unittests/SymbolInfoTests.cpp

[PATCH] D77458: [clang-tools-extra] NFC: Fix trivial typo in documents and comments

2020-04-05 Thread Kazuaki Ishizaki via Phabricator via cfe-commits
kiszk updated this revision to Diff 255119.
kiszk added a comment.

This includes a fix to break the llvm build


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77458/new/

https://reviews.llvm.org/D77458

Files:
  clang-tools-extra/clang-change-namespace/ChangeNamespace.cpp
  clang-tools-extra/clang-change-namespace/ChangeNamespace.h
  clang-tools-extra/clang-doc/Generators.cpp
  clang-tools-extra/clang-doc/Serialize.cpp
  clang-tools-extra/clang-include-fixer/IncludeFixer.h
  clang-tools-extra/clang-include-fixer/IncludeFixerContext.h
  clang-tools-extra/clang-include-fixer/SymbolIndexManager.cpp
  clang-tools-extra/clang-include-fixer/find-all-symbols/FindAllSymbols.cpp
  
clang-tools-extra/clang-include-fixer/find-all-symbols/tool/run-find-all-symbols.py
  clang-tools-extra/clang-include-fixer/tool/clang-include-fixer.py
  clang-tools-extra/clang-move/Move.cpp
  clang-tools-extra/clang-reorder-fields/ReorderFieldsAction.cpp
  clang-tools-extra/clang-tidy/abseil/DurationFactoryScaleCheck.cpp
  clang-tools-extra/clang-tidy/abseil/DurationRewriter.cpp
  clang-tools-extra/clang-tidy/abseil/TimeSubtractionCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/FoldInitTypeCheck.cpp
  
clang-tools-extra/clang-tidy/bugprone/MisplacedOperatorInStrlenInAllocCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SizeofExpressionCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SuspiciousEnumUsageCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SuspiciousMissingCommaCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/UnusedRaiiCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/OwningMemoryCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
  clang-tools-extra/clang-tidy/fuchsia/MultipleInheritanceCheck.h
  clang-tools-extra/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
  clang-tools-extra/clang-tidy/hicpp/MultiwayPathsCoveredCheck.cpp
  clang-tools-extra/clang-tidy/misc/NoRecursionCheck.cpp
  clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
  clang-tools-extra/clang-tidy/modernize/MakeSmartPtrCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseNullptrCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseTrailingReturnTypeCheck.cpp
  clang-tools-extra/clang-tidy/readability/ConstReturnTypeCheck.cpp
  clang-tools-extra/clang-tidy/readability/ImplicitBoolConversionCheck.cpp
  clang-tools-extra/clang-tidy/readability/IsolateDeclarationCheck.cpp
  clang-tools-extra/clang-tidy/readability/MakeMemberFunctionConstCheck.cpp
  clang-tools-extra/clang-tidy/readability/NamespaceCommentCheck.cpp
  clang-tools-extra/clang-tidy/readability/UppercaseLiteralSuffixCheck.cpp
  clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.cpp
  clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.h
  clang-tools-extra/clangd/AST.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/Diagnostics.cpp
  clang-tools-extra/clangd/FindSymbols.h
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/FindTarget.h
  clang-tools-extra/clangd/FormattedString.cpp
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/Hover.h
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/PathMapping.cpp
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Quality.cpp
  clang-tools-extra/clangd/QueryDriverDatabase.cpp
  clang-tools-extra/clangd/index/Background.cpp
  clang-tools-extra/clangd/index/Serialization.cpp
  clang-tools-extra/clangd/index/SymbolOrigin.h
  clang-tools-extra/clangd/index/dex/Trigram.cpp
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
  clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/tool/ClangdMain.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
  clang-tools-extra/clangd/unittests/FindTargetTests.cpp
  clang-tools-extra/clangd/unittests/HeaderSourceSwitchTests.cpp
  clang-tools-extra/clangd/unittests/PathMappingTests.cpp
  clang-tools-extra/clangd/unittests/RenameTests.cpp
  clang-tools-extra/clangd/unittests/SymbolInfoTests.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp
  clang-tools-extra/docs/clang-tidy/checks/abseil-no-internal-dependencies.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-misplaced-pointer-arithmetic-in-alloc.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-virtual-near-miss.rst
  
clang-tools-extra/docs/clang-tidy/checks/performance-inefficient-vector-operation.rst
  

[PATCH] D77484: [Vector] Pass VectLib to LTO backend so TLI build correct vector function list

2020-04-05 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

Added usual lld and LTO side reviewers. I am just a bit worried that option 
name changes like this patch and D77231  could 
accidentally slip through if I did not react in time...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77484/new/

https://reviews.llvm.org/D77484



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