[PATCH] D88345: [CUDA] Allow local `static const {__constant__, __device__}` variables.

[Artem Belevich via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbe86b6773b6b: [CUDA] Allow local static variables with 
target attributes. (authored by tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88345

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaCUDA.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGenCUDA/static-device-var-no-rdc.cu
  clang/test/SemaCUDA/bad-attributes.cu
  clang/test/SemaCUDA/device-var-init.cu

Index: clang/test/SemaCUDA/device-var-init.cu
===
--- clang/test/SemaCUDA/device-var-init.cu
+++ clang/test/SemaCUDA/device-var-init.cu
@@ -24,6 +24,12 @@
 
 __shared__ T s_t_i = {2};
 // expected-error@-1 {{initialization is not supported for __shared__ variables.}}
+__device__ T d_t_i = {2};
+__constant__ T c_t_i = {2};
+
+__device__ ECD d_ecd_i{};
+__shared__ ECD s_ecd_i{};
+__constant__ ECD c_ecd_i{};
 
 __device__ EC d_ec_i(3);
 // expected-error@-1 {{dynamic initialization is not supported for __device__, __constant__, and __shared__ variables.}}
@@ -196,34 +202,218 @@
 __constant__ T_FA_NED c_t_fa_ned;
 // expected-error@-1 {{dynamic initialization is not supported for __device__, __constant__, and __shared__ variables.}}
 
-// Verify that only __shared__ local variables may be static on device
-// side and that they are not allowed to be initialized.
+// Verify that local variables may be static on device
+// side and that they conform to the initialization constraints.
+// __shared__ can't be initialized at all and others don't support dynamic initialization.
 __device__ void df_sema() {
-  static __shared__ NCFS s_ncfs;
-  // expected-error@-1 {{initialization is not supported for __shared__ variables.}}
-  static __shared__ UC s_uc;
-  // expected-error@-1 {{initialization is not supported for __shared__ variables.}}
-  static __shared__ NED s_ned;
-  // expected-error@-1 {{initialization is not supported for __shared__ variables.}}
-
   static __device__ int ds;
-  // expected-error@-1 {{within a __device__ function, only __shared__ variables or const variables without device memory qualifier may be marked 'static'}}
   static __constant__ int dc;
-  // expected-error@-1 {{within a __device__ function, only __shared__ variables or const variables without device memory qualifier may be marked 'static'}}
   static int v;
-  // expected-error@-1 {{within a __device__ function, only __shared__ variables or const variables without device memory qualifier may be marked 'static'}}
   static const int cv = 1;
   static const __device__ int cds = 1;
-  // expected-error@-1 {{within a __device__ function, only __shared__ variables or const variables without device memory qualifier may be marked 'static'}}
   static const __constant__ int cdc = 1;
-  // expected-error@-1 {{within a __device__ function, only __shared__ variables or const variables without device memory qualifier may be marked 'static'}}
+
+
+  // __shared__ does not need to be explicitly static.
+  __shared__ int lsi;
+  // __constant__ and __device__ can not be non-static local
+  __constant__ int lci;
+  // expected-error@-1 {{__constant__ and __device__ are not allowed on non-static local variables}}
+  __device__ int ldi;
+  // expected-error@-1 {{__constant__ and __device__ are not allowed on non-static local variables}}
+
+  // Same test cases as for the globals above.
+
+  static __device__ int d_v_f = f();
+  // expected-error@-1 {{dynamic initialization is not supported for __device__, __constant__, and __shared__ variables.}}
+  static __shared__ int s_v_f = f();
+  // expected-error@-1 {{initialization is not supported for __shared__ variables.}}
+  static __constant__ int c_v_f = f();
+  // expected-error@-1 {{dynamic initialization is not supported for __device__, __constant__, and __shared__ variables.}}
+
+  static __shared__ T s_t_i = {2};
+  // expected-error@-1 {{initialization is not supported for __shared__ variables.}}
+  static __device__ T d_t_i = {2};
+  static __constant__ T c_t_i = {2};
+
+  static __device__ ECD d_ecd_i;
+  static __shared__ ECD s_ecd_i;
+  static __constant__ ECD c_ecd_i;
+
+  static __device__ EC d_ec_i(3);
+  // expected-error@-1 {{dynamic initialization is not supported for __device__, __constant__, and __shared__ variables.}}
+  static __shared__ EC s_ec_i(3);
+  // expected-error@-1 {{initialization is not supported for __shared__ variables.}}
+  static __constant__ EC c_ec_i(3);
+  // expected-error@-1 {{dynamic initialization is not supported for __device__, __constant__, and __shared__ variables.}}
+
+  static __device__ EC d_ec_i2 = {3};
+  // expected-error@-1 {{dynamic initialization is not supported for __device__, __constant__, and __shared__ variables.}}
+  stati

[clang] cdbf6bf - [HIP] Use argv[0] as the default choice for the Executable name.

[Artem Belevich via cfe-commits]

Author: Artem Belevich
Date: 2020-11-03T10:31:39-08:00
New Revision: cdbf6bfdc7d15fc6a078c7773f142042a11d2c1b

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

LOG: [HIP] Use argv[0] as the default choice for the Executable name.

The path produced by getMainExecutable() may not be the right one when the 
files are installed in
a symlinked tree and when the real location of llvm-objdump is in a different 
directory.

Given that clang-offload-bundler is invoked by clang, the driver already does 
the job figuring out
the right path (e.g. it pays attention to -no-canonical-prefixes).
Offload bundler should use it, instead of trying to figure out the path on its
own.

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

Added: 


Modified: 
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Removed: 




diff  --git a/clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp 
b/clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
index e4a32d5e8744..44c46a89a859 100644
--- a/clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ b/clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -1025,7 +1025,9 @@ int main(int argc, const char **argv) {
 
   // Save the current executable directory as it will be useful to find other
   // tools.
-  BundlerExecutable = sys::fs::getMainExecutable(argv[0], &BundlerExecutable);
+  BundlerExecutable = argv[0];
+  if (!llvm::sys::fs::exists(BundlerExecutable))
+BundlerExecutable = sys::fs::getMainExecutable(argv[0], 
&BundlerExecutable);
 
   if (llvm::Error Err = Unbundle ? UnbundleFiles() : BundleFiles()) {
 reportError(std::move(Err));



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

[PATCH] D90436: [Bundler] Use argv[0] as the default choice for the Executable name.

[Artem Belevich via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcdbf6bfdc7d1: [HIP] Use argv[0] as the default choice for 
the Executable name. (authored by tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90436

Files:
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp


Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -1025,7 +1025,9 @@
 
   // Save the current executable directory as it will be useful to find other
   // tools.
-  BundlerExecutable = sys::fs::getMainExecutable(argv[0], &BundlerExecutable);
+  BundlerExecutable = argv[0];
+  if (!llvm::sys::fs::exists(BundlerExecutable))
+BundlerExecutable = sys::fs::getMainExecutable(argv[0], 
&BundlerExecutable);
 
   if (llvm::Error Err = Unbundle ? UnbundleFiles() : BundleFiles()) {
 reportError(std::move(Err));


Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -1025,7 +1025,9 @@
 
   // Save the current executable directory as it will be useful to find other
   // tools.
-  BundlerExecutable = sys::fs::getMainExecutable(argv[0], &BundlerExecutable);
+  BundlerExecutable = argv[0];
+  if (!llvm::sys::fs::exists(BundlerExecutable))
+BundlerExecutable = sys::fs::getMainExecutable(argv[0], &BundlerExecutable);
 
   if (llvm::Error Err = Unbundle ? UnbundleFiles() : BundleFiles()) {
 reportError(std::move(Err));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72184: [BPF] support atomic instructions

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song updated this revision to Diff 302617.
yonghong-song retitled this revision from "[WIP][BPF] support 
exchange/compare-and-exchange instruction" to "[BPF] support atomic 
instructions".
yonghong-song edited the summary of this revision.
yonghong-song added a comment.

- remove RFC tag.
- addressed comments for encoding, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72184

Files:
  clang/lib/Basic/Targets/BPF.cpp
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/lib/Target/BPF/BPF.td
  llvm/lib/Target/BPF/BPFInstrFormats.td
  llvm/lib/Target/BPF/BPFInstrInfo.td
  llvm/lib/Target/BPF/BPFSubtarget.cpp
  llvm/lib/Target/BPF/BPFSubtarget.h
  llvm/lib/Target/BPF/Disassembler/BPFDisassembler.cpp
  llvm/test/CodeGen/BPF/atomics.ll
  llvm/test/CodeGen/BPF/atomics_2.ll

Index: llvm/test/CodeGen/BPF/atomics_2.ll
===
--- /dev/null
+++ llvm/test/CodeGen/BPF/atomics_2.ll
@@ -0,0 +1,131 @@
+; RUN: llc < %s -march=bpfel -verify-machineinstrs -show-mc-encoding -mcpu=v4 | FileCheck %s
+;
+; Source:
+;   char test_load_sub_8(char *p, char v) {
+; return __sync_fetch_and_sub(p, v);
+;   }
+;   short test_load_sub_16(short *p, short v) {
+; return __sync_fetch_and_sub(p, v);
+;   }
+;   int test_load_sub_32(int *p, int v) {
+; return __sync_fetch_and_sub(p, v);
+;   }
+;   int test_load_sub_64(long *p, long v) {
+; return __sync_fetch_and_sub(p, v);
+;   }
+;   int test_xchg_8(char *p, char v) {
+; return __sync_lock_test_and_set(p, v);
+;   }
+;   int test_xchg_16(short *p, short v) {
+; return __sync_lock_test_and_set(p, v);
+;   }
+;   int test_xchg_32(int *p, int v) {
+; return __sync_lock_test_and_set(p, v);
+;   }
+;   int test_xchg_64(long *p, long v) {
+; return __sync_lock_test_and_set(p, v);
+;   }
+;   int test_cas_32(int *p, int old, int new) {
+; return __sync_val_compare_and_swap(p, old, new);
+;   }
+;   long test_cas_64(long *p, long old, long new) {
+; return __sync_val_compare_and_swap(p, old, new);
+;   }
+
+; CHECK-LABEL: test_load_sub_8
+; CHECK: w0 = atomic_fetch_sub((u8 *)(r1 + 0), w2)
+; CHECK: encoding: [0xd3,0x01,0x00,0x00,0x11,0x02,0x00,0x00]
+define dso_local signext i8 @test_load_sub_8(i8* nocapture %p, i8 signext %v) local_unnamed_addr #0 {
+entry:
+  %0 = atomicrmw sub i8* %p, i8 %v seq_cst
+  ret i8 %0
+}
+
+; CHECK-LABEL: test_load_sub_16
+; CHECK: w0 = atomic_fetch_sub((u16 *)(r1 + 0), w2)
+; CHECK: encoding: [0xcb,0x01,0x00,0x00,0x11,0x02,0x00,0x00]
+define dso_local signext i16 @test_load_sub_16(i16* nocapture %p, i16 signext %v) local_unnamed_addr #0 {
+entry:
+  %0 = atomicrmw sub i16* %p, i16 %v seq_cst
+  ret i16 %0
+}
+
+; CHECK-LABEL: test_load_sub_32
+; CHECK: w0 = atomic_fetch_sub((u32 *)(r1 + 0), w2)
+; CHECK: encoding: [0xc3,0x01,0x00,0x00,0x11,0x02,0x00,0x00]
+define dso_local i32 @test_load_sub_32(i32* nocapture %p, i32 %v) local_unnamed_addr {
+entry:
+  %0 = atomicrmw sub i32* %p, i32 %v seq_cst
+  ret i32 %0
+}
+
+; CHECK-LABEL: test_load_sub_64
+; CHECK: r0 = atomic_fetch_sub((u64 *)(r1 + 0), r2)
+; CHECK: encoding: [0xdb,0x01,0x00,0x00,0x11,0x02,0x00,0x00]
+define dso_local i32 @test_load_sub_64(i64* nocapture %p, i64 %v) local_unnamed_addr {
+entry:
+  %0 = atomicrmw sub i64* %p, i64 %v seq_cst
+  %conv = trunc i64 %0 to i32
+  ret i32 %conv
+}
+
+; CHECK-LABEL: test_xchg_8
+; CHECK: w0 = xchg32_8(r1 + 0, w2)
+; CHECK: encoding: [0xd3,0x01,0x00,0x00,0xe1,0x02,0x00,0x00]
+define dso_local i32 @test_xchg_8(i8* nocapture %p, i8 signext %v) local_unnamed_addr {
+entry:
+  %0 = atomicrmw xchg i8* %p, i8 %v seq_cst
+  %conv = sext i8 %0 to i32
+  ret i32 %conv
+}
+
+; CHECK-LABEL: test_xchg_16
+; CHECK: w0 = xchg32_16(r1 + 0, w2)
+; CHECK: encoding: [0xcb,0x01,0x00,0x00,0xe1,0x02,0x00,0x00]
+define dso_local i32 @test_xchg_16(i16* nocapture %p, i16 signext %v) local_unnamed_addr {
+entry:
+  %0 = atomicrmw xchg i16* %p, i16 %v seq_cst
+  %conv = sext i16 %0 to i32
+  ret i32 %conv
+}
+
+; CHECK-LABEL: test_xchg_32
+; CHECK: w0 = xchg32_32(r1 + 0, w2)
+; CHECK: encoding: [0xc3,0x01,0x00,0x00,0xe1,0x02,0x00,0x00]
+define dso_local i32 @test_xchg_32(i32* nocapture %p, i32 %v) local_unnamed_addr {
+entry:
+  %0 = atomicrmw xchg i32* %p, i32 %v seq_cst
+  ret i32 %0
+}
+
+; CHECK-LABEL: test_xchg_64
+; CHECK: xchg_64(r1 + 0, r2)
+; CHECK: encoding: [0xdb,0x01,0x00,0x00,0xe1,0x02,0x00,0x00]
+define dso_local i32 @test_xchg_64(i64* nocapture %p, i64 %v) local_unnamed_addr {
+entry:
+  %0 = atomicrmw xchg i64* %p, i64 %v seq_cst
+  %conv = trunc i64 %0 to i32
+  ret i32 %conv
+}
+
+; CHECK-LABEL: test_cas_32
+; CHECK: w0 = w2
+; CHECK: w0 = cmpxchg32_32(r1 + 0, w0, w3)
+; CHECK: encoding: [0xc3,0x01,0x00,0x00,0xf1,0x03,0x00,0x00]
+define dso_local i32 @test_cas_32(i32* nocapture %p, i32 %old, i32 %new) local_unnamed_addr {
+entry:
+  %0 = cmpxchg i32* %p, i32 %old, i32 %new seq_cst

[PATCH] D90409: [HIP] Math Headers to use type promotion

[Aaron Enye Shi via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGca5b31502c82: [HIP] Math Headers to use type promotion 
(authored by ashi1).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90409

Files:
  clang/lib/Headers/__clang_hip_cmath.h

Index: clang/lib/Headers/__clang_hip_cmath.h
===
--- clang/lib/Headers/__clang_hip_cmath.h
+++ clang/lib/Headers/__clang_hip_cmath.h
@@ -16,6 +16,8 @@
 
 #if defined(__cplusplus)
 #include 
+#include 
+#include 
 #endif
 #include 
 #include 
@@ -205,6 +207,72 @@
 
 template  struct __hip_enable_if { typedef __T type; };
 
+// decltype is only available in C++11 and above.
+#if __cplusplus >= 201103L
+// __hip_promote
+namespace __hip {
+
+template  struct __numeric_type {
+  static void __test(...);
+  static _Float16 __test(_Float16);
+  static float __test(float);
+  static double __test(char);
+  static double __test(int);
+  static double __test(unsigned);
+  static double __test(long);
+  static double __test(unsigned long);
+  static double __test(long long);
+  static double __test(unsigned long long);
+  static double __test(double);
+
+  typedef decltype(__test(std::declval<_Tp>())) type;
+  static const bool value = !std::is_same::value;
+};
+
+template <> struct __numeric_type { static const bool value = true; };
+
+template ::value &&__numeric_type<_A2>::value
+  &&__numeric_type<_A3>::value>
+class __promote_imp {
+public:
+  static const bool value = false;
+};
+
+template 
+class __promote_imp<_A1, _A2, _A3, true> {
+private:
+  typedef typename __promote_imp<_A1>::type __type1;
+  typedef typename __promote_imp<_A2>::type __type2;
+  typedef typename __promote_imp<_A3>::type __type3;
+
+public:
+  typedef decltype(__type1() + __type2() + __type3()) type;
+  static const bool value = true;
+};
+
+template  class __promote_imp<_A1, _A2, void, true> {
+private:
+  typedef typename __promote_imp<_A1>::type __type1;
+  typedef typename __promote_imp<_A2>::type __type2;
+
+public:
+  typedef decltype(__type1() + __type2()) type;
+  static const bool value = true;
+};
+
+template  class __promote_imp<_A1, void, void, true> {
+public:
+  typedef typename __numeric_type<_A1>::type type;
+  static const bool value = true;
+};
+
+template 
+class __promote : public __promote_imp<_A1, _A2, _A3> {};
+
+} // namespace __hip
+#endif //__cplusplus >= 201103L
+
 // __HIP_OVERLOAD1 is used to resolve function calls with integer argument to
 // avoid compilation error due to ambibuity. e.g. floor(5) is resolved with
 // floor(double).
@@ -219,6 +287,18 @@
 // __HIP_OVERLOAD2 is used to resolve function calls with mixed float/double
 // or integer argument to avoid compilation error due to ambibuity. e.g.
 // max(5.0f, 6.0) is resolved with max(double, double).
+#if __cplusplus >= 201103L
+#define __HIP_OVERLOAD2(__retty, __fn) \
+  template   \
+  __DEVICE__ typename __hip_enable_if< \
+  std::numeric_limits<__T1>::is_specialized && \
+  std::numeric_limits<__T2>::is_specialized,   \
+  typename __hip::__promote<__T1, __T2>::type>::type   \
+  __fn(__T1 __x, __T2 __y) {   \
+typedef typename __hip::__promote<__T1, __T2>::type __result_type; \
+return __fn((__result_type)__x, (__result_type)__y);   \
+  }
+#else
 #define __HIP_OVERLOAD2(__retty, __fn) \
   template   \
   __DEVICE__   \
@@ -228,6 +308,7 @@
   __fn(__T1 __x, __T2 __y) {   \
 return __fn((double)__x, (double)__y); \
   }
+#endif
 
 __HIP_OVERLOAD1(double, abs)
 __HIP_OVERLOAD1(double, acos)
@@ -296,6 +377,18 @@
 __HIP_OVERLOAD2(double, min)
 
 // Additional Overloads that don't quite match HIP_OVERLOAD.
+#if __cplusplus >= 201103L
+template 
+__DEVICE__ typename __hip_enable_if<
+std::numeric_limits<__T1>::is_specialized &&
+std::numeric_limits<__T2>::is_specialized &&
+std::numeric_limits<__T3>::is_specialized,
+typename __hip::__promote<__T1, __T2, __T3>::type>::type
+fma(__T1 __x, __T2 __y, __T3 __z) {
+  typedef typename __hip::__promote<__T1, __T2, __T3>::type __result_type;
+  return ::fma((__result_type)__x, (__result_type)__y, (__result_type)__z);
+}
+#else
 template 
 __DEVICE__
 typename __hip_enable_if::is_specialized &&
@@ -305,6 +398,7 @@
 fma(__T1 __x, __T2 __y, __T3 __z) {
   return ::fma((double)__

[clang] ca5b315 - [HIP] Math Headers to use type promotion

[Aaron En Ye Shi via cfe-commits]

Author: Aaron En Ye Shi
Date: 2020-11-03T18:40:26Z
New Revision: ca5b31502c828f8e7160a77f54a5a131dc298005

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

LOG: [HIP] Math Headers to use type promotion

Similar to libcxx implementation of cmath function
overloads, use type promotion templates to determine
return types of multi-argument math functions.

Fixes: SWDEV-256825

Reviewed By: tra, yaxunl

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

Added: 


Modified: 
clang/lib/Headers/__clang_hip_cmath.h

Removed: 




diff  --git a/clang/lib/Headers/__clang_hip_cmath.h 
b/clang/lib/Headers/__clang_hip_cmath.h
index fea799ead32f..00519a9795bc 100644
--- a/clang/lib/Headers/__clang_hip_cmath.h
+++ b/clang/lib/Headers/__clang_hip_cmath.h
@@ -16,6 +16,8 @@
 
 #if defined(__cplusplus)
 #include 
+#include 
+#include 
 #endif
 #include 
 #include 
@@ -205,6 +207,72 @@ template  struct 
__hip_enable_if {};
 
 template  struct __hip_enable_if { typedef __T type; };
 
+// decltype is only available in C++11 and above.
+#if __cplusplus >= 201103L
+// __hip_promote
+namespace __hip {
+
+template  struct __numeric_type {
+  static void __test(...);
+  static _Float16 __test(_Float16);
+  static float __test(float);
+  static double __test(char);
+  static double __test(int);
+  static double __test(unsigned);
+  static double __test(long);
+  static double __test(unsigned long);
+  static double __test(long long);
+  static double __test(unsigned long long);
+  static double __test(double);
+
+  typedef decltype(__test(std::declval<_Tp>())) type;
+  static const bool value = !std::is_same::value;
+};
+
+template <> struct __numeric_type { static const bool value = true; };
+
+template ::value &&__numeric_type<_A2>::value
+  &&__numeric_type<_A3>::value>
+class __promote_imp {
+public:
+  static const bool value = false;
+};
+
+template 
+class __promote_imp<_A1, _A2, _A3, true> {
+private:
+  typedef typename __promote_imp<_A1>::type __type1;
+  typedef typename __promote_imp<_A2>::type __type2;
+  typedef typename __promote_imp<_A3>::type __type3;
+
+public:
+  typedef decltype(__type1() + __type2() + __type3()) type;
+  static const bool value = true;
+};
+
+template  class __promote_imp<_A1, _A2, void, true> {
+private:
+  typedef typename __promote_imp<_A1>::type __type1;
+  typedef typename __promote_imp<_A2>::type __type2;
+
+public:
+  typedef decltype(__type1() + __type2()) type;
+  static const bool value = true;
+};
+
+template  class __promote_imp<_A1, void, void, true> {
+public:
+  typedef typename __numeric_type<_A1>::type type;
+  static const bool value = true;
+};
+
+template 
+class __promote : public __promote_imp<_A1, _A2, _A3> {};
+
+} // namespace __hip
+#endif //__cplusplus >= 201103L
+
 // __HIP_OVERLOAD1 is used to resolve function calls with integer argument to
 // avoid compilation error due to ambibuity. e.g. floor(5) is resolved with
 // floor(double).
@@ -219,6 +287,18 @@ template  struct __hip_enable_if { 
typedef __T type; };
 // __HIP_OVERLOAD2 is used to resolve function calls with mixed float/double
 // or integer argument to avoid compilation error due to ambibuity. e.g.
 // max(5.0f, 6.0) is resolved with max(double, double).
+#if __cplusplus >= 201103L
+#define __HIP_OVERLOAD2(__retty, __fn) 
\
+  template   
\
+  __DEVICE__ typename __hip_enable_if< 
\
+  std::numeric_limits<__T1>::is_specialized && 
\
+  std::numeric_limits<__T2>::is_specialized,   
\
+  typename __hip::__promote<__T1, __T2>::type>::type   
\
+  __fn(__T1 __x, __T2 __y) {   
\
+typedef typename __hip::__promote<__T1, __T2>::type __result_type; 
\
+return __fn((__result_type)__x, (__result_type)__y);   
\
+  }
+#else
 #define __HIP_OVERLOAD2(__retty, __fn) 
\
   template   
\
   __DEVICE__   
\
@@ -228,6 +308,7 @@ template  struct __hip_enable_if { 
typedef __T type; };
   __fn(__T1 __x, __T2 __y) {   
\
 return __fn((double)__x, (double)__y); 
\
   }
+#endif
 
 __HIP_OVERLOAD1(double, abs)
 __HIP_OVERLOAD1(double, acos)
@@ -296,6 +377,18 @@ __HIP_OVERLOAD2(double, max)
 __HIP_OVERLOAD2(double, min)
 
 // Additional Overloads that don't quite match HIP_OVERLOAD.
+#if __cplusplus >= 201103L
+template 
+__DEVICE__ typename __hip_enable_if<
+std::numeric_lim

[PATCH] D72184: [BPF] support atomic instructions

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song marked an inline comment as done.
yonghong-song added inline comments.



Comment at: llvm/lib/Target/BPF/BPFInstrInfo.td:830
+
+let Predicates = [BPFHasAtomicExt] in {
+  def CMPXCHGD : CMPXCHG;

ast wrote:
> let Defs = [R0], Uses = [R0]
> and BPFISelLowering would need to do getCopyToReg+cmpxchg+getCopyFromReg 
> similar to X86ISelLowering ?
Yes, Just with Uses = [R0] or Uses = [W0] and change patterns can make it work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72184

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

[PATCH] D90409: [HIP] Math Headers to use type promotion

[Justin Lebar via Phabricator via cfe-commits]

jlebar added a comment.

> LGTM. I think the change would make sense for CUDA, too. @jlebar - WDYT?

I agree that the C and C++ standard libraries should behave the same in CUDA 
mode and host mode!

But if doing so would make our behavior different than nvcc's, maybe we could 
emit a warning or something?  Like, "this code you wrote maybe for nvcc is 
going to do something different with clang."


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90409

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

[PATCH] D90570: [mips] Add a -mmips3d command line option to clang

[Michael Roe via Phabricator via cfe-commits]

michael-roe added a comment.

The goal of this patch is that if you have some C code with inline MIPS 
assembly language that uses MIPS3D instructions, you can get it to compile by 
passing -mmips3d on the command line. (Without this command line option, 
there's an awkward workaround that involves putting .set mips3d in your inline 
assembly language).

I will admit that not many MIPS cores support MIPS3D. The CHERI MIPS FPGA soft 
core, which may be one of the few remaining MIPS cores that anyone still cares 
about, currently supports the MIPS V paired single instructions but not (at 
present) MIPS3D.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90570

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

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

[Aaron Ballman via Phabricator via cfe-commits]

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

I think this LGTM aside from a few minor nits. Thank you for working on this!




Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-sig30-c.rst:12-14
+This check corresponds to the CERT C Coding Standard rule
+`SIG30-C. Call only asynchronous-safe functions within signal handlers
+`_.

I think this bit about the CERT link should move into the main checker 
documentation (if only because the alias documentation will redirect to the 
main documentation after five seconds).



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-sig30-c.rst:15
+`_.
+The check handles only C code.

Same for the C-only nature of the check.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/signal.h:20
+typedef void (*sighandler_t)(int);
+sighandler_t signal(int signum, sighandler_t handler);
+

Might as well drop the parameter names here as well.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/stdlib.h:13-14
+void abort(void);
+void _Exit(int __status);
+void quick_exit(int __status);
+

Might as well drop the parameter names here too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87449

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

[PATCH] D90275: [clang][IR] Add support for leaf attribute

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Hi,

Naming is a hard thing... I have no special preference. :/

However, I'd like to understand the details of this attribute.

Would LTO be affected because `leaf` is guaranteed to untouch the current 
translation unit only?

  // a.c
  int x;
  void f1() {
f2();
  }
  void g() { x = 3; }
  
  // b.c
  void f2() {
leaf();
  }
  
  // leaf.c
  attribute((leaf)) void leaf() {
g();
  }

IIUC this program is okay because the caller of leaf() is at a.c, not b.c.
But, let's assume that a.c and b.c are LTO-ed, and leaf.c is separately 
compiled.
If LTO merges a.c and b.c into the same module, the two TUs cannot be 
distinguished anymore; either `leaf` should be dropped, or LTO should somehow 
conceptually keep two TUs.
Would it be a valid concern? Then I think it should be mentioned.

Another question is more about the motivation of this attribute (well, I know 
it is introduced by gcc first; just throwing a question :) )
If the motivation is to support better data flow analysis, is there something 
special in callback itself?
The gcc document states that `sin()` is a leaf function, and IIUC this is 
because `sin()` never touches the memory allocated at caller's TU (because 
`errno` isn't at the caller's TU).
I think things are easier if we simply say that `leaf` cannot touch the memory 
of current TU, regardless of the existence of callbacks.
Is there something important in the callback itself?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

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

[clang] 7ad6010 - Fix - [Clang] Add the ability to map DLL storage class to visibility

[Ben Dunbobbin via cfe-commits]

Author: Ben Dunbobbin
Date: 2020-11-03T19:13:54Z
New Revision: 7ad6010f58eac498896e601857ff7eda84466064

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

LOG: Fix - [Clang] Add the ability to map DLL storage class to visibility

415f7ee883 had a silly typo introduced when I inlined some
code into a loop from its own function.

Original commit message:

For PlayStation we offer source code compatibility with
Microsoft's dllimport/export annotations; however, our file
format is based on ELF.

To support this we translate from DLL storage class to ELF
visibility at the end of codegen in Clang.

Other toolchains have used similar strategies (e.g. see the
documentation for this ARM toolchain:

https://developer.arm.com/documentation/dui0530/i/migrating-from-rvct-v3-1-to-rvct-v4-0/changes-to-symbol-visibility-between-rvct-v3-1-and-rvct-v4-0)

This patch adds the ability to perform this translation. Options
are provided to support customizing the mapping behaviour.

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

Added: 


Modified: 
clang/lib/CodeGen/CodeGenModule.cpp
clang/test/CodeGenCXX/visibility-dllstorageclass.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 1efc39bc8fb1..24c067539f83 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -418,7 +418,7 @@ static void setVisibilityFromDLLStorageClass(const 
clang::LangOptions &LO,
 
   for (llvm::GlobalValue &GV : M.global_values()) {
 if (GV.hasAppendingLinkage() || GV.hasLocalLinkage())
-  return;
+  continue;
 
 if (GV.isDeclarationForLinker()) {
   GV.setVisibility(GV.getDLLStorageClass() ==
@@ -724,7 +724,7 @@ void CodeGenModule::Release() {
 
   EmitBackendOptionsMetadata(getCodeGenOpts());
 
-  // Set visibility from DLL export class
+  // Set visibility from DLL storage class
   // We do this at the end of LLVM IR generation; after any operation
   // that might affect the DLL storage class or the visibility, and
   // before anything that might act on these.

diff  --git a/clang/test/CodeGenCXX/visibility-dllstorageclass.cpp 
b/clang/test/CodeGenCXX/visibility-dllstorageclass.cpp
index f090ccb3b099..9003909f3ee0 100644
--- a/clang/test/CodeGenCXX/visibility-dllstorageclass.cpp
+++ b/clang/test/CodeGenCXX/visibility-dllstorageclass.cpp
@@ -19,11 +19,17 @@
 // RUN: -x c++  %s -S -emit-llvm -o - | \
 // RUN:   FileCheck %s --check-prefixes=EXPLICIT
 
+// Local
+static void l() {}
+void use_locals(){l();}
+// DEFAULT-DAG: define internal void @_ZL1lv()
+// EXPLICIT-DAG: define internal void @_ZL1lv()
+
 // Function
 void f() {}
 void __declspec(dllexport) exported_f() {}
 // DEFAULT-DAG: define hidden void @_Z1fv()
-// DEFAULT-DAG: define dso_local  void @_Z10exported_fv()
+// DEFAULT-DAG: define dso_local void @_Z10exported_fv()
 // EXPLICIT-DAG: define protected void @_Z1fv()
 // EXPLICIT-DAG: define hidden void @_Z10exported_fv()
 



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

[PATCH] D90275: [clang][IR] Add support for leaf attribute

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D90275#2371764 , @aqjune wrote:

> Hi,
>
> Naming is a hard thing... I have no special preference. :/
>
> However, I'd like to understand the details of this attribute.
>
> Would LTO be affected because `leaf` is guaranteed to untouch the current 
> translation unit only?
>
>   // a.c
>   int x;
>   void f1() {
> f2();
>   }
>   void g() { x = 3; }
>   
>   // b.c
>   void f2() {
> leaf();
>   }
>   
>   // leaf.c
>   attribute((leaf)) void leaf() {
> g();
>   }
>
> IIUC this program is okay because g() and the caller of leaf() are in 
> different TUs.
> But, let's assume that a.c and b.c are LTO-ed, and leaf.c is separately 
> compiled.
> If LTO merges a.c and b.c into the same module, the two TUs cannot be 
> distinguished anymore; either `leaf` should be dropped, or LTO should somehow 
> conceptually keep two TUs.
> Would it be a valid concern? Then I think it should be mentioned.

As noted by the GCC docs, it doesn't mean anything on a definition so that you 
can safely merge TUs. I want us to forbid `leaf` on IR function definitions for 
that reason, it would not mean anything and be only confusing.

> Another question is more about the motivation of this attribute (well, I know 
> it is introduced by gcc first; just throwing a question :) )
> If the motivation is to support better data flow analysis, is there something 
> special in callback itself?
> The gcc document states that `sin()` is a leaf function, and IIUC this is 
> because `sin()` never touches the memory allocated at caller's TU (because 
> `errno` isn't at the caller's TU).

No, that is not it. It is `leaf` because it will not transfer control to the 
callers TU.

> I think things are easier if we simply say that `leaf` cannot touch the 
> memory of current TU, regardless of the existence of callbacks.
> Is there something important in the callback itself?

Not really, IMHO, `leaf` means you cannot transfer control to the callers TU 
without going threw the original call site (via return or throw).
It is not a memory thing. However, the "almost" matching memory property is 
called `inaccesiblememonly` so that is why I wanted to call this 
`inaccessiblecodeonly`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

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

[PATCH] D89980: [hip] Remove kernel argument coercion.

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

This should use byref, but I don't think this should come at the cost of the 
promotion. I would still like to see this promotion occur for the in-memory 
byref type


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

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

[PATCH] D90392: [clang-tidy] Omit std::make_unique/make_shared for default initialization.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

I think for starters this patch needs a better description, explaining not 
*what* it does, but *why* it does what it does.
Also, it is probably not good to change (break) existing test coverage.
Instead, it is best to add new tests, and adjust existing check lines.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90392

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

[PATCH] D90704: [OpenMP] target nested `use_device_ptr() if()` and is_device_ptr trigger asserts

[Chi Chun Chen via Phabricator via cfe-commits]

cchen created this revision.
cchen added a reviewer: ABataev.
Herald added subscribers: cfe-commits, guansong, yaxunl.
Herald added a project: clang.
cchen requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added a subscriber: sstefan1.

Clang now asserts for the below case for "All ordered entries must
exist!" message.

  void
  add_one(float *b, int dm)
  {
{
{
  b[0] += 1;
}
}
  }

Clang now register for same device region for both `if_then` codegen and
`else_then` codegen so this patch just add a check to avoid register
twice for same device region.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90704

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp


Index: clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp
===
--- clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp
+++ clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp
@@ -471,5 +471,49 @@
   A.foo(arg);
   ++arg;
 }
+#endif
+///==///
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 
powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix 
CK3 --check-prefix CK3-64
+// RUN: %clang_cc1 -DCK3 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu 
-x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ 
-triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s 
-emit-llvm -o - | FileCheck %s  --check-prefix CK3 --check-prefix CK3-64
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu 
-x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck %s  
--check-prefix CK3 --check-prefix CK3-32
+// RUN: %clang_cc1 -DCK3 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ 
-std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple 
i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | 
FileCheck %s  --check-prefix CK3 --check-prefix CK3-32
+
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp-simd 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 
powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix 
SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK3 -fopenmp-simd 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple 
powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x 
c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s 
-emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp-simd 
-fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown 
-emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK3 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x 
c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ 
-triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm 
-o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// SIMD-ONLY1-NOT: {{__kmpc|__tgt}}
+#ifdef CK3
+
+// CK3: [[MTYPE00:@.+]] = {{.*}}constant [1 x i64] [i64 99]
+// CK3: [[MTYPE01:@.+]] = {{.*}}constant [1 x i64] [i64 288]
+// CK3: [[MTYPE02:@.+]] = {{.*}}constant [1 x i64] [i64 288]
+
+void add_one(float *b, int dm)
+{
+  // CK3: [[BP:%.+]] = getelementptr inbounds [1 x i8*], [1 x i8*]* 
%{{.+}}, i32 0, i32 0
+  // CK3: [[CBP:%.+]] = bitcast i8** [[BP]] to float**
+  // CK3: store float* [[B_ADDR:%.+]], float** [[CBP]]
+  // CK3: call void @__tgt_target_data_begin{{.+}}[[MTYPE00]]
+  // CK3: [[VAL:%.+]] = load float*, float** [[CBP]],
+  // CK3-NOT: store float* [[VAL]], float** [[DECL]],
+  // CK3: store float* [[VAL]], float** [[PVT:%.+]],
+  // CK3: [[TT:%.+]] = load float*, float** [[PVT]],
+  // CK3: call i32 @__tgt_target{{.+}}[[MTYPE01]]
+  // CK3: call i32 @__tgt_target{{.+}}[[MTYPE02]]
+  // CK3: call void @__tgt_target_data_end{{.+}}[[MTYPE00]]
+#pragma omp target data map(tofrom:b[:1]) use_device_ptr(b) if(dm == 0)
+  {
+#pragma omp target is_device_ptr(b)
+  {
+b[0] += 1;
+  }
+  }
+}
+
 #endif
 #endif
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -2955,6 +2955,19 @@
 Entry.setID(ID);
 Entry.setFlags(Flags);
   } else {
+auto PerDevice = OffloadEntriesTargetRegion.find(DeviceID);
+if (PerDevice != OffloadEntriesTargetRegion.end()) {
+  auto PerFile = PerDevice->second.find(FileID);
+ 

[PATCH] D90704: [OpenMP] target nested `use_device_ptr() if()` and is_device_ptr trigger asserts

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

I do not understand the commit message. Can you try to make it clearer?




Comment at: clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp:518
+
 #endif
 #endif

Create a new file please.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90704

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

[PATCH] D89980: [hip] Remove kernel argument coercion.

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

In D89980#2371850 , @arsenm wrote:

> This should use byref, but I don't think this should come at the cost of the 
> promotion. I would still like to see this promotion occur for the in-memory 
> byref type

Once we use `byref`, that in-memory byref type has no way to be preserved based 
on C model as it will be treated as a local variable. The initial value with 
the coerced type won't be preserved after that. That happens to the case with 
static index as well, but the promotion helps to build the chain from the 
initial value to the final use. But, if we cannot promote `alloca` finally, we 
lost that information or cannot assume that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

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

[PATCH] D89670: [clangd] Store the containing symbol for refs

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet accepted this revision.
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp:770
+EXPECT_TRUE(bool(Ref));
+if (!AllowNull)
+  EXPECT_FALSE(Ref->Container.isNull());

nit: instead of making this part of the lambda and complicating the signature I 
would just check this holds for classscope1 and namespacescope1 explicitly. it 
should be true for other cases anyways, as we are checking equality with 
non-null smybolids.



Comment at: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp:782
+
+EXPECT_EQ(Ref1->Container, Ref2->Container);
+  };

nridge wrote:
> kadircet wrote:
> > can you also assert containers here are non-null (and below)
> It looks like the container is null for toplevel decls. Is that a problem?
I think that's OK for now, might be worth leaving a comment tho. (at 
`Ref::Container`)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89670

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

[PATCH] D89980: [hip] Remove kernel argument coercion.

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D89980#2371952 , @hliao wrote:

> In D89980#2371850 , @arsenm wrote:
>
>> This should use byref, but I don't think this should come at the cost of the 
>> promotion. I would still like to see this promotion occur for the in-memory 
>> byref type
>
> Once we use `byref`, that in-memory byref type has no way to be preserved 
> based on C model as it will be treated as a local variable. The initial value 
> with the coerced type won't be preserved after that. That happens to the case 
> with static index as well, but the promotion helps to build the chain from 
> the initial value to the final use. But, if we cannot promote `alloca` 
> finally, we lost that information or cannot assume that.

Then the promotion can also be applied to the temporary argument slot


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

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

[PATCH] D90409: [HIP] Math Headers to use type promotion

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

nvcc does not support fma(float,float,char)

https://godbolt.org/z/zxbMhP

clang's behavior was different from nvcc already.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90409

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

[PATCH] D90409: [HIP] Math Headers to use type promotion

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D90409#2371679 , @jlebar wrote:

>> LGTM. I think the change would make sense for CUDA, too. @jlebar - WDYT?
>
> I agree that the C and C++ standard libraries should behave the same in CUDA 
> mode and host mode!
>
> But if doing so would make our behavior different than nvcc's, maybe we could 
> emit a warning or something?  Like, "this code you wrote maybe for nvcc is 
> going to do something different with clang."

Interestingly enough CUDA 10.1+ already promotes integer `fma()` arguments to 
double:
https://godbolt.org/z/crbqTe

I wonder what makes HIP different to require this change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90409

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

[PATCH] D90275: [clang][IR] Add support for leaf attribute

[Gulfem Savrun Yeniceri via Phabricator via cfe-commits]

gulfem marked an inline comment as done.
gulfem added a comment.

In D90275#2371343 , @jdoerfert wrote:

> The more I think about it, the more I think we should never create a 
> `leaf`/`nocallback` definition. Only declarations should carry that attribute.
>
> I'm also still not convinced `nocallback` is a good name. @efriedma @aqjune 
> @fhahn @reames What are your thoughts on the name. My earlier idea was 
> `inaccesiblecodeonly`, as it matches the `inaccisblememonly` idea. I'm not 
> married to it, `nocallback` is just not great IMHO as direct calls back into 
> the caller TU are also forbidden and there is already `!callback`.

We are totally fine to rename it to something else, and we do see the potential 
confusion with the existing callback attribute that we have.
If I understand correctly, `inaccessiblememonly` functions may only access 
memory that is not accessible by the **current** compilation unit (current 
compilation unit means the compilation unit that inaccessiblememonly function 
is defined).
If we use `inaccesiblecodeonly`, it implies that leaf functions may only access 
code that is not accessible by the compilation unit that they are defined.
But, leaf attribute does not enforce any rule for accessing code in the leaf 
attribute function's compilation. 
It only enforces that leaf function does not access any code in its `caller's 
translation unit`.
That's is why I'm not sure whether `inaccesiblecodeonly` is a good name for 
that.
Please let me know if I'm missing anything about inaccessiblememonly attribute.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

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

[PATCH] D90409: [HIP] Math Headers to use type promotion

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D90409#2371969 , @yaxunl wrote:

> nvcc does not support fma(float,float,char)

It does, it just needs an explicit flag to match clang's treatment of 
`constexpr` functions as HD.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90409

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

[PATCH] D90174: [HIP] Fix regressions due to fp contract change

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 302662.
yaxunl marked 7 inline comments as done.
yaxunl added a comment.

revised manual by John's comments


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

https://reviews.llvm.org/D90174

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/test/CodeGenCUDA/fp-contract.cu
  clang/test/Driver/autocomplete.c

Index: clang/test/Driver/autocomplete.c
===
--- clang/test/Driver/autocomplete.c
+++ clang/test/Driver/autocomplete.c
@@ -66,6 +66,7 @@
 // FNOSANICOVERALL-NEXT: trace-pc-guard
 // RUN: %clang --autocomplete=-ffp-contract= | FileCheck %s -check-prefix=FFPALL
 // FFPALL: fast
+// FFPALL-NEXT: faststd 
 // FFPALL-NEXT: off
 // FFPALL-NEXT: on
 // RUN: %clang --autocomplete=-flto= | FileCheck %s -check-prefix=FLTOALL
Index: clang/test/CodeGenCUDA/fp-contract.cu
===
--- clang/test/CodeGenCUDA/fp-contract.cu
+++ clang/test/CodeGenCUDA/fp-contract.cu
@@ -1,32 +1,298 @@
-// REQUIRES: x86-registered-target
-// REQUIRES: nvptx-registered-target
+// REQUIRES: x86-registered-target, nvptx-registered-target, amdgpu-registered-target
 
-// By default we should fuse multiply/add into fma instruction.
+// By default CUDA uses -ffp-contract=fast, HIP uses -ffp-contract=faststd.
+// we should fuse multiply/add into fma instruction.
+// In IR, fmul/fadd instructions with contract flag are emitted.
+// In backend
+//nvptx -  assumes fast fp fuse option, which fuses
+// mult/add insts disregarding contract flag and
+// llvm.fmuladd intrinsics.
+//amdgcn - assumes standard fp fuse option, which only
+// fuses mult/add insts with contract flag and
+// llvm.fmuladd intrinsics.
+
+// RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
+// RUN:   -disable-llvm-passes -o - %s \
+// RUN:   | FileCheck -check-prefixes=COMMON,NV-ON %s
+// RUN: %clang_cc1 -fcuda-is-device -triple amdgcn-amd-amdhsa -S \
+// RUN:   -target-cpu gfx906 -disable-llvm-passes -o - -x hip %s \
+// RUN:   | FileCheck -check-prefixes=COMMON,AMD-ON %s
 // RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
-// RUN:   -disable-llvm-passes -o - %s | FileCheck -check-prefix ENABLED %s
+// RUN:   -O3 -o - %s \
+// RUN:   | FileCheck -check-prefixes=COMMON,NV-OPT-FAST %s
+// RUN: %clang_cc1 -fcuda-is-device -triple amdgcn-amd-amdhsa -S \
+// RUN:   -O3 -target-cpu gfx906 -o - -x hip %s \
+// RUN:   | FileCheck -check-prefixes=COMMON,AMD-OPT-FASTSTD %s
+
+// Check separate compile/backend steps corresponding to -save-temps.
+
+// RUN: %clang_cc1 -fcuda-is-device -triple amdgcn-amd-amdhsa -emit-llvm \
+// RUN:   -O3 -disable-llvm-passes -target-cpu gfx906 -o %t.ll -x hip %s
+// RUN: cat %t.ll  | FileCheck -check-prefixes=COMMON,AMD-OPT-FAST-IR %s
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -S \
+// RUN:   -O3 -target-cpu gfx906 -o - -x ir %t.ll \
+// RUN:   | FileCheck -check-prefixes=COMMON,AMD-OPT-FASTSTD %s
 
 // Explicit -ffp-contract=fast
+// In IR, fmul/fadd instructions with contract flag are emitted.
+// In backend
+//nvptx/amdgcn - assumes fast fp fuse option, which fuses
+//   mult/add insts disregarding contract flag and
+//   llvm.fmuladd intrinsics.
+
 // RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
 // RUN:   -ffp-contract=fast -disable-llvm-passes -o - %s \
-// RUN:   | FileCheck -check-prefix ENABLED %s
+// RUN:   | FileCheck -check-prefixes=COMMON,NV-ON %s
+// RUN: %clang_cc1 -fcuda-is-device -triple amdgcn-amd-amdhsa -S \
+// RUN:   -target-cpu gfx906 -disable-llvm-passes -o - -x hip %s \
+// RUN:   -ffp-contract=fast \
+// RUN:   | FileCheck -check-prefixes=COMMON,AMD-ON %s
+// RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
+// RUN:   -O3 -o - %s \
+// RUN:   -ffp-contract=fast \
+// RUN:   | FileCheck -check-prefixes=COMMON,NV-OPT-FAST %s
+// RUN: %clang_cc1 -fcuda-is-device -triple amdgcn-amd-amdhsa -S \
+// RUN:   -O3 -target-cpu gfx906 -o - -x hip %s \
+// RUN:   -ffp-contract=fast \
+// RUN:   | FileCheck -check-prefixes=COMMON,AMD-OPT-FAST %s
+
+// Check separate compile/backend steps corresponding to -save-temps.
+// When input is IR, -ffp-contract has no effect. Backend uses default
+// default FP fuse option.
+
+// RUN: %clang_cc1 -fcuda-is-device -triple amdgcn-amd-amdhsa -emit-llvm \
+// RUN:   -ffp-contract=fast \
+// RUN:   -O3 -disable-llvm-passes -target-cpu gfx906 -o %t.ll -x hip %s
+// RUN: cat %t.ll  | FileCheck -check-prefixes=COMMON,AMD-OPT-FAST-IR %s
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -S \
+// RUN:   -O3 -target-cpu gfx906 -o - -x ir %t.ll \
+// RUN:   | FileCheck -che

[PATCH] D87194: Thread safety analysis: Use access specifiers to decide about scope

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert planned changes to this revision.
aaronpuchert added a comment.

That's a good point, while `mu_` is public, `params` is a local variable.

I need to take into account the left-hand side of a `til::Project`, which we're 
currently ignoring.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87194

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

[PATCH] D90409: [HIP] Math Headers to use type promotion

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D90409#2371987 , @tra wrote:

> In D90409#2371969 , @yaxunl wrote:
>
>> nvcc does not support fma(float,float,char)
>
> It does, it just needs an explicit flag to match clang's treatment of 
> `constexpr` functions as HD.



In D90409#2371972 , @tra wrote:

> In D90409#2371679 , @jlebar wrote:
>
>>> LGTM. I think the change would make sense for CUDA, too. @jlebar - WDYT?
>>
>> I agree that the C and C++ standard libraries should behave the same in CUDA 
>> mode and host mode!
>>
>> But if doing so would make our behavior different than nvcc's, maybe we 
>> could emit a warning or something?  Like, "this code you wrote maybe for 
>> nvcc is going to do something different with clang."
>
> Interestingly enough CUDA 10.1+ already promotes integer `fma()` arguments to 
> double:
> https://godbolt.org/z/crbqTe
>
> I wonder what makes HIP different to require this change.

Practically the behavior is the same since they all promote integer types to 
double. This matches the C++ behavior. However the HIP change will make it 
conform to C++ for a target supporting long double whereas the previous header 
did not.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90409

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

[clang] 96ed679 - [unittest][TrasnformerTest] Fix asan stack-use-after-return

[Fangrui Song via cfe-commits]

Author: Fangrui Song
Date: 2020-11-03T12:34:45-08:00
New Revision: 96ed6793b35e8267b0c94ebe69ae94f07024f476

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

LOG: [unittest][TrasnformerTest] Fix asan stack-use-after-return

Added: 


Modified: 
clang/unittests/Tooling/TransformerTest.cpp

Removed: 




diff  --git a/clang/unittests/Tooling/TransformerTest.cpp 
b/clang/unittests/Tooling/TransformerTest.cpp
index 46f1d63752d8..1f0637446a00 100644
--- a/clang/unittests/Tooling/TransformerTest.cpp
+++ b/clang/unittests/Tooling/TransformerTest.cpp
@@ -126,11 +126,14 @@ class ClangRefactoringTestBase : public testing::Test {
 
   template 
   void testRule(R Rule, StringRef Input, StringRef Expected) {
-Transformer T(std::move(Rule), consumer());
-T.registerMatchers(&MatchFinder);
+Transformers.push_back(
+std::make_unique(std::move(Rule), consumer()));
+Transformers.back()->registerMatchers(&MatchFinder);
 compareSnippets(Expected, rewrite(Input));
   }
 
+  // Transformers are referenced by MatchFinder.
+  std::vector> Transformers;
   clang::ast_matchers::MatchFinder MatchFinder;
   // Records whether any errors occurred in individual changes.
   int ErrorCount = 0;



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

[PATCH] D90682: [clangd][NFC] Make Located::operator->() use pointer sematics

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

Ah thanks for catching this. LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90682

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

[PATCH] D90409: [HIP] Math Headers to use type promotion

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D90409#2372023 , @yaxunl wrote:

> In D90409#2371987 , @tra wrote:
>
>> In D90409#2371969 , @yaxunl wrote:
>>
>>> nvcc does not support fma(float,float,char)
>>
>> It does, it just needs an explicit flag to match clang's treatment of 
>> `constexpr` functions as HD.
>
>
>
> In D90409#2371972 , @tra wrote:
>
>> In D90409#2371679 , @jlebar wrote:
>>
 LGTM. I think the change would make sense for CUDA, too. @jlebar - WDYT?
>>>
>>> I agree that the C and C++ standard libraries should behave the same in 
>>> CUDA mode and host mode!
>>>
>>> But if doing so would make our behavior different than nvcc's, maybe we 
>>> could emit a warning or something?  Like, "this code you wrote maybe for 
>>> nvcc is going to do something different with clang."
>>
>> Interestingly enough CUDA 10.1+ already promotes integer `fma()` arguments 
>> to double:
>> https://godbolt.org/z/crbqTe
>>
>> I wonder what makes HIP different to require this change.
>
> Practically the behavior is the same since they all promote integer types to 
> double. This matches the C++ behavior. However the HIP change will make it 
> conform to C++ for a target supporting long double whereas the previous 
> header did not.

Sorry I mean the change can make the header extendable to `long double` easily 
although it does not yet. Another thing is that it allows resolution of mixed 
argument types with _Float16.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90409

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

[clang-tools-extra] 7f059a2 - [clangd] Handle absolute/relative path specifications in Config

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2020-11-03T21:45:35+01:00
New Revision: 7f059a258a1dbfc240a8d526b5d23d238a3d84f7

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

LOG: [clangd] Handle absolute/relative path specifications in Config

This introduces a mechanism for providers to interpret paths specified
in a fragment either as absolute or relative to fragment location.
This information should be used during compile stage to handle blocks correctly.

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

Added: 


Modified: 
clang-tools-extra/clangd/ConfigCompile.cpp
clang-tools-extra/clangd/ConfigFragment.h
clang-tools-extra/clangd/ConfigProvider.cpp
clang-tools-extra/clangd/ConfigProvider.h
clang-tools-extra/clangd/tool/ClangdMain.cpp
clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/ConfigCompile.cpp 
b/clang-tools-extra/clangd/ConfigCompile.cpp
index 62fda5c9eacc..f73db45d3ab5 100644
--- a/clang-tools-extra/clangd/ConfigCompile.cpp
+++ b/clang-tools-extra/clangd/ConfigCompile.cpp
@@ -26,20 +26,34 @@
 #include "CompileCommands.h"
 #include "Config.h"
 #include "ConfigFragment.h"
+#include "ConfigProvider.h"
 #include "support/Logger.h"
 #include "support/Trace.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSwitch.h"
+#include "llvm/Support/Path.h"
 #include "llvm/Support/Regex.h"
 #include "llvm/Support/SMLoc.h"
 #include "llvm/Support/SourceMgr.h"
+#include 
 
 namespace clang {
 namespace clangd {
 namespace config {
 namespace {
 
+// Returns an empty stringref if Path is not under FragmentDir. Returns Path
+// as-is when FragmentDir is empty.
+llvm::StringRef configRelative(llvm::StringRef Path,
+   llvm::StringRef FragmentDir) {
+  if (FragmentDir.empty())
+return Path;
+  if (!Path.consume_front(FragmentDir))
+return llvm::StringRef();
+  return Path.empty() ? "." : Path;
+}
+
 struct CompiledFragmentImpl {
   // The independent conditions to check before using settings from this 
config.
   // The following fragment has *two* conditions:
@@ -67,9 +81,14 @@ struct CompiledFragmentImpl {
 
 // Wrapper around condition compile() functions to reduce arg-passing.
 struct FragmentCompiler {
+  FragmentCompiler(CompiledFragmentImpl &Out, DiagnosticCallback D,
+   llvm::SourceMgr *SM)
+  : Out(Out), Diagnostic(D), SourceMgr(SM) {}
   CompiledFragmentImpl &Out;
   DiagnosticCallback Diagnostic;
   llvm::SourceMgr *SourceMgr;
+  // Normalized Fragment::SourceInfo::Directory.
+  std::string FragmentDirectory;
 
   llvm::Optional compileRegex(const Located &Text) {
 std::string Anchored = "^(" + *Text + ")$";
@@ -129,6 +148,11 @@ struct FragmentCompiler {
   }
 
   void compile(Fragment &&F) {
+if (!F.Source.Directory.empty()) {
+  FragmentDirectory = 
llvm::sys::path::convert_to_slash(F.Source.Directory);
+  if (FragmentDirectory.back() != '/')
+FragmentDirectory += '/';
+}
 compile(std::move(F.If));
 compile(std::move(F.CompileFlags));
 compile(std::move(F.Index));
@@ -145,11 +169,16 @@ struct FragmentCompiler {
 }
 if (!PathMatch->empty()) {
   Out.Conditions.push_back(
-  [PathMatch(std::move(PathMatch))](const Params &P) {
+  [PathMatch(std::move(PathMatch)),
+   FragmentDir(FragmentDirectory)](const Params &P) {
 if (P.Path.empty())
   return false;
+llvm::StringRef Path = configRelative(P.Path, FragmentDir);
+// Ignore the file if it is not nested under Fragment.
+if (Path.empty())
+  return false;
 return llvm::any_of(*PathMatch, [&](const llvm::Regex &RE) {
-  return RE.match(P.Path);
+  return RE.match(Path);
 });
   });
 }
@@ -161,11 +190,16 @@ struct FragmentCompiler {
 }
 if (!PathExclude->empty()) {
   Out.Conditions.push_back(
-  [PathExclude(std::move(PathExclude))](const Params &P) {
+  [PathExclude(std::move(PathExclude)),
+   FragmentDir(FragmentDirectory)](const Params &P) {
 if (P.Path.empty())
   return false;
+llvm::StringRef Path = configRelative(P.Path, FragmentDir);
+// Ignore the file if it is not nested under Fragment.
+if (Path.empty())
+  return true;
 return llvm::none_of(*PathExclude, [&](const llvm::Regex &RE) {
-  return RE.match(P.Path);
+  return RE.match(Path);
 });
   });
 }

diff  --git a/clang-tools-extra/clangd/ConfigFragment.h 

[PATCH] D90270: [clangd] Handle absolute/relative path specifications in Config

[Kadir Cetinkaya via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7f059a258a1d: [clangd] Handle absolute/relative path 
specifications in Config (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90270

Files:
  clang-tools-extra/clangd/ConfigCompile.cpp
  clang-tools-extra/clangd/ConfigFragment.h
  clang-tools-extra/clangd/ConfigProvider.cpp
  clang-tools-extra/clangd/ConfigProvider.h
  clang-tools-extra/clangd/tool/ClangdMain.cpp
  clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
  clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp

Index: clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp
===
--- clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp
+++ clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp
@@ -10,6 +10,7 @@
 #include "ConfigProvider.h"
 #include "ConfigTesting.h"
 #include "TestFS.h"
+#include "llvm/Support/Path.h"
 #include "llvm/Support/SourceMgr.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -91,7 +92,7 @@
   FS.Files["foo.yaml"] = AddFooWithErr;
 
   CapturedDiags Diags;
-  auto P = Provider::fromYAMLFile(testPath("foo.yaml"), FS);
+  auto P = Provider::fromYAMLFile(testPath("foo.yaml"), /*Directory=*/"", FS);
   auto Cfg = P->getConfig(Params(), Diags.callback());
   EXPECT_THAT(Diags.Diagnostics,
   ElementsAre(DiagMessage("Unknown CompileFlags key Unknown")));
@@ -159,7 +160,7 @@
   Params MustBeFresh;
   MustBeFresh.FreshTime = StartTime + std::chrono::hours(1);
   CapturedDiags Diags;
-  auto P = Provider::fromYAMLFile(testPath("foo.yaml"), FS);
+  auto P = Provider::fromYAMLFile(testPath("foo.yaml"), /*Directory=*/"", FS);
 
   // Initial query always reads, regardless of policy.
   FS.Files["foo.yaml"] = AddFooWithErr;
@@ -187,6 +188,37 @@
   EXPECT_THAT(getAddedArgs(Cfg), IsEmpty());
 }
 
+TEST(ProviderTest, SourceInfo) {
+  MockFS FS;
+
+  FS.Files["baz/foo.yaml"] = R"yaml(
+If:
+  PathMatch: .*
+  PathExclude: bar.h
+CompileFlags:
+  Add: bar
+)yaml";
+  const auto BarPath = testPath("baz/bar.h", llvm::sys::path::Style::posix);
+  CapturedDiags Diags;
+  Params Bar;
+  Bar.Path = BarPath;
+
+  // This should be an absolute match/exclude hence baz/bar.h should not be
+  // excluded.
+  auto P =
+  Provider::fromYAMLFile(testPath("baz/foo.yaml"), /*Directory=*/"", FS);
+  auto Cfg = P->getConfig(Bar, Diags.callback());
+  ASSERT_THAT(Diags.Diagnostics, IsEmpty());
+  EXPECT_THAT(getAddedArgs(Cfg), ElementsAre("bar"));
+  Diags.Diagnostics.clear();
+
+  // This should be a relative match/exclude hence baz/bar.h should be excluded.
+  P = Provider::fromAncestorRelativeYAMLFiles("foo.yaml", FS);
+  Cfg = P->getConfig(Bar, Diags.callback());
+  ASSERT_THAT(Diags.Diagnostics, IsEmpty());
+  EXPECT_THAT(getAddedArgs(Cfg), IsEmpty());
+  Diags.Diagnostics.clear();
+}
 } // namespace
 } // namespace config
 } // namespace clangd
Index: clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
===
--- clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
+++ clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
@@ -9,8 +9,12 @@
 #include "Config.h"
 #include "ConfigFragment.h"
 #include "ConfigTesting.h"
+#include "TestFS.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Path.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
+#include 
 
 namespace clang {
 namespace clangd {
@@ -116,6 +120,62 @@
   "Invalid Background value 'Foo'. Valid values are Build, Skip.")));
 }
 
+TEST_F(ConfigCompileTests, PathSpecMatch) {
+  auto BarPath = llvm::sys::path::convert_to_slash(testPath("foo/bar.h"));
+  Parm.Path = BarPath;
+
+  struct {
+std::string Directory;
+std::string PathSpec;
+bool ShouldMatch;
+  } Cases[] = {
+  {
+  // Absolute path matches.
+  "",
+  llvm::sys::path::convert_to_slash(testPath("foo/bar.h")),
+  true,
+  },
+  {
+  // Absolute path fails.
+  "",
+  llvm::sys::path::convert_to_slash(testPath("bar/bar.h")),
+  false,
+  },
+  {
+  // Relative should fail to match as /foo/bar.h doesn't reside under
+  // /baz/.
+  testPath("baz"),
+  "bar\\.h",
+  false,
+  },
+  {
+  // Relative should pass with /foo as directory.
+  testPath("foo"),
+  "bar\\.h",
+  true,
+  },
+  };
+
+  // PathMatch
+  for (const auto &Case : Cases) {
+Frag = {};
+Frag.If.PathMatch.emplace_back(Case.PathSpec);
+Frag.Source.Directory = Case.Directory;
+EXPECT_EQ(compileAndApply(), Case.ShouldMatch);
+ASSERT_THAT(Diags.Diagnostics, IsEmpty());
+  }
+
+  // PathEclude
+  for (const auto &Case : Cases) {
+ 

[clang-tools-extra] 05e0a8e - [clangd] Fix missing override warnings in remote-index client

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2020-11-03T21:46:44+01:00
New Revision: 05e0a8e519fd7dd73141b58a1a479a84a5ac1014

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

LOG: [clangd] Fix missing override warnings in remote-index client

Added: 


Modified: 
clang-tools-extra/clangd/index/remote/Client.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/index/remote/Client.cpp 
b/clang-tools-extra/clangd/index/remote/Client.cpp
index ff6f1b2898d7..ef5c6ce430f6 100644
--- a/clang-tools-extra/clangd/index/remote/Client.cpp
+++ b/clang-tools-extra/clangd/index/remote/Client.cpp
@@ -84,26 +84,28 @@ class IndexClient : public clangd::SymbolIndex {
   }
 
   void lookup(const clangd::LookupRequest &Request,
-  llvm::function_ref Callback) const 
{
+  llvm::function_ref Callback)
+  const override {
 streamRPC(Request, &remote::v1::SymbolIndex::Stub::Lookup, Callback);
   }
 
-  bool
-  fuzzyFind(const clangd::FuzzyFindRequest &Request,
-llvm::function_ref Callback) const {
+  bool fuzzyFind(const clangd::FuzzyFindRequest &Request,
+ llvm::function_ref Callback)
+  const override {
 return streamRPC(Request, &remote::v1::SymbolIndex::Stub::FuzzyFind,
  Callback);
   }
 
-  bool refs(const clangd::RefsRequest &Request,
-llvm::function_ref Callback) const {
+  bool
+  refs(const clangd::RefsRequest &Request,
+   llvm::function_ref Callback) const override {
 return streamRPC(Request, &remote::v1::SymbolIndex::Stub::Refs, Callback);
   }
 
   void
   relations(const clangd::RelationsRequest &Request,
 llvm::function_ref
-Callback) const {
+Callback) const override {
 streamRPC(Request, &remote::v1::SymbolIndex::Stub::Relations,
   // Unpack protobuf Relation.
   [&](std::pair SubjectAndObject) {
@@ -113,7 +115,7 @@ class IndexClient : public clangd::SymbolIndex {
 
   // IndexClient does not take any space since the data is stored on the
   // server.
-  size_t estimateMemoryUsage() const { return 0; }
+  size_t estimateMemoryUsage() const override { return 0; }
 
 private:
   std::unique_ptr Stub;



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

[PATCH] D89980: [hip] Remove kernel argument coercion.

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

In D89980#2371966 , @arsenm wrote:

> In D89980#2371952 , @hliao wrote:
>
>> In D89980#2371850 , @arsenm wrote:
>>
>>> This should use byref, but I don't think this should come at the cost of 
>>> the promotion. I would still like to see this promotion occur for the 
>>> in-memory byref type
>>
>> Once we use `byref`, that in-memory byref type has no way to be preserved 
>> based on C model as it will be treated as a local variable. The initial 
>> value with the coerced type won't be preserved after that. That happens to 
>> the case with static index as well, but the promotion helps to build the 
>> chain from the initial value to the final use. But, if we cannot promote 
>> `alloca` finally, we lost that information or cannot assume that.
>
> Then the promotion can also be applied to the temporary argument slot

That's not safe to do that in the frontend as all arguments are local variables 
as well. They may be modified later. Such an assumption (pointers from argument 
is GLOBAL or CONSTANT) won't hold anymore.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

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

[PATCH] D89980: [hip] Remove kernel argument coercion.

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D89980#2372102 , @hliao wrote:

> In D89980#2371966 , @arsenm wrote:
>
>> In D89980#2371952 , @hliao wrote:
>>
>>> In D89980#2371850 , @arsenm wrote:
>>>
 This should use byref, but I don't think this should come at the cost of 
 the promotion. I would still like to see this promotion occur for the 
 in-memory byref type
>>>
>>> Once we use `byref`, that in-memory byref type has no way to be preserved 
>>> based on C model as it will be treated as a local variable. The initial 
>>> value with the coerced type won't be preserved after that. That happens to 
>>> the case with static index as well, but the promotion helps to build the 
>>> chain from the initial value to the final use. But, if we cannot promote 
>>> `alloca` finally, we lost that information or cannot assume that.
>>
>> Then the promotion can also be applied to the temporary argument slot
>
> That's not safe to do that in the frontend as all arguments are local 
> variables as well. They may be modified later. Such an assumption (pointers 
> from argument is GLOBAL or CONSTANT) won't hold anymore.

The type in the kernel argument byref does not need to match the alloca's type. 
The coercions can be inserted when initializing the argument alloca


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

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

[PATCH] D85474: Add -fbinutils-version= to gate ELF features on the specified binutils version

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

Ping @compnerd


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85474

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

[clang] daa127d - [PowerPC] Add MMA builtin decoding and definitions

[Baptiste Saleil via cfe-commits]

Author: Baptiste Saleil
Date: 2020-11-03T15:08:46-06:00
New Revision: daa127d77eab2547b1b7754939aa3f91fa8b1801

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

LOG: [PowerPC] Add MMA builtin decoding and definitions

Add MMA builtin decoding. These builtins use the new PowerPC-specific types 
__vector_pair and __vector_quad.
So to avoid pervasive changes, we use custom type descriptors and custom 
decoding for these builtins.
We also use custom code generation to expand builtin calls with pointers to 
simpler intrinsic calls with non-pointer types.

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

Added: 
clang/test/CodeGen/builtins-ppc-mma.c

Modified: 
clang/include/clang/AST/ASTContext.h
clang/include/clang/Basic/BuiltinsPPC.def
clang/include/clang/Sema/Sema.h
clang/lib/AST/ASTContext.cpp
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/Sema/SemaChecking.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 59135b6a4d35..5c92dfa39f69 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -2047,6 +2047,10 @@ class ASTContext : public RefCountedBase {
 GE_Missing_ucontext
   };
 
+  QualType DecodeTypeStr(const char *&Str, const ASTContext &Context,
+ ASTContext::GetBuiltinTypeError &Error,
+ bool &RequireICE, bool AllowTypeModifiers) const;
+
   /// Return the type for the specified builtin.
   ///
   /// If \p IntegerConstantArgs is non-null, it is filled in with a bitmask of

diff  --git a/clang/include/clang/Basic/BuiltinsPPC.def 
b/clang/include/clang/Basic/BuiltinsPPC.def
index fe20c9418e8d..f35a49b681cc 100644
--- a/clang/include/clang/Basic/BuiltinsPPC.def
+++ b/clang/include/clang/Basic/BuiltinsPPC.def
@@ -7,14 +7,22 @@
 
//===--===//
 //
 // This file defines the PowerPC-specific builtin function database.  Users of
-// this file must define the BUILTIN macro to make use of this information.
+// this file must define the BUILTIN macro or the MMA_BUILTIN macro to make use
+// of this information.
 //
 
//===--===//
 
 // FIXME: this needs to be the full list supported by GCC.  Right now, I'm just
 // adding stuff on demand.
 
-// The format of this database matches clang/Basic/Builtins.def.
+// The format of this database matches clang/Basic/Builtins.def except for the
+// MMA builtins that are using their own format documented below.
+
+#if defined(BUILTIN) && !defined(MMA_BUILTIN)
+#   define MMA_BUILTIN(ID, TYPES, ACCUMULATE) BUILTIN(__builtin_mma_##ID, 
"i.", "t")
+#elif defined(MMA_BUILTIN) && !defined(BUILTIN)
+#   define BUILTIN(ID, TYPES, ATTRS)
+#endif
 
 BUILTIN(__builtin_ppc_get_timebase, "ULLi", "n")
 
@@ -646,6 +654,92 @@ BUILTIN(__builtin_setflm, "dd", "")
 // Cache built-ins
 BUILTIN(__builtin_dcbf, "vvC*", "")
 
+// MMA built-ins
+// All MMA built-ins are declared here using the MMA_BUILTIN macro. Because
+// these built-ins rely on target-dependent types and to avoid pervasive 
change,
+// they are type checked manually in Sema using custom type descriptors.
+// The first argument of the MMA_BUILTIN macro is the name of the built-in, the
+// second argument specifies the type of the function (result value, then each
+// argument) as follows:
+//  i -> Unsigned integer followed by the greatest possible value for that
+//   argument or 0 if no constraint on the value.
+//   (e.g. i15 for a 4-bits value)
+//  v -> void
+//  V -> Vector type used with MMA builtins (vector unsigned char)
+//  W -> MMA vector type followed by the size of the vector type.
+//   (e.g. W512 for __vector_quad)
+// The 'C' suffix can be used as a suffix to specify the const type.
+// The '*' suffix can be used as a suffix to specify a pointer to a type.
+// The third argument is set to true if the builtin accumulates its result into
+// its given accumulator.
+
+MMA_BUILTIN(assemble_acc, "vW512*", false)
+MMA_BUILTIN(disassemble_acc, "vv*W512*", false)
+MMA_BUILTIN(assemble_pair, "vW256*VV", false)
+MMA_BUILTIN(disassemble_pair, "vv*W256*", false)
+MMA_BUILTIN(xxmtacc, "vW512*", true)
+MMA_BUILTIN(xxmfacc, "vW512*", true)
+MMA_BUILTIN(xxsetaccz, "vW512*", false)
+MMA_BUILTIN(xvi4ger8, "vW512*VV", false)
+MMA_BUILTIN(xvi8ger4, "vW512*VV", false)
+MMA_BUILTIN(xvi16ger2, "vW512*VV", false)
+MMA_BUILTIN(xvi16ger2s, "vW512*VV", false)
+MMA_BUILTIN(xvf16ger2, "vW512*VV", false)
+MMA_BUILTIN(xvf32ger, "vW512*VV", false)
+MMA_BUILTIN(xvf64ger, "vW512*W256V", false)
+MMA_BUILTIN(pmxvi4ger8, "vW512*VVi15i15i255", false)
+MMA_BUILTIN(pmxvi8ger4, "vW512*VVi15i15i15", f

[PATCH] D81748: [PowerPC] Add MMA builtin decoding and definitions

[Baptiste Saleil via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGdaa127d77eab: [PowerPC] Add MMA builtin decoding and 
definitions (authored by bsaleil).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81748

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-mma.c

Index: clang/test/CodeGen/builtins-ppc-mma.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-mma.c
@@ -0,0 +1,1038 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -O3 -triple powerpc64le-unknown-unknown -target-cpu future -emit-llvm %s -o - | FileCheck %s
+
+// CHECK-LABEL: @test1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = tail call <512 x i1> @llvm.ppc.mma.assemble.acc(<16 x i8> [[VC:%.*]], <16 x i8> [[VC]], <16 x i8> [[VC]], <16 x i8> [[VC]])
+// CHECK-NEXT:[[TMP1:%.*]] = bitcast i8* [[RESP:%.*]] to <512 x i1>*
+// CHECK-NEXT:store <512 x i1> [[TMP0]], <512 x i1>* [[TMP1]], align 64, !tbaa !2
+// CHECK-NEXT:ret void
+//
+void test1(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_quad vq = *((__vector_quad *)vqp);
+  __vector_pair vp = *((__vector_pair *)vpp);
+  __vector_quad res;
+  __builtin_mma_assemble_acc(&res, vc, vc, vc, vc);
+  *((__vector_quad *)resp) = res;
+}
+
+// CHECK-LABEL: @test2(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = bitcast i8* [[VQP:%.*]] to <512 x i1>*
+// CHECK-NEXT:[[TMP1:%.*]] = load <512 x i1>, <512 x i1>* [[TMP0]], align 64
+// CHECK-NEXT:[[TMP2:%.*]] = tail call { <16 x i8>, <16 x i8>, <16 x i8>, <16 x i8> } @llvm.ppc.mma.disassemble.acc(<512 x i1> [[TMP1]])
+// CHECK-NEXT:[[TMP3:%.*]] = bitcast i8* [[RESP:%.*]] to <16 x i8>*
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { <16 x i8>, <16 x i8>, <16 x i8>, <16 x i8> } [[TMP2]], 0
+// CHECK-NEXT:store <16 x i8> [[TMP4]], <16 x i8>* [[TMP3]], align 16
+// CHECK-NEXT:[[TMP5:%.*]] = extractvalue { <16 x i8>, <16 x i8>, <16 x i8>, <16 x i8> } [[TMP2]], 1
+// CHECK-NEXT:[[TMP6:%.*]] = getelementptr inbounds i8, i8* [[RESP]], i64 16
+// CHECK-NEXT:[[TMP7:%.*]] = bitcast i8* [[TMP6]] to <16 x i8>*
+// CHECK-NEXT:store <16 x i8> [[TMP5]], <16 x i8>* [[TMP7]], align 16
+// CHECK-NEXT:[[TMP8:%.*]] = extractvalue { <16 x i8>, <16 x i8>, <16 x i8>, <16 x i8> } [[TMP2]], 2
+// CHECK-NEXT:[[TMP9:%.*]] = getelementptr inbounds i8, i8* [[RESP]], i64 32
+// CHECK-NEXT:[[TMP10:%.*]] = bitcast i8* [[TMP9]] to <16 x i8>*
+// CHECK-NEXT:store <16 x i8> [[TMP8]], <16 x i8>* [[TMP10]], align 16
+// CHECK-NEXT:[[TMP11:%.*]] = extractvalue { <16 x i8>, <16 x i8>, <16 x i8>, <16 x i8> } [[TMP2]], 3
+// CHECK-NEXT:[[TMP12:%.*]] = getelementptr inbounds i8, i8* [[RESP]], i64 48
+// CHECK-NEXT:[[TMP13:%.*]] = bitcast i8* [[TMP12]] to <16 x i8>*
+// CHECK-NEXT:store <16 x i8> [[TMP11]], <16 x i8>* [[TMP13]], align 16
+// CHECK-NEXT:ret void
+//
+void test2(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __builtin_mma_disassemble_acc(resp, (__vector_quad*)vqp);
+}
+
+// CHECK-LABEL: @test3(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = tail call <256 x i1> @llvm.ppc.mma.assemble.pair(<16 x i8> [[VC:%.*]], <16 x i8> [[VC]])
+// CHECK-NEXT:[[TMP1:%.*]] = bitcast i8* [[RESP:%.*]] to <256 x i1>*
+// CHECK-NEXT:store <256 x i1> [[TMP0]], <256 x i1>* [[TMP1]], align 32, !tbaa !6
+// CHECK-NEXT:ret void
+//
+void test3(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_quad vq = *((__vector_quad *)vqp);
+  __vector_pair vp = *((__vector_pair *)vpp);
+  __vector_pair res;
+  __builtin_mma_assemble_pair(&res, vc, vc);
+  *((__vector_pair *)resp) = res;
+}
+
+// CHECK-LABEL: @test4(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = bitcast i8* [[VPP:%.*]] to <256 x i1>*
+// CHECK-NEXT:[[TMP1:%.*]] = load <256 x i1>, <256 x i1>* [[TMP0]], align 32
+// CHECK-NEXT:[[TMP2:%.*]] = tail call { <16 x i8>, <16 x i8> } @llvm.ppc.mma.disassemble.pair(<256 x i1> [[TMP1]])
+// CHECK-NEXT:[[TMP3:%.*]] = bitcast i8* [[RESP:%.*]] to <16 x i8>*
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { <16 x i8>, <16 x i8> } [[TMP2]], 0
+// CHECK-NEXT:store <16 x i8> [[TMP4]], <16 x i8>* [[TMP3]], align 16
+// CHECK-NEXT:[[TMP5:%.*]] = extractvalue { <16 x i8>, <16 x i8> } [[TMP2]], 1
+// CHECK-NEXT:[[TMP6:%.*]] = getelementptr inbounds i8, i8* [[RESP]], i64 16
+// CHECK-NEXT:[[TMP7:%.*]] = bitcast i8* [[TMP6]] to <16 x i8>*
+// CH

[PATCH] D90704: [OpenMP] target nested `use_device_ptr() if()` and is_device_ptr trigger asserts

[Chi Chun Chen via Phabricator via cfe-commits]

cchen updated this revision to Diff 302672.
cchen added a comment.

Separate test to a independent file


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90704

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/target_data_use_device_ptr_if_codegen.cpp


Index: clang/test/OpenMP/target_data_use_device_ptr_if_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/target_data_use_device_ptr_if_codegen.cpp
@@ -0,0 +1,48 @@
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+///==///
+// RUN: %clang_cc1 -DCK1 -verify -fopenmp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 
powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix 
CK1 --check-prefix CK1-64
+// RUN: %clang_cc1 -DCK1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu 
-x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ 
-triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s 
-emit-llvm -o - | FileCheck %s  --check-prefix CK1 --check-prefix CK1-64
+// RUN: %clang_cc1 -DCK1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu 
-x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck %s  
--check-prefix CK1 --check-prefix CK1-32
+// RUN: %clang_cc1 -DCK1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ 
-std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple 
i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | 
FileCheck %s  --check-prefix CK1 --check-prefix CK1-32
+
+// RUN: %clang_cc1 -DCK1 -verify -fopenmp-simd 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 
powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix 
SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK1 -fopenmp-simd 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple 
powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x 
c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s 
-emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK1 -verify -fopenmp-simd 
-fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown 
-emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x 
c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ 
-triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm 
-o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// SIMD-ONLY1-NOT: {{__kmpc|__tgt}}
+#ifdef CK1
+
+// CK1: [[MTYPE00:@.+]] = {{.*}}constant [1 x i64] [i64 99]
+// CK1: [[MTYPE01:@.+]] = {{.*}}constant [1 x i64] [i64 288]
+// CK1: [[MTYPE02:@.+]] = {{.*}}constant [1 x i64] [i64 288]
+
+void add_one(float *b, int dm)
+{
+  // CK1: [[BP:%.+]] = getelementptr inbounds [1 x i8*], [1 x i8*]* 
%{{.+}}, i32 0, i32 0
+  // CK1: [[CBP:%.+]] = bitcast i8** [[BP]] to float**
+  // CK1: store float* [[B_ADDR:%.+]], float** [[CBP]]
+  // CK1: call void @__tgt_target_data_begin{{.+}}[[MTYPE00]]
+  // CK1: [[VAL:%.+]] = load float*, float** [[CBP]],
+  // CK1-NOT: store float* [[VAL]], float** [[DECL]],
+  // CK1: store float* [[VAL]], float** [[PVT:%.+]],
+  // CK1: [[TT:%.+]] = load float*, float** [[PVT]],
+  // CK1: call i32 @__tgt_target{{.+}}[[MTYPE01]]
+  // CK1: call i32 @__tgt_target{{.+}}[[MTYPE02]]
+  // CK1: call void @__tgt_target_data_end{{.+}}[[MTYPE00]]
+#pragma omp target data map(tofrom:b[:1]) use_device_ptr(b) if(dm == 0)
+  {
+#pragma omp target is_device_ptr(b)
+  {
+b[0] += 1;
+  }
+  }
+}
+
+#endif
+#endif
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -2955,6 +2955,19 @@
 Entry.setID(ID);
 Entry.setFlags(Flags);
   } else {
+auto PerDevice = OffloadEntriesTargetRegion.find(DeviceID);
+if (PerDevice != OffloadEntriesTargetRegion.end()) {
+  auto PerFile = PerDevice->second.find(FileID);
+  if (PerFile != PerDevice->second.end()) {
+auto PerParentName = PerFile->second.find(ParentName);
+if (PerParentName != PerFile->second.end()) {
+  auto PerLine = PerParentName->second.find(LineNum);
+  if (PerLine != PerParentName->second.end()) {
+return;
+  }
+}
+  }
+}
 OffloadEntryInfoTargetRegion Entry(OffloadingEntriesNum, Addr, ID, Flags);
 OffloadEntriesTargetReg

[PATCH] D85474: Add -fbinutils-version= to gate ELF features on the specified binutils version

[Peter Collingbourne via Phabricator via cfe-commits]

pcc added a comment.

I agree with @MaskRay that this should be a binutils-specific option. The flag 
`-mlinker-version` seems to have been designed around macOS-specific 
assumptions i.e. there is a single linker (ld64) and that the linker and 
assembler are not version coupled. Having this option be binutils-specific 
seems like the best way to reflect the binutils-specific requirements.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85474

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

[PATCH] D90704: [OpenMP] target nested `use_device_ptr() if()` and is_device_ptr trigger asserts

[Chi Chun Chen via Phabricator via cfe-commits]

cchen added a comment.

In D90704#2371938 , @jdoerfert wrote:

> I do not understand the commit message. Can you try to make it clearer?

Hi, sorry for the shabby commit message, I've updated it and use godbolt link 
instead of pasting the code snippet since the pragma is always removed 
automatically by git or arc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90704

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

[PATCH] D90409: [HIP] Math Headers to use type promotion

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D90409#2372042 , @yaxunl wrote:

>> Practically the behavior is the same since they all promote integer types to 
>> double. This matches the C++ behavior. However the HIP change will make it 
>> conform to C++ for a target supporting long double whereas the previous 
>> header did not.
>
> Sorry I mean the change can make the header extendable to `long double` 
> easily although it does not yet. Another thing is that it allows resolution 
> of mixed argument types with _Float16.

OK. This makes more sense now. Thank you for the explanation.

While this does solve one particular instance of the issue, we can't jsut 
copy/paste bits of the standard library forever. We need something more robust.
NVIDIA now has their own fork of the standard library 
https://github.com/NVIDIA/libcudacxx and that may be a good starting point.
I think at some point we (HIP & CUDA owners) need to talk to libc++ maintainers 
and see if we can find a better way to extend the standard library to CUDA/HIP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90409

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

[PATCH] D74735: [analyzer] Add support for CXXInheritedCtorInitExpr.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h:916-918
+  virtual const CXXInheritedCtorInitExpr *getOriginExpr() const {
+return cast(AnyFunctionCall::getOriginExpr());
+  }

steakhal wrote:
> Why is this function virtual?
> If we want such behavior we should mark the `CallEvent::getOriginExpr` 
> virtual and just //override// it here.
> As-of-now, this just hides the previous implementation, causing potential 
> problems.
> 
> This code-smell occures several times across this class hierachy.
> 
> Is this the expected behavior @NoQ?
I think you're right, it should have been virtual from the start. Weird. 
Probably the only reason this works is that all overrides do literally the same 
thing, just cast to different types. But if even one of them doesn't we're in 
trouble. Yeah this needs to be fixed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74735

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

[PATCH] D90714: [clang]Fix length threshold for MicrosoftMangle md5 hash

[Melanie Blower via Phabricator via cfe-commits]

mibintc created this revision.
mibintc added a reviewer: majnemer.
Herald added a project: clang.
mibintc requested review of this revision.

Fix off-by-one bug in determining the threshold for when want to shorten very 
large external names, Microsoft compatibility.
This fixes the bug reported here, https://bugs.llvm.org/show_bug.cgi?id=38868


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90714

Files:
  clang/lib/AST/MicrosoftMangle.cpp


Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -50,7 +50,7 @@
 bool StartsWithEscape = MangledName.startswith("\01");
 if (StartsWithEscape)
   MangledName = MangledName.drop_front(1);
-if (MangledName.size() <= 4096) {
+if (MangledName.size() < 4096) {
   OS << str();
   return;
 }


Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -50,7 +50,7 @@
 bool StartsWithEscape = MangledName.startswith("\01");
 if (StartsWithEscape)
   MangledName = MangledName.drop_front(1);
-if (MangledName.size() <= 4096) {
+if (MangledName.size() < 4096) {
   OS << str();
   return;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90704: [OpenMP] target nested `use_device_ptr() if()` and is_device_ptr trigger asserts

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

It would be good if you could identify the object which leads to a crash, I 
mean a target region, variable, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90704

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

[PATCH] D72184: [BPF] support atomic instructions

[Alexei Starovoitov via Phabricator via cfe-commits]

ast added inline comments.



Comment at: llvm/test/CodeGen/BPF/atomics_2.ll:124
+; CHECK: r0 = r2
+; CHECK: r0 = cmpxchg_64(r1 + 0, r0, r3)
+; CHECK: encoding: [0xdb,0x01,0x00,0x00,0xf1,0x03,0x00,0x00]

Looks like it's generating correct code without special handling in 
ISelLowering. Nice. I wonder why x86 had to use it. Because of eflags, I guess?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72184

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

[clang] 72531ae - Revert "Ignore template instantiations if not in AsIs mode"

[Matt Morehouse via cfe-commits]

Author: Matt Morehouse
Date: 2020-11-03T13:57:31-08:00
New Revision: 72531ae6e64d4408f6e9aee8d5902f5d6b0ae519

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

LOG: Revert "Ignore template instantiations if not in AsIs mode"

This reverts commit 53df3beb624989ed32d87697d0c17601d7871465 due to
check-asan failure on the buildbot.

Added: 


Modified: 
clang/include/clang/AST/ASTNodeTraverser.h
clang/include/clang/AST/RecursiveASTVisitor.h
clang/include/clang/ASTMatchers/ASTMatchersInternal.h
clang/lib/AST/ASTDumper.cpp
clang/lib/ASTMatchers/ASTMatchFinder.cpp
clang/lib/ASTMatchers/ASTMatchersInternal.cpp
clang/unittests/AST/ASTTraverserTest.cpp
clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
clang/unittests/Tooling/TransformerTest.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTNodeTraverser.h 
b/clang/include/clang/AST/ASTNodeTraverser.h
index 1141f514d795..b0b1c152db05 100644
--- a/clang/include/clang/AST/ASTNodeTraverser.h
+++ b/clang/include/clang/AST/ASTNodeTraverser.h
@@ -82,7 +82,6 @@ class ASTNodeTraverser
   bool getDeserialize() const { return Deserialize; }
 
   void SetTraversalKind(TraversalKind TK) { Traversal = TK; }
-  TraversalKind GetTraversalKind() const { return Traversal; }
 
   void Visit(const Decl *D) {
 getNodeDelegate().AddChild([=] {
@@ -482,10 +481,8 @@ class ASTNodeTraverser
 
 Visit(D->getTemplatedDecl());
 
-if (Traversal == TK_AsIs) {
-  for (const auto *Child : D->specializations())
-dumpTemplateDeclSpecialization(Child);
-}
+for (const auto *Child : D->specializations())
+  dumpTemplateDeclSpecialization(Child);
   }
 
   void VisitTypeAliasDecl(const TypeAliasDecl *D) {

diff  --git a/clang/include/clang/AST/RecursiveASTVisitor.h 
b/clang/include/clang/AST/RecursiveASTVisitor.h
index 0a36ec9ad687..5e83cded0652 100644
--- a/clang/include/clang/AST/RecursiveASTVisitor.h
+++ b/clang/include/clang/AST/RecursiveASTVisitor.h
@@ -461,13 +461,6 @@ template  class RecursiveASTVisitor {
 
   bool canIgnoreChildDeclWhileTraversingDeclContext(const Decl *Child);
 
-#define DEF_TRAVERSE_TMPL_INST(TMPLDECLKIND)   
\
-  bool TraverseTemplateInstantiations(TMPLDECLKIND##TemplateDecl *D);
-  DEF_TRAVERSE_TMPL_INST(Class)
-  DEF_TRAVERSE_TMPL_INST(Var)
-  DEF_TRAVERSE_TMPL_INST(Function)
-#undef DEF_TRAVERSE_TMPL_INST
-
 private:
   // These are helper methods used by more than one Traverse* method.
   bool TraverseTemplateParameterListHelper(TemplateParameterList *TPL);
@@ -476,6 +469,12 @@ template  class RecursiveASTVisitor {
   template 
   bool TraverseDeclTemplateParameterLists(T *D);
 
+#define DEF_TRAVERSE_TMPL_INST(TMPLDECLKIND)   
\
+  bool TraverseTemplateInstantiations(TMPLDECLKIND##TemplateDecl *D);
+  DEF_TRAVERSE_TMPL_INST(Class)
+  DEF_TRAVERSE_TMPL_INST(Var)
+  DEF_TRAVERSE_TMPL_INST(Function)
+#undef DEF_TRAVERSE_TMPL_INST
   bool TraverseTemplateArgumentLocsHelper(const TemplateArgumentLoc *TAL,
   unsigned Count);
   bool TraverseArrayTypeLocHelper(ArrayTypeLoc TL);

diff  --git a/clang/include/clang/ASTMatchers/ASTMatchersInternal.h 
b/clang/include/clang/ASTMatchers/ASTMatchersInternal.h
index 1f5951877f24..2a3f503f9951 100644
--- a/clang/include/clang/ASTMatchers/ASTMatchersInternal.h
+++ b/clang/include/clang/ASTMatchers/ASTMatchersInternal.h
@@ -586,10 +586,6 @@ class Matcher {
   return this->InnerMatcher.matches(DynTypedNode::create(*Node), Finder,
 Builder);
 }
-
-llvm::Optional TraversalKind() const override {
-  return this->InnerMatcher.getTraversalKind();
-}
   };
 
 private:
@@ -1060,8 +1056,6 @@ class ASTMatchFinder {
 
   virtual ASTContext &getASTContext() const = 0;
 
-  virtual bool isMatchingInImplicitTemplateInstantiation() const = 0;
-
 protected:
   virtual bool matchesChildOf(const DynTypedNode &Node, ASTContext &Ctx,
   const DynTypedMatcher &Matcher,

diff  --git a/clang/lib/AST/ASTDumper.cpp b/clang/lib/AST/ASTDumper.cpp
index 3d368a0a7b63..284e5bdbc6b0 100644
--- a/clang/lib/AST/ASTDumper.cpp
+++ b/clang/lib/AST/ASTDumper.cpp
@@ -129,11 +129,9 @@ void ASTDumper::dumpTemplateDecl(const TemplateDecl *D, 
bool DumpExplicitInst) {
 
   Visit(D->getTemplatedDecl());
 
-  if (GetTraversalKind() == TK_AsIs) {
-for (const auto *Child : D->specializations())
-  dumpTemplateDeclSpecialization(Child, DumpExplicitInst,
- !D->isCanonicalDecl());
-  }
+  for (const auto *Child : D->specializations())
+dumpTemplateDeclSpecialization(Child, DumpExplicitInst,
+   !D->isCanonicalD

[clang] a6d15d4 - Undo Revert "Ignore template instantiations if not in AsIs mode"

[Matt Morehouse via cfe-commits]

Author: Matt Morehouse
Date: 2020-11-03T13:59:01-08:00
New Revision: a6d15d40701ad38f29e4ff93703b3ffa7b204611

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

LOG: Undo Revert "Ignore template instantiations if not in AsIs mode"

MaskRay already fixed the ASan bug.

Added: 


Modified: 
clang/include/clang/AST/ASTNodeTraverser.h
clang/include/clang/AST/RecursiveASTVisitor.h
clang/include/clang/ASTMatchers/ASTMatchersInternal.h
clang/lib/AST/ASTDumper.cpp
clang/lib/ASTMatchers/ASTMatchFinder.cpp
clang/lib/ASTMatchers/ASTMatchersInternal.cpp
clang/unittests/AST/ASTTraverserTest.cpp
clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
clang/unittests/Tooling/TransformerTest.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTNodeTraverser.h 
b/clang/include/clang/AST/ASTNodeTraverser.h
index b0b1c152db05..1141f514d795 100644
--- a/clang/include/clang/AST/ASTNodeTraverser.h
+++ b/clang/include/clang/AST/ASTNodeTraverser.h
@@ -82,6 +82,7 @@ class ASTNodeTraverser
   bool getDeserialize() const { return Deserialize; }
 
   void SetTraversalKind(TraversalKind TK) { Traversal = TK; }
+  TraversalKind GetTraversalKind() const { return Traversal; }
 
   void Visit(const Decl *D) {
 getNodeDelegate().AddChild([=] {
@@ -481,8 +482,10 @@ class ASTNodeTraverser
 
 Visit(D->getTemplatedDecl());
 
-for (const auto *Child : D->specializations())
-  dumpTemplateDeclSpecialization(Child);
+if (Traversal == TK_AsIs) {
+  for (const auto *Child : D->specializations())
+dumpTemplateDeclSpecialization(Child);
+}
   }
 
   void VisitTypeAliasDecl(const TypeAliasDecl *D) {

diff  --git a/clang/include/clang/AST/RecursiveASTVisitor.h 
b/clang/include/clang/AST/RecursiveASTVisitor.h
index 5e83cded0652..0a36ec9ad687 100644
--- a/clang/include/clang/AST/RecursiveASTVisitor.h
+++ b/clang/include/clang/AST/RecursiveASTVisitor.h
@@ -461,6 +461,13 @@ template  class RecursiveASTVisitor {
 
   bool canIgnoreChildDeclWhileTraversingDeclContext(const Decl *Child);
 
+#define DEF_TRAVERSE_TMPL_INST(TMPLDECLKIND)   
\
+  bool TraverseTemplateInstantiations(TMPLDECLKIND##TemplateDecl *D);
+  DEF_TRAVERSE_TMPL_INST(Class)
+  DEF_TRAVERSE_TMPL_INST(Var)
+  DEF_TRAVERSE_TMPL_INST(Function)
+#undef DEF_TRAVERSE_TMPL_INST
+
 private:
   // These are helper methods used by more than one Traverse* method.
   bool TraverseTemplateParameterListHelper(TemplateParameterList *TPL);
@@ -469,12 +476,6 @@ template  class RecursiveASTVisitor {
   template 
   bool TraverseDeclTemplateParameterLists(T *D);
 
-#define DEF_TRAVERSE_TMPL_INST(TMPLDECLKIND)   
\
-  bool TraverseTemplateInstantiations(TMPLDECLKIND##TemplateDecl *D);
-  DEF_TRAVERSE_TMPL_INST(Class)
-  DEF_TRAVERSE_TMPL_INST(Var)
-  DEF_TRAVERSE_TMPL_INST(Function)
-#undef DEF_TRAVERSE_TMPL_INST
   bool TraverseTemplateArgumentLocsHelper(const TemplateArgumentLoc *TAL,
   unsigned Count);
   bool TraverseArrayTypeLocHelper(ArrayTypeLoc TL);

diff  --git a/clang/include/clang/ASTMatchers/ASTMatchersInternal.h 
b/clang/include/clang/ASTMatchers/ASTMatchersInternal.h
index 2a3f503f9951..1f5951877f24 100644
--- a/clang/include/clang/ASTMatchers/ASTMatchersInternal.h
+++ b/clang/include/clang/ASTMatchers/ASTMatchersInternal.h
@@ -586,6 +586,10 @@ class Matcher {
   return this->InnerMatcher.matches(DynTypedNode::create(*Node), Finder,
 Builder);
 }
+
+llvm::Optional TraversalKind() const override {
+  return this->InnerMatcher.getTraversalKind();
+}
   };
 
 private:
@@ -1056,6 +1060,8 @@ class ASTMatchFinder {
 
   virtual ASTContext &getASTContext() const = 0;
 
+  virtual bool isMatchingInImplicitTemplateInstantiation() const = 0;
+
 protected:
   virtual bool matchesChildOf(const DynTypedNode &Node, ASTContext &Ctx,
   const DynTypedMatcher &Matcher,

diff  --git a/clang/lib/AST/ASTDumper.cpp b/clang/lib/AST/ASTDumper.cpp
index 284e5bdbc6b0..3d368a0a7b63 100644
--- a/clang/lib/AST/ASTDumper.cpp
+++ b/clang/lib/AST/ASTDumper.cpp
@@ -129,9 +129,11 @@ void ASTDumper::dumpTemplateDecl(const TemplateDecl *D, 
bool DumpExplicitInst) {
 
   Visit(D->getTemplatedDecl());
 
-  for (const auto *Child : D->specializations())
-dumpTemplateDeclSpecialization(Child, DumpExplicitInst,
-   !D->isCanonicalDecl());
+  if (GetTraversalKind() == TK_AsIs) {
+for (const auto *Child : D->specializations())
+  dumpTemplateDeclSpecialization(Child, DumpExplicitInst,
+ !D->isCanonicalDecl());
+  }
 }
 
 void ASTDumper::VisitFunctionTemplateDecl(const F

[clang] 09b54e2 - When re-checking an already-substituted template argument, don't lose

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2020-11-03T14:09:54-08:00
New Revision: 09b54e2799a11c6813796c70475d52e09898568b

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

LOG: When re-checking an already-substituted template argument, don't lose
the reference-ness of the parameter's type.

Added: 


Modified: 
clang/lib/Sema/SemaTemplateInstantiate.cpp
clang/test/SemaTemplate/temp_arg_nontype_cxx11.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaTemplateInstantiate.cpp 
b/clang/lib/Sema/SemaTemplateInstantiate.cpp
index d01189b42ed6..03670e2145c1 100644
--- a/clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -1593,7 +1593,7 @@ 
TemplateInstantiator::TransformSubstNonTypeTemplateParmExpr(
   ExprResult SubstReplacement = TransformExpr(E->getReplacement());
   if (SubstReplacement.isInvalid())
 return true;
-  QualType SubstType = TransformType(E->getType());
+  QualType SubstType = TransformType(E->getParameterType(getSema().Context));
   if (SubstType.isNull())
 return true;
   // The type may have been previously dependent and not now, which means we

diff  --git a/clang/test/SemaTemplate/temp_arg_nontype_cxx11.cpp 
b/clang/test/SemaTemplate/temp_arg_nontype_cxx11.cpp
index 460b6def5d6f..522835f33454 100644
--- a/clang/test/SemaTemplate/temp_arg_nontype_cxx11.cpp
+++ b/clang/test/SemaTemplate/temp_arg_nontype_cxx11.cpp
@@ -65,3 +65,15 @@ namespace PR42513 {
 
   void use() { f(); }
 }
+
+namespace ReferenceToConstexpr {
+  struct A { const char *str = "hello"; };
+  constexpr A a;
+  template struct B {
+static_assert(__builtin_strcmp(r.str, "hello") == 0, "");
+  };
+  template struct C {
+template void f(B, T) {}
+  };
+  void f(C ca) { ca.f({}, 0); }
+}



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

[PATCH] D90634: Implement Lambda Conversion Operators for All CCs for MSVC.

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

rsmith added inline comments.



Comment at: clang/lib/Sema/SemaLambda.cpp:1285
+  /// that someone who intentionally places 'thiscall' on the lambda call
+  /// operator will still get that overload, since we don't have the a way of
+  /// detecting the attribute by the time we get here.





Comment at: clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp:10
 void usage() {
   auto lambda = [](int i, float f, double d) CC { return i + f + d; };
 

Does lambda-to-function-pointer decay still work (eg, `+lambda` or `*lambda`)? 
It'd be good to test that, since it's a fairly common idiom.


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

https://reviews.llvm.org/D90634

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

[PATCH] D72184: [BPF] support atomic instructions

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song added inline comments.



Comment at: llvm/test/CodeGen/BPF/atomics_2.ll:124
+; CHECK: r0 = r2
+; CHECK: r0 = cmpxchg_64(r1 + 0, r0, r3)
+; CHECK: encoding: [0xdb,0x01,0x00,0x00,0xf1,0x03,0x00,0x00]

ast wrote:
> Looks like it's generating correct code without special handling in 
> ISelLowering. Nice. I wonder why x86 had to use it. Because of eflags, I 
> guess?
which specific x86 codes you are referring to?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72184

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

[PATCH] D90719: [DebugInfo] Modify ctor homing as workaround for unconstructed libcxx types

[Amy Huang via Phabricator via cfe-commits]

akhuang created this revision.
akhuang added reviewers: rnk, dblaikie.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
akhuang requested review of this revision.

There are some types in libcxx that are used but their constructors
are not called (__hash_node, __hash_value_type, __tree_node, __value_type),
which means that with constructor homing, the types are not complete.

This patch avoids using ctor homing if there are no constructors in
the class definition. So it'll mean we emit some extra debug info in places.

I also re-measured the size of object files in a clang build
-debug-info-kind=limited: 5568746k
-debug-info-kind=constructor: 2695028k

  after this patch: 2685607k

So they're ~10mb larger after this change, which is not too bad.

In terms of testing, in chromium (on windows) there's visualization for libcxx
types and all of those types are displayed correctly after this patch, so I
think that means all the STL types are getting emitted now.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90719

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-limited-ctor.cpp


Index: clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
===
--- clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
+++ clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
@@ -74,6 +74,14 @@
   auto func = [&]() {};
 }
 
+// Test that a class that otherwise should be subject to constructor homing
+// is not because its constructor isn't used in this translation unit.
+// CHECK-DAG: !DICompositeType({{.*}}name: "M",{{.*}}DIFlagTypePassByValue
+class M {
+  B b;
+};
+void f(M m) {}
+
 // Check that types are being added to retained types list.
 // CHECK-DAG: !DICompileUnit{{.*}}retainedTypes: ![[RETAINED:[0-9]+]]
 // CHECK-DAG: ![[RETAINED]] = {{.*}}![[C]]
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2300,7 +2300,16 @@
   if (isClassOrMethodDLLImport(RD))
 return false;
 
-  return !RD->isLambda() && !RD->isAggregate() &&
+  // Attempt to avoid using constructor homing if a class is used but for
+  // whatever reason is not constructed. Constructors are added to the class
+  // definition when used, so use the existence of constructors here as a
+  // heuristic.
+  bool HasCtor = false;
+  for (auto *Ctor : RD->ctors())
+if (!Ctor->isCopyOrMoveConstructor() && !Ctor->isDeleted())
+  HasCtor = true;
+
+  return HasCtor && !RD->isLambda() && !RD->isAggregate() &&
  !RD->hasTrivialDefaultConstructor() &&
  !RD->hasConstexprNonCopyMoveConstructor();
 }


Index: clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
===
--- clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
+++ clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
@@ -74,6 +74,14 @@
   auto func = [&]() {};
 }
 
+// Test that a class that otherwise should be subject to constructor homing
+// is not because its constructor isn't used in this translation unit.
+// CHECK-DAG: !DICompositeType({{.*}}name: "M",{{.*}}DIFlagTypePassByValue
+class M {
+  B b;
+};
+void f(M m) {}
+
 // Check that types are being added to retained types list.
 // CHECK-DAG: !DICompileUnit{{.*}}retainedTypes: ![[RETAINED:[0-9]+]]
 // CHECK-DAG: ![[RETAINED]] = {{.*}}![[C]]
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2300,7 +2300,16 @@
   if (isClassOrMethodDLLImport(RD))
 return false;
 
-  return !RD->isLambda() && !RD->isAggregate() &&
+  // Attempt to avoid using constructor homing if a class is used but for
+  // whatever reason is not constructed. Constructors are added to the class
+  // definition when used, so use the existence of constructors here as a
+  // heuristic.
+  bool HasCtor = false;
+  for (auto *Ctor : RD->ctors())
+if (!Ctor->isCopyOrMoveConstructor() && !Ctor->isDeleted())
+  HasCtor = true;
+
+  return HasCtor && !RD->isLambda() && !RD->isAggregate() &&
  !RD->hasTrivialDefaultConstructor() &&
  !RD->hasConstexprNonCopyMoveConstructor();
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90714: [clang]Fix length threshold for MicrosoftMangle md5 hash

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Test case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90714

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

[PATCH] D90719: [DebugInfo] Modify ctor homing as workaround for unconstructed libcxx types

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Does Chromium need this fixed in clang? Or if it were fixed in libc++ would 
that be adequate? (does Chromium's build need to work with old libc++s, or does 
it always build with a libc++ that matches the compiler? (in the latter case, a 
fix in libc++ would be as good as a fix in clang))


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90719

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

[PATCH] D89959: UBSAN: emit distinctive traps in trapping mode

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a reviewer: morehouse.
kcc added a comment.

did you consider approaches where the emitted code doesn't change, but the 
binary contains a debug-like metadata that corresponds to the trap instructions?
Matt (CC-ed) has a patch if this kind (for a different purpose) in the works .


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

https://reviews.llvm.org/D89959

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

[PATCH] D90704: [OpenMP] target nested `use_device_ptr() if()` and is_device_ptr trigger asserts

[Chi Chun Chen via Phabricator via cfe-commits]

cchen added a comment.

In D90704#2372303 , @ABataev wrote:

> It would be good if you could identify the object which leads to a crash, I 
> mean a target region, variable, etc.



   1void
   2add_one(float *b, int dm)
   3{
   4#pragma omp target data map(tofrom:b[:1]) use_device_ptr(b) if (dm)
   5  {
   6#pragma omp target is_device_ptr(b)
   7  {
   8b[0] += 1;
   9  }
  10  }
  11}

The code crashes at line 6. Below is the information I dumped from 
`registerTargetRegionEntryInfo`. (DeviceID, FileID, ParentName, LineNum, Addr, 
ID)

  DeviceID: 16777220, FileID 38814071, ParentName add_one, LineNum: 6
  Addr:
  ; Function Attrs: noinline norecurse nounwind optnone ssp uwtable
  define internal void @__omp_offloading_104_2504177_add_one_l6(float* %b) 
#2 {
  entry:
%b.addr = alloca float*, align 8
store float* %b, float** %b.addr, align 8
%0 = load float*, float** %b.addr, align 8
%arrayidx = getelementptr inbounds float, float* %0, i64 0
%1 = load float, float* %arrayidx, align 4
%add = fadd float %1, 1.00e+00
store float %add, float* %arrayidx, align 4
ret void
  }
  
  ID:
  @.__omp_offloading_104_2504177_add_one_l6.region_id = weak constant i8 0

I found that both the `BeginThenGen` lambda and `BeginElseGen` lambda calls 
`registerTargetRegionEntryInfo` and both do

  OffloadEntryInfoTargetRegion Entry(OffloadingEntriesNum, Addr, ID, Flags);
  OffloadEntriesTargetRegion[DeviceID][FileID][ParentName][LineNum] = Entry;
  OffloadingEntriesNum++;

Which will lead to out-of-bounds access in 
`createOffloadEntriesAndInfoMetadata` since OffloadingEntriessNum is increased 
even if the size of `OffloadEntriesTargetRegion` is not increased.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90704

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

[PATCH] D90719: [DebugInfo] Modify ctor homing as workaround for unconstructed libcxx types

[Amy Huang via Phabricator via cfe-commits]

akhuang added a comment.

No, chromium doesn't need this fixed in clang, but I didn't see a clear way to 
fix this in libc++. Do you think it should be fixed as a bug in libc++?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90719

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

[PATCH] D90719: [DebugInfo] Modify ctor homing as workaround for unconstructed libcxx types

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a subscriber: EricWF.
rnk added a comment.

In D90719#2372463 , @dblaikie wrote:

> Does Chromium need this fixed in clang? Or if it were fixed in libc++ would 
> that be adequate? (does Chromium's build need to work with old libc++s, or 
> does it always build with a libc++ that matches the compiler? (in the latter 
> case, a fix in libc++ would be as good as a fix in clang))

Well, we'd like to make this new type homing behavior the default, and it 
wouldn't work with old libc++ versions, and there is the general possibility 
that there is code out there like this libc++ code that has implicit nontrivial 
constructors that are not used. So, I wouldn't think so much about what's right 
for Chrome, and more about what's right for Clang.

If we do want to fix libc++, I'd warn you that the code is subtle. It takes 
care to construct the node value in a particular way, and it sets a flag after 
construction succeeds, which perhaps affects exception safety:
https://github.com/llvm/llvm-project/blob/master/libcxx/include/__hash_table#L2456
+ @EricWF


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90719

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

[PATCH] D89936: [clang-tidy] adding "--config-file=" to specify custom config file.

[Hiral via Phabricator via cfe-commits]

Hiralo added a comment.

Hello @DmitryPolukhin ,
Sorry I missed to update 'SUMMARY' section of this review earlier! was not 
aware that that will be considered as commit message.
I have now updated the 'SUMMARY', it is possible to revert this commit and then 
re-submit it with updated commit message?
I think latest commit message reflects and provides details about usage and 
helpful to people.
Sorry for inconvenience caused!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89936

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

[PATCH] D90275: [clang][IR] Add support for leaf attribute

[Gulfem Savrun Yeniceri via Phabricator via cfe-commits]

gulfem updated this revision to Diff 302716.
gulfem added a comment.

Add a target into the test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/attr-leaf.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/attr-leaf.c
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Bitcode/attributes.ll

Index: llvm/test/Bitcode/attributes.ll
===
--- llvm/test/Bitcode/attributes.ll
+++ llvm/test/Bitcode/attributes.ll
@@ -410,6 +410,12 @@
   ret void
 }
 
+; CHECK; define void @f70() #43
+define void @f70() nocallback
+{
+  ret void
+}
+
 ; CHECK: attributes #0 = { noreturn }
 ; CHECK: attributes #1 = { nounwind }
 ; CHECK: attributes #2 = { readnone }
@@ -453,4 +459,5 @@
 ; CHECK: attributes #40 = { null_pointer_is_valid }
 ; CHECK: attributes #41 = { mustprogress }
 ; CHECK: attributes #42 = { nossp }
+; CHECK: attributes #43 = { nocallback }
 ; CHECK: attributes #[[NOBUILTIN]] = { nobuiltin }
Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
===
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp
@@ -906,6 +906,7 @@
   case Attribute::NoRecurse:
   case Attribute::InlineHint:
   case Attribute::MinSize:
+  case Attribute::NoCallback:
   case Attribute::NoDuplicate:
   case Attribute::NoFree:
   case Attribute::NoImplicitFloat:
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1572,6 +1572,7 @@
   case Attribute::NoReturn:
   case Attribute::NoSync:
   case Attribute::WillReturn:
+  case Attribute::NoCallback:
   case Attribute::NoCfCheck:
   case Attribute::NoUnwind:
   case Attribute::NoInline:
Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -371,6 +371,8 @@
 return "noalias";
   if (hasAttribute(Attribute::NoBuiltin))
 return "nobuiltin";
+  if (hasAttribute(Attribute::NoCallback))
+return "nocallback";
   if (hasAttribute(Attribute::NoCapture))
 return "nocapture";
   if (hasAttribute(Attribute::NoDuplicate))
Index: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -643,6 +643,8 @@
 return bitc::ATTR_KIND_NO_ALIAS;
   case Attribute::NoBuiltin:
 return bitc::ATTR_KIND_NO_BUILTIN;
+  case Attribute::NoCallback:
+return bitc::ATTR_KIND_NO_CALLBACK;
   case Attribute::NoCapture:
 return bitc::ATTR_KIND_NO_CAPTURE;
   case Attribute::NoDuplicate:
Index: llvm/lib/Bitcode/Reader/BitcodeReader.cpp
===
--- llvm/lib/Bitcode/Reader/BitcodeReader.cpp
+++ llvm/lib/Bitcode/Reader/BitcodeReader.cpp
@@ -1433,6 +1433,8 @@
 return Attribute::NoAlias;
   case bitc::ATTR_KIND_NO_BUILTIN:
 return Attribute::NoBuiltin;
+  case bitc::ATTR_KIND_NO_CALLBACK:
+return Attribute::NoCallback;
   case bitc::ATTR_KIND_NO_CAPTURE:
 return Attribute::NoCapture;
   case bitc::ATTR_KIND_NO_DUPLICATE:
Index: llvm/lib/AsmParser/LLToken.h
===
--- llvm/lib/AsmParser/LLToken.h
+++ llvm/lib/AsmParser/LLToken.h
@@ -198,6 +198,7 @@
   kw_noalias,
   kw_noundef,
   kw_nobuiltin,
+  kw_nocallback,
   kw_nocapture,
   kw_noduplicate,
   kw_nofree,
Index: llvm/lib/AsmParser/LLParser.cpp
===
--- llvm/lib/AsmParser/LLParser.cpp
+++ llvm/lib/AsmParser/LLParser.cpp
@@ -1314,6 +1314,9 @@
   break;
 case lltok::kw_naked: B.addAttribute(Attribute::Naked); break;
 case lltok::kw_nobuiltin: B.addAttribute(Attribute::NoBuiltin); break;
+case lltok::kw_nocallback:
+  B.addAttribute(Attribute::NoCallback);
+  break;
 case lltok::kw_noduplicate: B.addAttribute(Attribute::NoDuplicate); break;
 case lltok::kw_nofree: B.addAttribute(Attribute::NoFree); break;
 case lltok::kw_noimplicitfloat:
Index: llvm/lib/AsmParser/LLLexer.cpp
===
--- llvm/lib/Asm

[PATCH] D90275: [clang][IR] Add support for leaf attribute

[Gulfem Savrun Yeniceri via Phabricator via cfe-commits]

gulfem added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:3910
+in library functions. Functions marked with the ``leaf`` attribute are not 
allowed
+to jump back into the caller's translation unit, whether through invoking a
+callback function, a direct external function call, use of ``longjmp``, or 
other means.

aaron.ballman wrote:
> gulfem wrote:
> > I think this property is transitive. 
> > If a leaf function somehow enters into caller's translation unit (either 
> > via direct call or a via its call chain), it will violate the rule that 
> > says "Calls to external functions with this attribute must return to the 
> > current compilation unit only by return or by exception handling". 
> > Entering via its call chain is not a return or an exception handling.
> > Do you agree with that?
> > I think this property is transitive. ... Do you agree with that?
> 
> That makes sense to me! I think I'd recommend a slight modification to the 
> docs then:
> 
> ```
> Functions marked with the ``leaf`` attribute are not allowed to jump back 
> into the caller's translation unit, whether through invoking a callback 
> function, a direct, possibly transitive, external function call, use of 
> ``longjmp``, or other means.
> ```
> The last question is: by "direct" does the GCC docs imply that calls back to 
> the caller's TU through a function *pointer* are not UB? I'd imagine those 
> would also be bad, but I'd like to make sure (and perhaps we can remove the 
> `direct` from the wording if calls through function pointers are disallowed).
I think the idea is that the control-flow should never come back to the 
caller's translation unit by any kind of control-flow changing mechanism 
(direct/indirect and call/jump).
The compiler might use this hint to do optimizations based on that assumption, 
so the user should ensure that.
Could you please explain what do you mean by calling back via function pointer?
I thought that callback function is basically calling back via a function 
pointer. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

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

[PATCH] D90682: [clangd][NFC] Make Located::operator->() use pointer sematics

[Nathan James via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcb9d0e8819ad: [clangd][NFC] Make Located::operator->() 
use pointer sematics (authored by njames93).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90682

Files:
  clang-tools-extra/clangd/ConfigFragment.h


Index: clang-tools-extra/clangd/ConfigFragment.h
===
--- clang-tools-extra/clangd/ConfigFragment.h
+++ clang-tools-extra/clangd/ConfigFragment.h
@@ -51,8 +51,8 @@
   : Range(Range), Value(std::move(Value)) {}
 
   llvm::SMRange Range;
-  T &operator->() { return Value; }
-  const T &operator->() const { return Value; }
+  T *operator->() { return &Value; }
+  const T *operator->() const { return &Value; }
   T &operator*() { return Value; }
   const T &operator*() const { return Value; }
 


Index: clang-tools-extra/clangd/ConfigFragment.h
===
--- clang-tools-extra/clangd/ConfigFragment.h
+++ clang-tools-extra/clangd/ConfigFragment.h
@@ -51,8 +51,8 @@
   : Range(Range), Value(std::move(Value)) {}
 
   llvm::SMRange Range;
-  T &operator->() { return Value; }
-  const T &operator->() const { return Value; }
+  T *operator->() { return &Value; }
+  const T *operator->() const { return &Value; }
   T &operator*() { return Value; }
   const T &operator*() const { return Value; }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] cb9d0e8 - [clangd][NFC] Make Located::operator->() use pointer sematics

[Nathan James via cfe-commits]

Author: Nathan James
Date: 2020-11-04T01:36:14Z
New Revision: cb9d0e8819ad7ca2f349a57d62ea2af02d631dfa

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

LOG: [clangd][NFC] Make Located::operator->() use pointer sematics

This enables using the arrow operator to access members of the contained item.
```lang=c++
Located X;
const char* CStr = X->c_str();
```
This is inline with how classes like `Optional` handle the arrow operator.

Reviewed By: kadircet

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

Added: 


Modified: 
clang-tools-extra/clangd/ConfigFragment.h

Removed: 




diff  --git a/clang-tools-extra/clangd/ConfigFragment.h 
b/clang-tools-extra/clangd/ConfigFragment.h
index 7e07e9d065b3..65772715095f 100644
--- a/clang-tools-extra/clangd/ConfigFragment.h
+++ b/clang-tools-extra/clangd/ConfigFragment.h
@@ -51,8 +51,8 @@ template  struct Located {
   : Range(Range), Value(std::move(Value)) {}
 
   llvm::SMRange Range;
-  T &operator->() { return Value; }
-  const T &operator->() const { return Value; }
+  T *operator->() { return &Value; }
+  const T *operator->() const { return &Value; }
   T &operator*() { return Value; }
   const T &operator*() const { return Value; }
 



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

LLVM buildmaster will be restarted tonight

[Galina Kistanova via cfe-commits]

 Hello everyone,

LLVM buildmaster will be restarted after 6pm PST.

Thanks

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

[PATCH] D90719: [DebugInfo] Modify ctor homing as workaround for unconstructed libcxx types

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D90719#2372554 , @rnk wrote:

> In D90719#2372463 , @dblaikie wrote:
>
>> Does Chromium need this fixed in clang? Or if it were fixed in libc++ would 
>> that be adequate? (does Chromium's build need to work with old libc++s, or 
>> does it always build with a libc++ that matches the compiler? (in the latter 
>> case, a fix in libc++ would be as good as a fix in clang))
>
> Well, we'd like to make this new type homing behavior the default, and it 
> wouldn't work with old libc++ versions, and there is the general possibility 
> that there is code out there like this libc++ code that has implicit 
> nontrivial constructors that are not used. So, I wouldn't think so much about 
> what's right for Chrome, and more about what's right for Clang.

My understanding is that such code is UB, is that right? - if libc++ was 
threading some needle/depending on some agreed upon Clang guarantee (even if it 
was a secret handshake only for libc++) then I'd be more in favor of the "we 
have to/should support it" but as it seems to stand, I'm inclined towards 
addressing this by fixing libc++ unless there's evidence of a pervasive 
dependence on this UB.

> If we do want to fix libc++, I'd warn you that the code is subtle. It takes 
> care to construct the node value in a particular way, and it sets a flag 
> after construction succeeds, which perhaps affects exception safety:
> https://github.com/llvm/llvm-project/blob/master/libcxx/include/__hash_table#L2456
> + @EricWF

Yeah, +1 on getting @EricWF's take on this for sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90719

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

[PATCH] D90634: Implement Lambda Conversion Operators for All CCs for MSVC.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp:10
 void usage() {
   auto lambda = [](int i, float f, double d) CC { return i + f + d; };
 

rsmith wrote:
> Does lambda-to-function-pointer decay still work (eg, `+lambda` or 
> `*lambda`)? It'd be good to test that, since it's a fairly common idiom.
It does! I tested that in the last patch, but don't seem to have a codegen test 
for it, so I'll make sure to add it.

I ended up having to do a tiebreaker as you suggested in that patch as well.


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

https://reviews.llvm.org/D90634

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

[PATCH] D90275: [clang][IR] Add support for leaf attribute

[Roland McGrath via Phabricator via cfe-commits]

mcgrathr added a comment.

The GCC documentation specifically gives the example of the standard C function 
`qsort` as one that does not qualify as `__attribute__((leaf))` because it uses 
a callback function (that presumably might be from the caller's own TU).  AIUI 
the claim the attribute makes is that no normal control flow (i.e. excluding 
only signal handlers) would call any function in the caller's TU by any means, 
nor `longjmp` to any state captured by a `setjmp` call in the caller's TU, and 
thus only normal return or normal C++ exception handling return/unwind would 
reach the caller's TU again after the jump (call) to this entry point.  The 
caller is thus presumed not to share potentially-called functions with the 
callee by any means, whether direct symbol references or function pointers 
passed in the call or function pointers previously stored somewhere (e.g. a C++ 
vtable).  The compiler can make whatever assumptions about potential 
dataflow/side-effect and the like are implied by this exclusion of TU-local 
code paths from the otherwise unknown call graph of the external call.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

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

[PATCH] D90733: Frontend: Sink named pipe logic from CompilerInstance down to FileManager

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith created this revision.
dexonsmith added reviewers: arphaman, JDevlieghere.
Herald added a subscriber: ributzka.
dexonsmith requested review of this revision.

Remove compilicated logic from CompilerInstance::InitializeSourceManager
to deal with named pipes, updating  FileManager::getBufferForFile to
handle it in a more straightforward way.  The existing test at
clang/test/Misc/dev-fd-fs.c covers the new behaviour.


https://reviews.llvm.org/D90733

Files:
  clang/lib/Basic/FileManager.cpp
  clang/lib/Frontend/CompilerInstance.cpp


Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -856,30 +856,8 @@
 }
 FileEntryRef File = *FileOrErr;
 
-// The natural SourceManager infrastructure can't currently handle named
-// pipes, but we would at least like to accept them for the main
-// file. Detect them here, read them with the volatile flag so FileMgr will
-// pick up the correct size, and simply override their contents as we do 
for
-// STDIN.
-if (File.getFileEntry().isNamedPipe()) {
-  auto MB =
-  FileMgr.getBufferForFile(&File.getFileEntry(), /*isVolatile=*/true);
-  if (MB) {
-// Create a new virtual file that will have the correct size.
-const FileEntry *FE =
-FileMgr.getVirtualFile(InputFile, (*MB)->getBufferSize(), 0);
-SourceMgr.overrideFileContents(FE, std::move(*MB));
-SourceMgr.setMainFileID(
-SourceMgr.createFileID(FE, SourceLocation(), Kind));
-  } else {
-Diags.Report(diag::err_cannot_open_file) << InputFile
- << MB.getError().message();
-return false;
-  }
-} else {
-  SourceMgr.setMainFileID(
-  SourceMgr.createFileID(File, SourceLocation(), Kind));
-}
+SourceMgr.setMainFileID(
+SourceMgr.createFileID(File, SourceLocation(), Kind));
   } else {
 llvm::ErrorOr> SBOrErr =
 llvm::MemoryBuffer::getSTDIN();
Index: clang/lib/Basic/FileManager.cpp
===
--- clang/lib/Basic/FileManager.cpp
+++ clang/lib/Basic/FileManager.cpp
@@ -489,7 +489,7 @@
   uint64_t FileSize = Entry->getSize();
   // If there's a high enough chance that the file have changed since we
   // got its size, force a stat before opening it.
-  if (isVolatile)
+  if (isVolatile || Entry->isNamedPipe())
 FileSize = -1;
 
   StringRef Filename = Entry->getName();


Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -856,30 +856,8 @@
 }
 FileEntryRef File = *FileOrErr;
 
-// The natural SourceManager infrastructure can't currently handle named
-// pipes, but we would at least like to accept them for the main
-// file. Detect them here, read them with the volatile flag so FileMgr will
-// pick up the correct size, and simply override their contents as we do for
-// STDIN.
-if (File.getFileEntry().isNamedPipe()) {
-  auto MB =
-  FileMgr.getBufferForFile(&File.getFileEntry(), /*isVolatile=*/true);
-  if (MB) {
-// Create a new virtual file that will have the correct size.
-const FileEntry *FE =
-FileMgr.getVirtualFile(InputFile, (*MB)->getBufferSize(), 0);
-SourceMgr.overrideFileContents(FE, std::move(*MB));
-SourceMgr.setMainFileID(
-SourceMgr.createFileID(FE, SourceLocation(), Kind));
-  } else {
-Diags.Report(diag::err_cannot_open_file) << InputFile
- << MB.getError().message();
-return false;
-  }
-} else {
-  SourceMgr.setMainFileID(
-  SourceMgr.createFileID(File, SourceLocation(), Kind));
-}
+SourceMgr.setMainFileID(
+SourceMgr.createFileID(File, SourceLocation(), Kind));
   } else {
 llvm::ErrorOr> SBOrErr =
 llvm::MemoryBuffer::getSTDIN();
Index: clang/lib/Basic/FileManager.cpp
===
--- clang/lib/Basic/FileManager.cpp
+++ clang/lib/Basic/FileManager.cpp
@@ -489,7 +489,7 @@
   uint64_t FileSize = Entry->getSize();
   // If there's a high enough chance that the file have changed since we
   // got its size, force a stat before opening it.
-  if (isVolatile)
+  if (isVolatile || Entry->isNamedPipe())
 FileSize = -1;
 
   StringRef Filename = Entry->getName();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90392: [clang-tidy] Omit std::make_unique/make_shared for default initialization.

[Chris Kennelly via Phabricator via cfe-commits]

ckennelly updated this revision to Diff 302731.
ckennelly added a comment.

Expand tests to cover value and default initialization


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90392

Files:
  clang-tools-extra/clang-tidy/modernize/MakeSmartPtrCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/modernize-make-shared.cpp
  clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp
@@ -83,49 +83,60 @@
   // CHECK-FIXES: return std::make_unique();
 }
 
+std::unique_ptr getPointerValue() {
+  return std::unique_ptr(new Base());
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: use std::make_unique instead
+  // CHECK-FIXES: return std::make_unique();
+}
+
 void basic() {
   std::unique_ptr P1 = std::unique_ptr(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: std::unique_ptr P1 = std::make_unique();
+  std::unique_ptr P2 = std::unique_ptr(new int);
 
   P1.reset(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: P1 = std::make_unique();
+  P2.reset(new int);
 
   P1 = std::unique_ptr(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: P1 = std::make_unique();
+  P1 = std::unique_ptr(new int);
 
-  // Without parenthesis.
-  std::unique_ptr P2 = std::unique_ptr(new int);
-  // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_unique instead [modernize-make-unique]
-  // CHECK-FIXES: std::unique_ptr P2 = std::make_unique();
+  // Without parenthesis, default initialization.
+  std::unique_ptr P3 = std::unique_ptr(new int);
 
   P2.reset(new int);
-  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use std::make_unique instead [modernize-make-unique]
-  // CHECK-FIXES: P2 = std::make_unique();
 
   P2 = std::unique_ptr(new int);
-  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use std::make_unique instead [modernize-make-unique]
-  // CHECK-FIXES: P2 = std::make_unique();
 
   // With auto.
-  auto P3 = std::unique_ptr(new int());
+  auto P4 = std::unique_ptr(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use std::make_unique instead
-  // CHECK-FIXES: auto P3 = std::make_unique();
+  // CHECK-FIXES: auto P4 = std::make_unique();
+  auto P5 = std::unique_ptr(new int);
 
-  std::unique_ptr P4 = std::unique_ptr((new int));
+  std::unique_ptr P6 = std::unique_ptr((new int()));
   // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_unique instead [modernize-make-unique]
-  // CHECK-FIXES: std::unique_ptr P4 = std::make_unique();
-  P4.reset((new int));
+  // CHECK-FIXES: std::unique_ptr P6 = std::make_unique();
+  std::unique_ptr P7 = std::unique_ptr((new int));
+
+  P4.reset((new int()));
   // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: P4 = std::make_unique();
-  std::unique_ptr P5 = std::unique_ptrnew int;
+  P5.reset((new int));
+
+  std::unique_ptr P8 = std::unique_ptrnew int();
   // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_unique instead [modernize-make-unique]
-  // CHECK-FIXES: std::unique_ptr P5 = std::make_unique();
-  P5.reset(new int);
+  // CHECK-FIXES: std::unique_ptr P8 = std::make_unique();
+  std::unique_ptr P9 = std::unique_ptrnew int;
+
+  P5.reset(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: P5 = std::make_unique();
+  P6.reset(new int);
 
   {
 // No std.
@@ -133,40 +144,55 @@
 unique_ptr Q = unique_ptr(new int());
 // CHECK-MESSAGES: :[[@LINE-1]]:25: warning: use std::make_unique instead
 // CHECK-FIXES: unique_ptr Q = std::make_unique();
+unique_ptr P = unique_ptr(new int);
 
 Q = unique_ptr(new int());
 // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: use std::make_unique instead
 // CHECK-FIXES: Q = std::make_unique();
+
+P = unique_ptr(new int);
   }
 
   std::unique_ptr R(new int());
+  std::unique_ptr S(new int);
 
   // Create the unique_ptr as a parameter to a function.
   int T = g(std::unique_ptr(new int()));
   // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use std::make_unique instead
   // CHECK-FIXES: int T = g(std::make_unique());
+  T = g(std::unique_ptr(new int));
 
   // Only replace if the type in the template is the same as the type returned
   // by the new operator.
   auto Pderived = std::unique_ptr(new Derived());
+  auto PderivedNoparen = std::unique_ptr(new Derived);
 
   // OK to replace 

[PATCH] D90188: Add support for attribute 'using_if_exists'

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington updated this revision to Diff 302733.
erik.pilkington marked 20 inline comments as done.
erik.pilkington added a comment.

Address review comments, thanks!


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

https://reviews.llvm.org/D90188

Files:
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DeclNodes.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/SemaCXX/attr-deprecated.cpp
  clang/test/SemaCXX/using-if-exists-attr.cpp
  clang/test/SemaCXX/using-if-exists.cpp
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -6411,6 +6411,7 @@
   case Decl::Concept:
   case Decl::LifetimeExtendedTemporary:
   case Decl::RequiresExprBody:
+  case Decl::UnresolvedUsingIfExists:
 return C;
 
   // Declaration kinds that don't make any sense here, but are
Index: clang/test/SemaCXX/using-if-exists.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/using-if-exists.cpp
@@ -0,0 +1,193 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only %s -verify
+
+#define UIE __attribute__((using_if_exists))
+
+namespace test_basic {
+namespace NS {}
+
+using NS::x UIE; // expected-note{{using declaration annotated with 'using_if_exists' here}}
+x usex(); // expected-error{{reference to unresolved using declaration}}
+
+using NotNS::x UIE; // expected-error{{use of undeclared identifier 'NotNS'}}
+} // test_basic
+
+namespace test_redecl {
+namespace NS {}
+
+using NS::x UIE;
+using NS::x UIE;
+
+namespace NS1 {}
+namespace NS2 {}
+namespace NS3 {
+int A(); // expected-note{{target of using declaration}}
+struct B {}; // expected-note{{target of using declaration}}
+int C(); // expected-note{{conflicting declaration}}
+struct D {}; // expected-note{{conflicting declaration}}
+}
+
+using NS1::A UIE;
+using NS2::A UIE; // expected-note{{using declaration annotated with 'using_if_exists' here}} expected-note{{conflicting declaration}}
+using NS3::A UIE; // expected-error{{target of using declaration conflicts with declaration already in scope}}
+int i = A(); // expected-error{{reference to unresolved using declaration}}
+
+using NS1::B UIE;
+using NS2::B UIE; // expected-note{{conflicting declaration}} expected-note{{using declaration annotated with 'using_if_exists' here}}
+using NS3::B UIE; // expected-error{{target of using declaration conflicts with declaration already in scope}}
+B myB; // expected-error{{reference to unresolved using declaration}}
+
+using NS3::C UIE;
+using NS2::C UIE; // expected-error{{target of using declaration conflicts with declaration already in scope}} expected-note{{target of using declaration}}
+int j = C();
+
+using NS3::D UIE;
+using NS2::D UIE; // expected-error{{target of using declaration conflicts with declaration already in scope}} expected-note{{target of using declaration}}
+D myD;
+} // test_redecl
+
+namespace test_dependent {
+template 
+struct S : B {
+  using B::mf UIE; // expected-note 3 {{using declaration annotated with 'using_if_exists' here}}
+  using typename B::mt UIE; // expected-note{{using declaration annotated with 'using_if_exists' here}}
+};
+
+struct BaseEmpty {
+};
+struct BaseNonEmpty {
+  void mf();
+  typedef int mt;
+};
+
+void f() {
+  S empty;
+  S nonempty;
+  empty.mf(); // expected-error {{reference to unresolved using declaration}}
+  nonempty.mf();
+  (&empty)->mf(); // expected-error {{reference to unresolved using declaration}}
+  (&nonempty)->mf();
+
+  S::mt y; // expected-error {{reference to unresolved using declaration}}
+  S::mt z;
+
+  S::mf(); // expected-error {{reference to unresolved using declaration}}
+}
+
+template 
+struct Implicit : B {
+  using B::mf UIE; // expected-note {{using declaration annotated with 'using_if_exists' here}}
+  using typename B::mt UIE; // expected-note 2 {{using declaration annotated with 'using_if_exists' here}}
+
+  void use() {
+mf(); // expected-error {{reference to unresolved using declaration}}
+mt x; // expected-error {{reference to unresolved using declaration}}
+  }
+
+  mt alsoUse(); // expected-error {{reference to unresolved using declaration}}
+};
+
+void testImplicit() {
+  Implicit nonempty;
+  Impl

[PATCH] D90188: Add support for attribute 'using_if_exists'

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington added inline comments.



Comment at: clang/include/clang/AST/DeclCXX.h:3801
+/// error.
+class UnresolvedUsingIfExistsDecl final : public NamedDecl {
+  UnresolvedUsingIfExistsDecl(DeclContext *DC, SourceLocation Loc,

aaron.ballman wrote:
> Why is this inheriting from a `NamedDecl` rather than a `UsingDecl`? Given 
> that this is a type of using declaration, I guess I would have expected it to 
> appear as such in the AST hierarchy. For instance, should people using AST 
> matchers be able to match one of these as a using declaration or are they so 
> different semantically that they need to be sibling AST nodes?
This node isn't a kind of using declaration, it is a declaration that gets 
inserted into the scope via a usual UsingDecl & UsingShadowDecl mechanism that 
Sema knows to error out on if it is ever used. So presumably existing AST users 
would still recognize that this is a UsingDecl that adds a single declaration 
into the current context, but wouldn't really know anything about that 
declaration. I updated the doc comment above to make that more clear.



Comment at: clang/include/clang/Basic/AttrDocs.td:5273
+  namespace empty_namespace {};
+  using empty_namespace::does_not_exist __attribute__((using_if_exists)); // 
no error!
+

Mordante wrote:
> Mordante wrote:
> > Can you add an example using `[[clang::using_if_exists]]` or use that 
> > instead of this attribute?
> Why is the attribute placed here? I would expect the attribute before the 
> declaration `[[clang::using_if_exists]] using 
> empty_namespace::does_not_exist;`
The attribute is written like that because clang rejects C++ style attributes 
on using declarations, and only accepts attributes in that position. I think 
this is the first attribute we actually support on using-declarations, so maybe 
we should consider supporting it.



Comment at: clang/lib/Sema/SemaDecl.cpp:440-441
+RealRes = ShadowD->getTargetDecl();
+  if (isa(RealRes) || isa(RealRes) ||
+  isa(RealRes) ||
+  (AllowDeducedTemplate && getAsTypeTemplateDecl(RealRes))) {

rsmith wrote:
> 
Huh, didn't know `isa` did that!



Comment at: clang/lib/Sema/SemaDecl.cpp:500
+// Recover with 'int'
+T = Context.IntTy;
   } else if (AllowDeducedTemplate) {

rsmith wrote:
> Mordante wrote:
> > Why do you want recover instead of returning a `nullptr`?
> I agree. Producing `IntTy` here is liable to result in follow-on diagnostics. 
> It seems better to tell downstream code that you found a non-type. Can you 
> remove this special case entirely?
Hmm, removing this case seems to result in worse diagnostics. For instance, 
here:
```
using NS::X __attribute__((using_if_exists));
X y;
```

If we remove this check and let `getTypeName()` just return nullptr on `X`, 
then the parser just emits a generic "unknown type name `X`" diagnostic. This 
is the only place in that path where lookup is done on X, so ISTM like the 
place where we should be checking this.

If we don't recover with some type, then the parser will sometimes assume that 
this is unworkable as a type, and attempt to recover by parsing it as something 
else, which can lead to duplicate diagnostics. e.g., here: `int i = X();`

I guess we could make `getTypeName()` return an `Optional` that 
indicated to callers that they should assume that the name was a type, even if 
it can't be represented by a type node. That seems a little heavy-handed 
though. WDYT?



Comment at: clang/lib/Sema/SemaDecl.cpp:1177
 
+  if (auto *EmptyD = dyn_cast(FirstDecl)) {
+Diag(NameLoc, diag::err_use_of_empty_using_if_exists);

aaron.ballman wrote:
> `const auto *`
This would lead to a bit of a `const`-goosechase in DiagnoseUseOfDecl. I 
thought we generally weren't too interested in `const` on AST nodes since 
they're assumed to be immutable anyways, so it doesn't really show much intent.



Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:3195-3196
+UnresolvedUsingIfExistsDecl *D) {
+  return UnresolvedUsingIfExistsDecl::Create(
+  SemaRef.Context, Owner, D->getLocation(), D->getDeclName());
+}

rsmith wrote:
> Is this reachable? I'd expect the only way we can see these is via the list 
> of shadow declarations of the `UsingDecl`, so we should never try to 
> instantiate one by itself.
Yeah, this is unreachable. I added a `llvm_unreachable`.



Comment at: clang/lib/Sema/TreeTransform.h:14115-14123
+NamedDecl *Target = Using->shadow_begin()->getTargetDecl();
+if (auto *EmptyD = dyn_cast(Target)) {
+  getSema().Diag(Loc, diag::err_use_of_empty_using_if_exists);
+  getSema().Diag(EmptyD->getLocation(),
+ diag::note_empty_using_if_exists_here);
+  return QualType();
+}

rsmith wrote:
> We should `DiagnoseUseOfD

[PATCH] D87981: [X86] AMX programming model prototype.

[LuoYuanke via Phabricator via cfe-commits]

LuoYuanke updated this revision to Diff 302738.
LuoYuanke added a comment.

Removed tilezero support in this patch.
Fixed some bugs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87981

Files:
  clang/include/clang/Basic/BuiltinsX86_64.def
  clang/lib/Headers/amxintrin.h
  clang/test/CodeGen/X86/amx_api.c
  llvm/include/llvm/CodeGen/LiveIntervalUnion.h
  llvm/include/llvm/CodeGen/LiveRegMatrix.h
  llvm/include/llvm/CodeGen/Passes.h
  llvm/include/llvm/CodeGen/TileShapeInfo.h
  llvm/include/llvm/CodeGen/VirtRegMap.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/include/llvm/IR/IntrinsicsX86.td
  llvm/lib/CodeGen/InlineSpiller.cpp
  llvm/lib/CodeGen/LiveIntervalUnion.cpp
  llvm/lib/CodeGen/LiveRegMatrix.cpp
  llvm/lib/CodeGen/VirtRegMap.cpp
  llvm/lib/Target/X86/CMakeLists.txt
  llvm/lib/Target/X86/X86.h
  llvm/lib/Target/X86/X86ExpandPseudo.cpp
  llvm/lib/Target/X86/X86ISelDAGToDAG.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86InstrAMX.td
  llvm/lib/Target/X86/X86InstrInfo.cpp
  llvm/lib/Target/X86/X86LowerAMXType.cpp
  llvm/lib/Target/X86/X86PreTileConfig.cpp
  llvm/lib/Target/X86/X86RegisterInfo.cpp
  llvm/lib/Target/X86/X86RegisterInfo.h
  llvm/lib/Target/X86/X86RegisterInfo.td
  llvm/lib/Target/X86/X86Subtarget.h
  llvm/lib/Target/X86/X86TargetMachine.cpp
  llvm/lib/Target/X86/X86TileConfig.cpp
  llvm/test/CodeGen/X86/AMX/amx-across-func.ll
  llvm/test/CodeGen/X86/AMX/amx-config.ll
  llvm/test/CodeGen/X86/AMX/amx-spill.ll
  llvm/test/CodeGen/X86/AMX/amx-type.ll
  llvm/test/CodeGen/X86/O0-pipeline.ll
  llvm/test/CodeGen/X86/ipra-reg-usage.ll
  llvm/test/CodeGen/X86/opt-pipeline.ll
  llvm/test/CodeGen/X86/statepoint-fixup-invoke.mir
  llvm/test/CodeGen/X86/statepoint-fixup-shared-ehpad.mir

Index: llvm/test/CodeGen/X86/statepoint-fixup-shared-ehpad.mir
===
--- llvm/test/CodeGen/X86/statepoint-fixup-shared-ehpad.mir
+++ llvm/test/CodeGen/X86/statepoint-fixup-shared-ehpad.mir
@@ -108,7 +108,7 @@
   ; CHECK:   ADJCALLSTACKDOWN64 0, 0, 0, implicit-def dead $rsp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp
   ; CHECK:   MOV64mr [[STACK0:%stack.[0-9]+]], 1, $noreg, 0, $noreg, killed $rbx :: (store 8 into [[STACK0]])
   ; CHECK:   MOV64mr [[STACK1:%stack.[0-9]+]], 1, $noreg, 0, $noreg, killed $r14 :: (store 8 into [[STACK1]])
-  ; CHECK:   STATEPOINT 0, 0, 0, @foo, 2, 0, 2, 0, 2, 0, 2, 2, 1, 8, [[STACK0]], 0, 1, 8, [[STACK1]], 0, 2, 0, 2, 2, 0, 0, 1, 1, csr_64, implicit-def $rsp, implicit-def $ssp :: (load store 8 on [[STACK0]]), (load store 8 on [[STACK1]])
+  ; CHECK:   STATEPOINT 0, 0, 0, @foo, 2, 0, 2, 0, 2, 0, 2, 2, 1, 8, [[STACK0]], 0, 1, 8, [[STACK1]], 0, 2, 0, 2, 2, 0, 0, 1, 1, csr_64, implicit-def $rsp, implicit-def $ssp :: (load store 8 on [[STACK1]]), (load store 8 on [[STACK0]])
   ; CHECK-DAG:   $rbx = MOV64rm [[STACK0]], 1, $noreg, 0, $noreg :: (load 8 from [[STACK0]])
   ; CHECK-DAG:   $r14 = MOV64rm [[STACK1]], 1, $noreg, 0, $noreg :: (load 8 from [[STACK1]])
   ; CHECK:   ADJCALLSTACKUP64 0, 0, implicit-def dead $rsp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp
@@ -121,7 +121,7 @@
   ; CHECK:   ADJCALLSTACKDOWN64 0, 0, 0, implicit-def dead $rsp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp
   ; CHECK-DAG:   MOV64mr [[STACK0]], 1, $noreg, 0, $noreg, killed $rbx :: (store 8 into [[STACK0]])
   ; CHECK-DAG:   MOV64mr [[STACK1]], 1, $noreg, 0, $noreg, killed $r14 :: (store 8 into [[STACK1]])
-  ; CHECK:   STATEPOINT 0, 0, 0, @bar, 2, 0, 2, 0, 2, 0, 2, 2, 1, 8, %stack.0, 0, 1, 8, [[STACK1]], 0, 2, 0, 2, 2, 0, 0, 1, 1, csr_64, implicit-def $rsp, implicit-def $ssp :: (load store 8 on [[STACK0]]), (load store 8 on [[STACK1]])
+  ; CHECK:   STATEPOINT 0, 0, 0, @bar, 2, 0, 2, 0, 2, 0, 2, 2, 1, 8, %stack.0, 0, 1, 8, [[STACK1]], 0, 2, 0, 2, 2, 0, 0, 1, 1, csr_64, implicit-def $rsp, implicit-def $ssp :: (load store 8 on [[STACK1]]), (load store 8 on [[STACK0]])
   ; CHECK-DAG:   $rbx = MOV64rm [[STACK0]], 1, $noreg, 0, $noreg :: (load 8 from [[STACK0]])
   ; CHECK-DAG:   $r14 = MOV64rm [[STACK1]], 1, $noreg, 0, $noreg :: (load 8 from [[STACK1]])
   ; CHECK:   ADJCALLSTACKUP64 0, 0, implicit-def dead $rsp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp
Index: llvm/test/CodeGen/X86/statepoint-fixup-invoke.mir
===
--- llvm/test/CodeGen/X86/statepoint-fixup-invoke.mir
+++ llvm/test/CodeGen/X86/statepoint-fixup-invoke.mir
@@ -91,7 +91,7 @@
   ; CHECK-DAG:   MOV64mr %stack.1, 1, $noreg, 0, $noreg, $rdi :: (store 8 into %stack.1)
   ; CHECK:   EH_LABEL 
   ; CHECK:   ADJCALLSTACKDOWN64 0, 0, 0, implicit-def dead $rsp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp
-  ; CHECK:   STATEPOINT 0, 0, 1, @some_call, $r

[clang] d3bd06f - [clang] Fix the fsanitize.c testcase after eaae6fdf67e1f. NFC.

[Martin Storsjö via cfe-commits]

Author: Martin Storsjö
Date: 2020-11-03T10:21:29+02:00
New Revision: d3bd06f5c709fe073739a06e0d5a22020f0bf90c

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

LOG: [clang] Fix the fsanitize.c testcase after eaae6fdf67e1f. NFC.

After that commit, the vptr sanitizer is enabled for mingw targets.

Added: 


Modified: 
clang/test/Driver/fsanitize.c

Removed: 




diff  --git a/clang/test/Driver/fsanitize.c b/clang/test/Driver/fsanitize.c
index 0ecf656f292c..8926d55a0cf4 100644
--- a/clang/test/Driver/fsanitize.c
+++ b/clang/test/Driver/fsanitize.c
@@ -15,16 +15,17 @@
 // RUN: %clang -target x86_64-apple-darwin10 -fsanitize=undefined %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-UNDEFINED-DARWIN
 // CHECK-UNDEFINED-DARWIN: 
"-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|function|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute),?){18}"}}
 
-// RUN: %clang -target i386-pc-win32 -fsanitize=undefined %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN 
--check-prefix=CHECK-UNDEFINED-WIN32
-// RUN: %clang -target i386-pc-win32 -fsanitize=undefined -x c++ %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN 
--check-prefix=CHECK-UNDEFINED-WIN32 --check-prefix=CHECK-UNDEFINED-WIN-CXX
-// RUN: %clang -target x86_64-pc-win32 -fsanitize=undefined %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN 
--check-prefix=CHECK-UNDEFINED-WIN64
+// RUN: %clang -target i386-pc-win32 -fsanitize=undefined %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN 
--check-prefix=CHECK-UNDEFINED-WIN32 --check-prefix=CHECK-UNDEFINED-MSVC
+// RUN: %clang -target i386-pc-win32 -fsanitize=undefined -x c++ %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN 
--check-prefix=CHECK-UNDEFINED-WIN32 --check-prefix=CHECK-UNDEFINED-WIN-CXX 
--check-prefix=CHECK-UNDEFINED-MSVC
+// RUN: %clang -target x86_64-pc-win32 -fsanitize=undefined %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN 
--check-prefix=CHECK-UNDEFINED-WIN64 --check-prefix=CHECK-UNDEFINED-MSVC
 // RUN: %clang -target x86_64-w64-mingw32 -fsanitize=undefined %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN 
--check-prefix=CHECK-UNDEFINED-WIN64-MINGW
-// RUN: %clang -target x86_64-pc-win32 -fsanitize=undefined -x c++ %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN 
--check-prefix=CHECK-UNDEFINED-WIN64 --check-prefix=CHECK-UNDEFINED-WIN-CXX
+// RUN: %clang -target x86_64-pc-win32 -fsanitize=undefined -x c++ %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN 
--check-prefix=CHECK-UNDEFINED-WIN64 --check-prefix=CHECK-UNDEFINED-WIN-CXX 
--check-prefix=CHECK-UNDEFINED-MSVC
 // CHECK-UNDEFINED-WIN32: "--dependent-lib={{[^"]*}}ubsan_standalone-i386.lib"
 // CHECK-UNDEFINED-WIN64: 
"--dependent-lib={{[^"]*}}ubsan_standalone-x86_64.lib"
 // CHECK-UNDEFINED-WIN64-MINGW: 
"--dependent-lib={{[^"]*}}libclang_rt.ubsan_standalone-x86_64.a"
 // CHECK-UNDEFINED-WIN-CXX: 
"--dependent-lib={{[^"]*}}ubsan_standalone_cxx{{[^"]*}}.lib"
-// CHECK-UNDEFINED-WIN-SAME: 
"-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
+// CHECK-UNDEFINED-MSVC-SAME: 
"-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
+// CHECK-UNDEFINED-WIN64-MINGW-SAME: 
"-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute|vptr),?){18}"}}
 
 // RUN: %clang -target i386-pc-win32 -fsanitize-coverage=bb %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-COVERAGE-WIN32
 // CHECK-COVERAGE-WIN32: "--dependent-lib={{[^"]*}}ubsan_standalone-i386.lib"



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

[PATCH] D90208: [PowerPC] [Clang] Define macros to identify quad-fp semantics

[Qiu Chaofan via Phabricator via cfe-commits]

qiucf added inline comments.



Comment at: clang/lib/Basic/Targets/PPC.cpp:122
   if (LongDoubleWidth == 128) {
 Builder.defineMacro("__LONG_DOUBLE_128__");
 Builder.defineMacro("__LONGDOUBLE128");

steven.zhang wrote:
> Can you please double check if we need to define these two macros if PPC IEEE 
> long double enabled ? And also double check if they can be controlled by 
> options.
Yes. GCC shows expected behavior that `__LONG_DOUBLE_IEEE128__` is defined 
under `-mabi=ieeelongdouble` while `__LONG_DOUBLE_IBM128__` is defined when 
not. Some libraries may rely on this macro. (see 
https://www.openwall.com/lists/musl/2019/06/30/8)

In clang, currently we can only use `__LDBL_MANT_DIG__` to guess current 
128-bit fp semantics. (106 for IBM-quad, 113 for IEEE-quad). We need to 
implement dedicated macros.

And I'll keep the `FIXME` since it's not related to this revision.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90208

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

[PATCH] D90208: [PowerPC] [Clang] Define macros to identify quad-fp semantics

[Qiu Chaofan via Phabricator via cfe-commits]

qiucf updated this revision to Diff 302488.
qiucf marked an inline comment as done.
qiucf added a comment.

Keep the `FIXME`.


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

https://reviews.llvm.org/D90208

Files:
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/CodeGen/ppc64-long-double.cpp


Index: clang/test/CodeGen/ppc64-long-double.cpp
===
--- clang/test/CodeGen/ppc64-long-double.cpp
+++ clang/test/CodeGen/ppc64-long-double.cpp
@@ -16,6 +16,20 @@
 // RUN: %clang_cc1 -triple powerpc64-linux-musl -emit-llvm -o - 
-mlong-double-128 %s | \
 // RUN:   FileCheck --check-prefix=IBM128 %s
 
+// Check IBM-quad and IEEE-quad macros are defined.
+// RUN: %clang -E -dM -ffreestanding -target powerpc64le-linux-gnu %s \
+// RUN:   -mabi=ibmlongdouble | FileCheck -check-prefix=CHECK-DEF-IBM128 %s
+// RUN: %clang -E -dM -ffreestanding -target powerpc64le-linux-gnu %s \
+// RUN:   -mabi=ieeelongdouble | FileCheck -check-prefix=CHECK-DEF-IEEE128 %s
+// RUN: %clang -E -dM -ffreestanding -target powerpc64le-linux-gnu %s \
+// RUN:   -mlong-double-64 | FileCheck -check-prefix=CHECK-DEF-F64 %s
+
+// CHECK-DEF-IBM128: #define __LONG_DOUBLE_128__
+// CHECK-DEF-IBM128: #define __LONG_DOUBLE_IBM128__
+// CHECK-DEF-IEEE128: #define __LONG_DOUBLE_128__
+// CHECK-DEF-IEEE128: #define __LONG_DOUBLE_IEEE128__
+// CHECK-DEF-F64-NOT: #define __LONG_DOUBLE_128__
+
 long double x = 0;
 int size = sizeof(x);
 
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -122,6 +122,10 @@
   if (LongDoubleWidth == 128) {
 Builder.defineMacro("__LONG_DOUBLE_128__");
 Builder.defineMacro("__LONGDOUBLE128");
+if (Opts.PPCIEEELongDouble)
+  Builder.defineMacro("__LONG_DOUBLE_IEEE128__");
+else
+  Builder.defineMacro("__LONG_DOUBLE_IBM128__");
   }
 
   // Define this for elfv2 (64-bit only) or 64-bit darwin.


Index: clang/test/CodeGen/ppc64-long-double.cpp
===
--- clang/test/CodeGen/ppc64-long-double.cpp
+++ clang/test/CodeGen/ppc64-long-double.cpp
@@ -16,6 +16,20 @@
 // RUN: %clang_cc1 -triple powerpc64-linux-musl -emit-llvm -o - -mlong-double-128 %s | \
 // RUN:   FileCheck --check-prefix=IBM128 %s
 
+// Check IBM-quad and IEEE-quad macros are defined.
+// RUN: %clang -E -dM -ffreestanding -target powerpc64le-linux-gnu %s \
+// RUN:   -mabi=ibmlongdouble | FileCheck -check-prefix=CHECK-DEF-IBM128 %s
+// RUN: %clang -E -dM -ffreestanding -target powerpc64le-linux-gnu %s \
+// RUN:   -mabi=ieeelongdouble | FileCheck -check-prefix=CHECK-DEF-IEEE128 %s
+// RUN: %clang -E -dM -ffreestanding -target powerpc64le-linux-gnu %s \
+// RUN:   -mlong-double-64 | FileCheck -check-prefix=CHECK-DEF-F64 %s
+
+// CHECK-DEF-IBM128: #define __LONG_DOUBLE_128__
+// CHECK-DEF-IBM128: #define __LONG_DOUBLE_IBM128__
+// CHECK-DEF-IEEE128: #define __LONG_DOUBLE_128__
+// CHECK-DEF-IEEE128: #define __LONG_DOUBLE_IEEE128__
+// CHECK-DEF-F64-NOT: #define __LONG_DOUBLE_128__
+
 long double x = 0;
 int size = sizeof(x);
 
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -122,6 +122,10 @@
   if (LongDoubleWidth == 128) {
 Builder.defineMacro("__LONG_DOUBLE_128__");
 Builder.defineMacro("__LONGDOUBLE128");
+if (Opts.PPCIEEELongDouble)
+  Builder.defineMacro("__LONG_DOUBLE_IEEE128__");
+else
+  Builder.defineMacro("__LONG_DOUBLE_IBM128__");
   }
 
   // Define this for elfv2 (64-bit only) or 64-bit darwin.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D82756: Port some floating point options to new option marshalling infrastructure

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added a comment.

Thanks for the feedback.

@Bigcheese do you have anything to add?


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

https://reviews.llvm.org/D82756

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

[PATCH] D90588: [clangd] NFC: Only pass ASTContext and TokenBuffer in getFoldingRanges API

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev added a comment.

In D90588#2368021 , @sammccall wrote:

> This doesn't feel quite right to me - we're going to need to get PP 
> conditional regions, include blocks etc from the ParsedAST (they're not in 
> ASTContext).
> My sense is that we'll need a fairly random subset of ParsedAST, and so 
> ParsedAST is a reasonable abstraction unless it's hard to produce for tests. 
> But it isn't!
>
> What's the motivation for this change?

Aww that comment is regarding `syntax::buildSyntaxTree` weren't you? I thought 
this was about `getFoldingRanges` API... Sorry.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90588

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

[PATCH] D90630: [CodeGen] Fix Bug 47499: __unaligned extension inconsistent behaviour with C and C++

[Jan Ole Hüser via Phabricator via cfe-commits]

j0le updated this revision to Diff 302496.
j0le edited the summary of this revision.
j0le added a comment.

Moved comment into the else-if block.
Changed Summary of the diff, so that it is better suited for a commit message.


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

https://reviews.llvm.org/D90630

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/unaligned-struct-copy.c


Index: clang/test/CodeGen/unaligned-struct-copy.c
===
--- /dev/null
+++ clang/test/CodeGen/unaligned-struct-copy.c
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -xc   -O2 -triple thumbv7a-unknown-windows-eabi 
-fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc++ -O2 -triple thumbv7a-unknown-windows-eabi 
-fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc   -O2 -triple x86_64-unknown-linux-gnu -fms-extensions 
-emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc++ -O2 -triple x86_64-unknown-linux-gnu -fms-extensions 
-emit-llvm < %s | FileCheck %s
+
+struct S1 {
+  unsigned long x;
+};
+
+// CHECK: define
+// CHECK-SAME: void
+// CHECK-SAME: test1
+
+void test1(__unaligned struct S1 *out) {
+  // CHECK: store
+  // CHECK-SAME: align 1
+  out->x = 5;
+  // CHECK: ret void
+}
+
+// CHECK: define
+// CHECK-SAME: void
+// CHECK-SAME: test2
+
+void test2(__unaligned struct S1 *out, __unaligned struct S1 *in) {
+  // CHECK: load
+  // CHECK-SAME: align 1
+  // CHECK: store
+  // CHECK-SAME: align 1
+  *out = *in;
+  // CHECK: ret void
+}
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -6146,16 +6146,17 @@
 *BaseInfo = LValueBaseInfo(AlignmentSource::Type);
 
   CharUnits Alignment;
-  // For C++ class pointees, we don't know whether we're pointing at a
-  // base or a complete object, so we generally need to use the
-  // non-virtual alignment.
   const CXXRecordDecl *RD;
-  if (forPointeeType && !AlignForArray && (RD = T->getAsCXXRecordDecl())) {
+  if (T.getQualifiers().hasUnaligned()) {
+Alignment = CharUnits::One();
+  } else if (forPointeeType && !AlignForArray &&
+ (RD = T->getAsCXXRecordDecl())) {
+// For C++ class pointees, we don't know whether we're pointing at a
+// base or a complete object, so we generally need to use the
+// non-virtual alignment.
 Alignment = getClassPointerAlignment(RD);
   } else {
 Alignment = getContext().getTypeAlignInChars(T);
-if (T.getQualifiers().hasUnaligned())
-  Alignment = CharUnits::One();
   }
 
   // Cap to the global maximum type alignment unless the alignment


Index: clang/test/CodeGen/unaligned-struct-copy.c
===
--- /dev/null
+++ clang/test/CodeGen/unaligned-struct-copy.c
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -xc   -O2 -triple thumbv7a-unknown-windows-eabi -fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc++ -O2 -triple thumbv7a-unknown-windows-eabi -fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc   -O2 -triple x86_64-unknown-linux-gnu -fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc++ -O2 -triple x86_64-unknown-linux-gnu -fms-extensions -emit-llvm < %s | FileCheck %s
+
+struct S1 {
+  unsigned long x;
+};
+
+// CHECK: define
+// CHECK-SAME: void
+// CHECK-SAME: test1
+
+void test1(__unaligned struct S1 *out) {
+  // CHECK: store
+  // CHECK-SAME: align 1
+  out->x = 5;
+  // CHECK: ret void
+}
+
+// CHECK: define
+// CHECK-SAME: void
+// CHECK-SAME: test2
+
+void test2(__unaligned struct S1 *out, __unaligned struct S1 *in) {
+  // CHECK: load
+  // CHECK-SAME: align 1
+  // CHECK: store
+  // CHECK-SAME: align 1
+  *out = *in;
+  // CHECK: ret void
+}
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -6146,16 +6146,17 @@
 *BaseInfo = LValueBaseInfo(AlignmentSource::Type);
 
   CharUnits Alignment;
-  // For C++ class pointees, we don't know whether we're pointing at a
-  // base or a complete object, so we generally need to use the
-  // non-virtual alignment.
   const CXXRecordDecl *RD;
-  if (forPointeeType && !AlignForArray && (RD = T->getAsCXXRecordDecl())) {
+  if (T.getQualifiers().hasUnaligned()) {
+Alignment = CharUnits::One();
+  } else if (forPointeeType && !AlignForArray &&
+ (RD = T->getAsCXXRecordDecl())) {
+// For C++ class pointees, we don't know whether we're pointing at a
+// base or a complete object, so we generally need to use the
+// non-virtual alignment.
 Alignment = getClassPointerAlignment(RD);
   } else {
 Alignment = getContext().getTypeAlignInChars(T);
-if (T.getQualifiers().hasUnaligned())
-  Alignment = CharUnits::One();
  

[PATCH] D90588: [clangd] NFC: Only pass ASTContext and TokenBuffer in getFoldingRanges API

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D90588#2370604 , @kbobyrev wrote:

> In D90588#2368021 , @sammccall wrote:
>
>> This doesn't feel quite right to me - we're going to need to get PP 
>> conditional regions, include blocks etc from the ParsedAST (they're not in 
>> ASTContext).
>> My sense is that we'll need a fairly random subset of ParsedAST, and so 
>> ParsedAST is a reasonable abstraction unless it's hard to produce for tests. 
>> But it isn't!
>>
>> What's the motivation for this change?
>
> Aww that comment is regarding `syntax::buildSyntaxTree` weren't you? I 
> thought this was about `getFoldingRanges` API... Sorry.

Oops, sorry - yes :-(

My the point there was that the traversal roots for building the syntax tree 
are the ASTContext's traversal scope, which defaults to TUDecl, so passing in 
TUDecl is misleading there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90588

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

[PATCH] D90630: [CodeGen] Fix Bug 47499: __unaligned extension inconsistent behaviour with C and C++

[Jan Ole Hüser via Phabricator via cfe-commits]

j0le marked an inline comment as done.
j0le added a comment.

In D90630#2368984 , @rnk wrote:

> Thanks, this basically looks correct to me, aside from some formatting 
> details. Do you want me to apply those fixes and land this for you? I see 
> that was done for your last patch, but it's best to ask first.

Yes, that would be nice, if you could land this for me.


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

https://reviews.llvm.org/D90630

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

[PATCH] D90208: [PowerPC] [Clang] Define macros to identify quad-fp semantics

[Qing Shan Zhang via Phabricator via cfe-commits]

steven.zhang added a comment.

LGTM now and thank you for the double check. But please hold on for some days 
in case someone has concern on enabling the new macros(we are enabling the 
__LONG_DOUBLE_IBM128__ by default now).


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

https://reviews.llvm.org/D90208

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

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen requested changes to this revision.
sdesmalen added inline comments.
This revision now requires changes to proceed.



Comment at: clang/docs/LanguageExtensions.rst:3039
+useful for specifying the optimal width/count of the set of target
+architectures supported by your application.
 

Can you add a comment saying that the use of `"scalable"` is still experimental 
and is currently only intended to work for targets that support scalable 
vectors?



Comment at: clang/lib/Sema/SemaStmtAttr.cpp:144
+  assert(ValueExpr && "Attribute must have a valid value expression.");
+  if (S.CheckLoopHintExpr(ValueExpr, St->getBeginLoc()))
+return nullptr;

fhahn wrote:
> sdesmalen wrote:
> > david-arm wrote:
> > > fhahn wrote:
> > > > Is there a way to only accept `fixed_width/scalable` for targets that 
> > > > support it? Not sure if we have enough information here, but we might 
> > > > be able to reject it eg per target basis or something
> > > Hi @fhahn, I think if possible we'd prefer not to reject scalable vectors 
> > > at this point. Theoretically there is no reason why we can't perform 
> > > scalable vectorisation for targets that don't have hardware support for 
> > > scalable vectors. In this case it simply means that vscale is 1. If you 
> > > want we could add some kind of opt-remark in the vectoriser that says 
> > > something like "target does not support scalable vectors, vectorising for 
> > > vscale=1"?
> > I agree with @david-arm that we shouldn't prevent this in the front-end. 
> > Even if the architecture may not support scalable vectors natively, there 
> > may still be reasons to want to create scalable vectors in IR, for example 
> > to have more portable IR.
> Hm, I am just a bit worried that it might be a bit confusing to users that do 
> not know what scalable vectors are (it is obvious when knowing all about SVE, 
> but I would assume most people don't necessarily know what this means). I 
> guess that is not the biggest deal, as long `vectorize_width(X, scalable)` 
> works for every target.
> 
> >  Even if the architecture may not support scalable vectors natively, there 
> > may still be reasons to want to create scalable vectors in IR, for example 
> > to have more portable IR.
> 
> Sure, but there are so many other target-specific things encoded that make 
> the IR really un-portable between targets. Granted, it is not impossible to 
> convert IR between some architectures (as in arm64_32)
Sorry, forgot to reply to this.

> Hm, I am just a bit worried that it might be a bit confusing to users that do 
> not know what scalable vectors are (it is obvious when knowing all about SVE, 
> but I would assume most people don't necessarily know what this means). I 
> guess that is not the biggest deal, as long vectorize_width(X, scalable) 
> works for every target.
At the moment this feature is still experimental, so I don't think any target 
would be able to return `true` to the question if this is supported :) That 
said, I agree that the compiler shouldn't crash for other targets after support 
in the loop-vectorizer stops being experimental. So I'm changing my mind here, 
and am happy to go with your suggestion to ignore the flag for other targets. 
When some default mechanism is added to lower scalable vectors to fixed-width 
vectors (for targets that don't natively support them), this check can probably 
be removed. @david-arm can you add some target hook to ignore the hint?

> Sure, but there are so many other target-specific things encoded that make 
> the IR really un-portable between targets. Granted, it is not impossible to 
> convert IR between some architectures (as in arm64_32)
I didn't mean portable between targets, but more as keeping the length of the 
vector agnostic in IR and leaving it until code-generation to pick a 
suitable/available vector extension, so that the same IR could be used to 
generate code for Neon or 256bit SVE for example. This is more a hypothetical 
use-case at the moment though.


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

https://reviews.llvm.org/D89031

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

[PATCH] D90654: [clangd] Add index server request logging

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

I wish there was an easy way to check redacted error logs too :/




Comment at: clang-tools-extra/clangd/index/remote/server/Server.cpp:335
 return std::make_unique(OS, LogLevel);
+llvm::errs() << "non redacted logger\n";
+  }

feels like this one, and the one below are residues?



Comment at: clang-tools-extra/clangd/test/remote-index/public-log.test:2
+# RUN: rm -rf %t
+# RUN: clangd-indexer %S/Inputs/Source.cpp > %t.idx
+# RUN: %python %S/pipeline_helper.py --input-file-name=%s 
--server-arg=--log=verbose --server-arg=-log-public --server-log=%t.public.log 
--project-root=%S --index-file=%t.idx > /dev/null

nit: use `%/S` to not mix forward and backslashes.



Comment at: clang-tools-extra/clangd/test/remote-index/public-log.test:3
+# RUN: clangd-indexer %S/Inputs/Source.cpp > %t.idx
+# RUN: %python %S/pipeline_helper.py --input-file-name=%s 
--server-arg=--log=verbose --server-arg=-log-public --server-log=%t.public.log 
--project-root=%S --index-file=%t.idx > /dev/null
+# RUN: %python %S/pipeline_helper.py --input-file-name=%s 
--server-arg=--log=verbose --server-log=%t.log --project-root=%S 
--index-file=%t.idx > /dev/null

not sure if it is any easier, but it might make sense to just pass anything 
after `--` to server, rather than explicitly mentioning `--server-arg` before 
each one. I suppose we can also rename the script to `server_request_helper` ?

This won't work if we decide to pass arbitrary client flags too though.



Comment at: clang-tools-extra/clangd/test/remote-index/public-log.test:6
+# RUN: FileCheck --check-prefixes=LOG,LOG-PUBLIC %s < %t.public.log
+# RUN: FileCheck --check-prefixes=LOG,LOG-ALL %s < %t.log
+# REQUIRES: clangd-remote-index

can you also add a check for TextProto printing ? I believe descriptor names 
should be enough.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90654

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

[PATCH] D90672: [clang] Simplify buildSyntaxTree API

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev created this revision.
kbobyrev added a reviewer: sammccall.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman.
Herald added a project: clang.
kbobyrev requested review of this revision.

Follow-up on https://reviews.llvm.org/D88553#inline-837013


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90672

Files:
  clang-tools-extra/clangd/SemanticSelection.cpp
  clang/include/clang/Tooling/Syntax/BuildTree.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/unittests/Tooling/Syntax/TreeTestBase.cpp


Index: clang/unittests/Tooling/Syntax/TreeTestBase.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTestBase.cpp
+++ clang/unittests/Tooling/Syntax/TreeTestBase.cpp
@@ -81,7 +81,7 @@
   Tokens = nullptr; // make sure we fail if this gets called twice.
   Arena = std::make_unique(Ctx.getSourceManager(),
   Ctx.getLangOpts(), *TB);
-  Root = syntax::buildSyntaxTree(*Arena, *Ctx.getTranslationUnitDecl());
+  Root = syntax::buildSyntaxTree(*Arena, Ctx);
 }
 
   private:
Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -1712,9 +1712,9 @@
   return It->second;
 }
 
-syntax::TranslationUnit *
-syntax::buildSyntaxTree(Arena &A, const TranslationUnitDecl &TU) {
+syntax::TranslationUnit *syntax::buildSyntaxTree(Arena &A,
+ ASTContext &Context) {
   TreeBuilder Builder(A);
-  BuildTreeVisitor(TU.getASTContext(), 
Builder).TraverseAST(TU.getASTContext());
+  BuildTreeVisitor(Context, Builder).TraverseAST(Context);
   return std::move(Builder).finalize();
 }
Index: clang/include/clang/Tooling/Syntax/BuildTree.h
===
--- clang/include/clang/Tooling/Syntax/BuildTree.h
+++ clang/include/clang/Tooling/Syntax/BuildTree.h
@@ -19,8 +19,7 @@
 namespace syntax {
 
 /// Build a syntax tree for the main file.
-syntax::TranslationUnit *buildSyntaxTree(Arena &A,
- const clang::TranslationUnitDecl &TU);
+syntax::TranslationUnit *buildSyntaxTree(Arena &A, ASTContext &Context);
 
 // Create syntax trees from subtrees not backed by the source code.
 
Index: clang-tools-extra/clangd/SemanticSelection.cpp
===
--- clang-tools-extra/clangd/SemanticSelection.cpp
+++ clang-tools-extra/clangd/SemanticSelection.cpp
@@ -160,8 +160,7 @@
 // Related issue: https://github.com/clangd/clangd/issues/310
 llvm::Expected> getFoldingRanges(ParsedAST &AST) {
   syntax::Arena A(AST.getSourceManager(), AST.getLangOpts(), AST.getTokens());
-  const auto *SyntaxTree =
-  syntax::buildSyntaxTree(A, 
*AST.getASTContext().getTranslationUnitDecl());
+  const auto *SyntaxTree = syntax::buildSyntaxTree(A, AST.getASTContext());
   return collectFoldingRanges(SyntaxTree, AST.getSourceManager());
 }
 


Index: clang/unittests/Tooling/Syntax/TreeTestBase.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTestBase.cpp
+++ clang/unittests/Tooling/Syntax/TreeTestBase.cpp
@@ -81,7 +81,7 @@
   Tokens = nullptr; // make sure we fail if this gets called twice.
   Arena = std::make_unique(Ctx.getSourceManager(),
   Ctx.getLangOpts(), *TB);
-  Root = syntax::buildSyntaxTree(*Arena, *Ctx.getTranslationUnitDecl());
+  Root = syntax::buildSyntaxTree(*Arena, Ctx);
 }
 
   private:
Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -1712,9 +1712,9 @@
   return It->second;
 }
 
-syntax::TranslationUnit *
-syntax::buildSyntaxTree(Arena &A, const TranslationUnitDecl &TU) {
+syntax::TranslationUnit *syntax::buildSyntaxTree(Arena &A,
+ ASTContext &Context) {
   TreeBuilder Builder(A);
-  BuildTreeVisitor(TU.getASTContext(), Builder).TraverseAST(TU.getASTContext());
+  BuildTreeVisitor(Context, Builder).TraverseAST(Context);
   return std::move(Builder).finalize();
 }
Index: clang/include/clang/Tooling/Syntax/BuildTree.h
===
--- clang/include/clang/Tooling/Syntax/BuildTree.h
+++ clang/include/clang/Tooling/Syntax/BuildTree.h
@@ -19,8 +19,7 @@
 namespace syntax {
 
 /// Build a syntax tree for the main file.
-syntax::TranslationUnit *buildSyntaxTree(Arena &A,
- const clang::TranslationUnitDecl &TU);
+syntax::TranslationUnit *buildSyntaxTree(Arena &A, ASTContext &Context);
 
 // Create syntax trees from subtrees not backed by the source code.
 

[PATCH] D89936: [clang-tidy] adding "--config-file=" to specify custom config file.

[Dmitry Polukhin via Phabricator via cfe-commits]

DmitryPolukhin added a comment.

In D89936#2370163 , @Hiralo wrote:

> When this patch will be merged and available in master?

@Hiralo I can push this changes to master for you. Please let me know if you 
need it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89936

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

[PATCH] D90572: [clang] [MinGW] Allow using the vptr sanitizer

[Stephan Bergmann via Phabricator via cfe-commits]

sberg added a comment.

Smells like this breaks various bots due to a -fsanitize=...,... option now 
listing 18 instead of 17 items, see 
http://lab.llvm.org:8011/#builders/76/builds/363, 
http://lab.llvm.org:8011/#builders/93/builds/430, 
http://lab.llvm.org:8011/#builders/66/builds/315, 
http://lab.llvm.org:8011/#builders/7/builds/303.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90572

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

[PATCH] D90572: [clang] [MinGW] Allow using the vptr sanitizer

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In D90572#2370716 , @sberg wrote:

> Smells like this breaks various bots due to a -fsanitize=...,... option now 
> listing 18 instead of 17 items, see 
> http://lab.llvm.org:8011/#builders/76/builds/363, 
> http://lab.llvm.org:8011/#builders/93/builds/430, 
> http://lab.llvm.org:8011/#builders/66/builds/315, 
> http://lab.llvm.org:8011/#builders/7/builds/303.

Yep, I pushed a commit that is supposed to fix it, 
d3bd06f5c709fe073739a06e0d5a22020f0bf90c 
, but all 
bots haven't caught up yet. Sorry for the noise and breakage.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90572

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

[PATCH] D89936: [clang-tidy] adding "--config-file=" to specify custom config file.

[Hiral via Phabricator via cfe-commits]

Hiralo added a comment.

In D89936#2370712 , @DmitryPolukhin 
wrote:

> In D89936#2370163 , @Hiralo wrote:
>
>> When this patch will be merged and available in master?
>
> @Hiralo I can push this changes to master for you. Please let me know if you 
> need it.

Yes please.

And just for confirmation, this patch will be part of the release 12.0.0 (i.e. 
Dec release), correct?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89936

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

[PATCH] D90673: yet another commit

[Mikhail Goncharov via Phabricator via cfe-commits]

goncharov created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
goncharov requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90673

Files:
  clang-tools-extra/docs/new_file.txt


Index: clang-tools-extra/docs/new_file.txt
===
--- clang-tools-extra/docs/new_file.txt
+++ clang-tools-extra/docs/new_file.txt
@@ -2,3 +2,4 @@
 ddd
 ccc
 eee
+fff


Index: clang-tools-extra/docs/new_file.txt
===
--- clang-tools-extra/docs/new_file.txt
+++ clang-tools-extra/docs/new_file.txt
@@ -2,3 +2,4 @@
 ddd
 ccc
 eee
+fff
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88859: APINotes: add APINotesYAMLCompiler

[Gabor Marton via Phabricator via cfe-commits]

martong accepted this revision.
martong added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: rnkovacs.

Looks good to me now! Thanks for addressing my concerns.




Comment at: clang/tools/apinotes-test/APINotesTest.cpp:15
+
+static llvm::cl::list
+APINotes(llvm::cl::Positional, llvm::cl::desc("[ ...]"),

We still have: `clang-format: please reformat the code`. (Mabe you already 
know, but if you use [[ 
https://secure.phabricator.com/book/phabricator/article/arcanist/ | arc ]] then 
all these formatting issues are handled automatically and it will upload a 
linted patch to Phabricator.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88859

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

[clang] ff02ae2 - Add test missing from previous commit

[Stephen Kelly via cfe-commits]

Author: Stephen Kelly
Date: 2020-11-03T11:06:52Z
New Revision: ff02ae2139eebbe3fbd66d4204ad7589d475a355

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

LOG: Add test missing from previous commit

Added: 


Modified: 
clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Removed: 




diff  --git a/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp 
b/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
index 092747e4387d..13b5011bfe3e 100644
--- a/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ b/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2188,6 +2188,59 @@ void varDeclCtors() {
   Code,
   traverse(TK_IgnoreUnlessSpelledInSource,
varDecl(hasName("var8"), hasInitializer(cxxConstructExpr());
+
+  Code = R"cpp(
+
+template
+struct TemplStruct {
+  TemplStruct() {}
+  ~TemplStruct() {}
+
+private:
+  T m_t;
+};
+
+template
+T timesTwo(T input)
+{
+  return input * 2;
+}
+
+void instantiate()
+{
+  TemplStruct ti;
+  TemplStruct td;
+  (void)timesTwo(2);
+  (void)timesTwo(2);
+}
+
+)cpp";
+  {
+auto M = cxxRecordDecl(hasName("TemplStruct"),
+   has(fieldDecl(hasType(asString("int");
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
+  {
+auto M = cxxRecordDecl(hasName("TemplStruct"),
+   has(fieldDecl(hasType(asString("double");
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
+  {
+auto M =
+functionDecl(hasName("timesTwo"),
+ hasParameter(0, parmVarDecl(hasType(asString("int");
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
+  {
+auto M =
+functionDecl(hasName("timesTwo"),
+ hasParameter(0, 
parmVarDecl(hasType(asString("double");
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
 }
 
 template 



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

[PATCH] D90654: [clangd] Add index server request logging

[Aleksandr Platonov via Phabricator via cfe-commits]

ArcsinX added inline comments.



Comment at: clang-tools-extra/clangd/test/remote-index/pipeline_helper.py:43
   args.index_file, args.project_root
-  ],
+  ] + args.server_arg,
   stderr=subprocess.PIPE)

this breaks `remote-index/pipeline.test` test for me:
```
TypeError: can only concatenate list (not "NoneType") to list
```



Comment at: clang-tools-extra/clangd/test/remote-index/public-log.test:5
+# RUN: %python %S/pipeline_helper.py --input-file-name=%s 
--server-arg=--log=verbose --server-log=%t.log --project-root=%S 
--index-file=%t.idx > /dev/null
+# RUN: FileCheck --check-prefixes=LOG,LOG-PUBLIC %s < %t.public.log
+# RUN: FileCheck --check-prefixes=LOG,LOG-ALL %s < %t.log

Maybe we can use `--input-file` option of FileCheck instead of `<` (the same 
for the next line)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90654

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

[clang-tools-extra] d6a468d - [clang-tidy] adding "--config-file=" to specify custom config file.

[Dmitry Polukhin via cfe-commits]

Author: Hiral Oza
Date: 2020-11-03T11:59:46Z
New Revision: d6a468d622b2d48c40c47290aa54d6d910c5a6bf

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

LOG: [clang-tidy] adding "--config-file=" to specify custom config 
file.

Let clang-tidy to read config from specified file.
Example:
$ clang-tidy --config-file=/some/path/myTidyConfig --list-checks --
...this will read config from '/some/path/myTidyConfig'.

ClangTidyMain.cpp reads ConfigFile into string and then assigned read data to 
'Config' i.e. makes like '--config' code flow internally.

May speed-up tidy runtime since now it will just look-up 
instead of searching ".clang-tidy" in parent-dir(s).

Directly specifying config path helps setting build dependencies.

Thanks to @DmitryPolukhin for valuable suggestion. This patch now propose
change only in ClangTidyMain.cpp.

Reviewed By: DmitryPolukhin

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

Added: 

clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-file/config-file
clang-tools-extra/test/clang-tidy/infrastructure/config-file.cpp

Modified: 
clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp 
b/clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
index e248c04ea570..e0465665d6a0 100644
--- a/clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ b/clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -168,6 +168,16 @@ each source file in its parent directories.
 )"),
cl::init(""), cl::cat(ClangTidyCategory));
 
+static cl::opt ConfigFile("config-file", cl::desc(R"(
+Specify the path of .clang-tidy or custom config file:
+ e.g. --config-file=/some/path/myTidyConfigFile
+This option internally works exactly the same way as
+ --config option after reading specified config file.
+Use either --config-file or --config, not both.
+)"),
+   cl::init(""),
+   cl::cat(ClangTidyCategory));
+
 static cl::opt DumpConfig("dump-config", cl::desc(R"(
 Dumps configuration in the YAML format to
 stdout. This option can be used along with a
@@ -302,19 +312,41 @@ static std::unique_ptr 
createOptionsProvider(
   if (UseColor.getNumOccurrences() > 0)
 OverrideOptions.UseColor = UseColor;
 
-  if (!Config.empty()) {
-if (llvm::ErrorOr ParsedConfig =
-parseConfiguration(Config)) {
+  auto LoadConfig = [&](StringRef Configuration)
+  -> std::unique_ptr {
+llvm::ErrorOr ParsedConfig =
+parseConfiguration(Configuration);
+if (ParsedConfig)
   return std::make_unique(
   GlobalOptions,
   ClangTidyOptions::getDefaults().mergeWith(DefaultOptions, 0),
   *ParsedConfig, OverrideOptions, std::move(FS));
-} else {
-  llvm::errs() << "Error: invalid configuration specified.\n"
-   << ParsedConfig.getError().message() << "\n";
+llvm::errs() << "Error: invalid configuration specified.\n"
+ << ParsedConfig.getError().message() << "\n";
+return nullptr;
+  };
+
+  if (ConfigFile.getNumOccurrences() > 0) {
+if (Config.getNumOccurrences() > 0) {
+  llvm::errs() << "Error: --config-file and --config are "
+  "mutually exclusive. Specify only one.\n";
   return nullptr;
 }
+
+llvm::ErrorOr> Text =
+llvm::MemoryBuffer::getFile(ConfigFile.c_str());
+if (std::error_code EC = Text.getError()) {
+  llvm::errs() << "Error: can't read config-file '" << ConfigFile
+   << "': " << EC.message() << "\n";
+  return nullptr;
+}
+
+return LoadConfig((*Text)->getBuffer());
   }
+
+  if (Config.getNumOccurrences() > 0)
+return LoadConfig(Config);
+
   return std::make_unique(GlobalOptions, DefaultOptions,
 OverrideOptions, 
std::move(FS));
 }

diff  --git 
a/clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-file/config-file
 
b/clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-file/config-file
new file mode 100644
index ..23bb65e0155b
--- /dev/null
+++ 
b/clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-file/config-file
@@ -0,0 +1 @@
+Checks: "-*,hicpp-uppercase-literal-suffix"

diff  --git a/clang-tools-extra/test/clang-tidy/infrastructure/config-file.cpp 
b/clang-tools-extra/test/clang-tidy/infrastructure/config-file.cpp
new file mode 100644
index ..49028d198f75
--- /dev/null
+++ b/clang-tools-extra/test/clang-tidy/infrastructure/config-file.cpp
@@ -0,0 +1,2 @@
+// RUN: clang-tidy -config-file=%S/Inputs/config-file/config-file -dump-config 
-- | FileCheck %s -check-prefix=CHECK-BASE
+// CHECK-BASE: Ch

[PATCH] D89936: [clang-tidy] adding "--config-file=" to specify custom config file.

[Dmitry Polukhin via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd6a468d622b2: [clang-tidy] adding 
"--config-file=" to specify custom config file. 
(authored by Hiralo, committed by DmitryPolukhin).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89936

Files:
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-file/config-file
  clang-tools-extra/test/clang-tidy/infrastructure/config-file.cpp


Index: clang-tools-extra/test/clang-tidy/infrastructure/config-file.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/config-file.cpp
@@ -0,0 +1,2 @@
+// RUN: clang-tidy -config-file=%S/Inputs/config-file/config-file -dump-config 
-- | FileCheck %s -check-prefix=CHECK-BASE
+// CHECK-BASE: Checks: {{.*}}hicpp-uppercase-literal-suffix
Index: 
clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-file/config-file
===
--- /dev/null
+++ 
clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-file/config-file
@@ -0,0 +1 @@
+Checks: "-*,hicpp-uppercase-literal-suffix"
Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -168,6 +168,16 @@
 )"),
cl::init(""), cl::cat(ClangTidyCategory));
 
+static cl::opt ConfigFile("config-file", cl::desc(R"(
+Specify the path of .clang-tidy or custom config file:
+ e.g. --config-file=/some/path/myTidyConfigFile
+This option internally works exactly the same way as
+ --config option after reading specified config file.
+Use either --config-file or --config, not both.
+)"),
+   cl::init(""),
+   cl::cat(ClangTidyCategory));
+
 static cl::opt DumpConfig("dump-config", cl::desc(R"(
 Dumps configuration in the YAML format to
 stdout. This option can be used along with a
@@ -302,19 +312,41 @@
   if (UseColor.getNumOccurrences() > 0)
 OverrideOptions.UseColor = UseColor;
 
-  if (!Config.empty()) {
-if (llvm::ErrorOr ParsedConfig =
-parseConfiguration(Config)) {
+  auto LoadConfig = [&](StringRef Configuration)
+  -> std::unique_ptr {
+llvm::ErrorOr ParsedConfig =
+parseConfiguration(Configuration);
+if (ParsedConfig)
   return std::make_unique(
   GlobalOptions,
   ClangTidyOptions::getDefaults().mergeWith(DefaultOptions, 0),
   *ParsedConfig, OverrideOptions, std::move(FS));
-} else {
-  llvm::errs() << "Error: invalid configuration specified.\n"
-   << ParsedConfig.getError().message() << "\n";
+llvm::errs() << "Error: invalid configuration specified.\n"
+ << ParsedConfig.getError().message() << "\n";
+return nullptr;
+  };
+
+  if (ConfigFile.getNumOccurrences() > 0) {
+if (Config.getNumOccurrences() > 0) {
+  llvm::errs() << "Error: --config-file and --config are "
+  "mutually exclusive. Specify only one.\n";
   return nullptr;
 }
+
+llvm::ErrorOr> Text =
+llvm::MemoryBuffer::getFile(ConfigFile.c_str());
+if (std::error_code EC = Text.getError()) {
+  llvm::errs() << "Error: can't read config-file '" << ConfigFile
+   << "': " << EC.message() << "\n";
+  return nullptr;
+}
+
+return LoadConfig((*Text)->getBuffer());
   }
+
+  if (Config.getNumOccurrences() > 0)
+return LoadConfig(Config);
+
   return std::make_unique(GlobalOptions, DefaultOptions,
 OverrideOptions, 
std::move(FS));
 }


Index: clang-tools-extra/test/clang-tidy/infrastructure/config-file.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/config-file.cpp
@@ -0,0 +1,2 @@
+// RUN: clang-tidy -config-file=%S/Inputs/config-file/config-file -dump-config -- | FileCheck %s -check-prefix=CHECK-BASE
+// CHECK-BASE: Checks: {{.*}}hicpp-uppercase-literal-suffix
Index: clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-file/config-file
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-file/config-file
@@ -0,0 +1 @@
+Checks: "-*,hicpp-uppercase-literal-suffix"
Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -168,6 +168,16 @@
 )"),

[PATCH] D72184: [WIP][BPF] support exchange/compare-and-exchange instruction

[Brendan Jackman via Phabricator via cfe-commits]

jackmanb added inline comments.



Comment at: llvm/lib/Target/BPF/BPFInstrFormats.td:98
+
+def BPF_ATOMIC_FETCH : BPFAtomicFlag<0x1>;
 

Per Alexei's email comments let's call this BPF_FETCH?



Comment at: llvm/lib/Target/BPF/BPFInstrInfo.td:765
+  def XCHGB : XCHG;
+  def XCHGH : XCHG;
+  def XCHGW : XCHG;

I don't know if we want to define these for 16 and 8bit operands - XADD isn't 
defined for those.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72184

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

[PATCH] D74735: [analyzer] Add support for CXXInheritedCtorInitExpr.

[Balázs Benics via Phabricator via cfe-commits]

steakhal added inline comments.
Herald added a subscriber: ASDenysPetrov.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h:916-918
+  virtual const CXXInheritedCtorInitExpr *getOriginExpr() const {
+return cast(AnyFunctionCall::getOriginExpr());
+  }

Why is this function virtual?
If we want such behavior we should mark the `CallEvent::getOriginExpr` virtual 
and just //override// it here.
As-of-now, this just hides the previous implementation, causing potential 
problems.

This code-smell occures several times across this class hierachy.

Is this the expected behavior @NoQ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74735

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

[PATCH] D80961: [clang][AST] Ignore template instantiations if not in AsIs mode

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

This seems to make asan buildbots unhappy: 
http://lab.llvm.org:8011/#/builders/5/builds/744
I can't see anything immediately suspicious, but I don't know the matcher 
internals that well :-\


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80961

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

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 302542.
balazske added a comment.

Rename of the checker.
Using canonical decl for system function detection.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87449

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-signal-handler.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-sig30-c.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/signal.h
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/stdlib.h
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
@@ -0,0 +1,78 @@
+// RUN: %check_clang_tidy %s cert-sig30-c %t -- -- -isystem %S/Inputs/Headers
+
+#include "signal.h"
+#include "stdio.h"
+#include "stdlib.h"
+
+// The function should be classified as system call even if there is
+// declaration the in source file.
+// FIXME: The detection works only if the first declaration is in system
+// header.
+int printf(const char *, ...);
+typedef void (*sighandler_t)(int);
+sighandler_t signal(int signum, sighandler_t handler);
+
+void handler_abort(int) {
+  abort();
+}
+
+void handler__Exit(int) {
+  _Exit(0);
+}
+
+void handler_quick_exit(int) {
+  quick_exit(0);
+}
+
+void handler_other(int) {
+  printf("1234");
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void handler_signal(int) {
+  // FIXME: It is only OK to call signal with the current signal number.
+  signal(0, SIG_DFL);
+}
+
+void f_ok() {
+  abort();
+}
+
+void f_bad() {
+  printf("1234");
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void f_extern();
+
+void handler_ok(int) {
+  f_ok();
+}
+
+void handler_bad(int) {
+  f_bad();
+}
+
+void handler_extern(int) {
+  f_extern();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void test() {
+  signal(SIGINT, handler_abort);
+  signal(SIGINT, handler__Exit);
+  signal(SIGINT, handler_quick_exit);
+  signal(SIGINT, handler_signal);
+  signal(SIGINT, handler_other);
+
+  signal(SIGINT, handler_ok);
+  signal(SIGINT, handler_bad);
+  signal(SIGINT, handler_extern);
+
+  signal(SIGINT, quick_exit);
+  signal(SIGINT, other_call);
+  // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: 'other_call' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+
+  signal(SIGINT, SIG_IGN);
+  signal(SIGINT, SIG_DFL);
+}
Index: clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/stdlib.h
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/stdlib.h
@@ -0,0 +1,18 @@
+//===--- stdlib.h - Stub header for tests ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _STDLIB_H_
+#define _STDLIB_H_
+
+void abort(void);
+void _Exit(int __status);
+void quick_exit(int __status);
+
+void other_call(int);
+
+#endif // _STDLIB_H_
Index: clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/signal.h
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/signal.h
@@ -0,0 +1,22 @@
+//===--- signal.h - Stub header for tests ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _SIGNAL_H_
+#define _SIGNAL_H_
+
+void _sig_ign(int);
+void _sig_dfl(int);
+
+#define SIGINT 1
+#define SIG_IGN _sig_ign
+#define SIG_DFL _sig_dfl
+
+typedef void (*sighandler_t)(int);
+sighandler_t signal(int signum, sighandler_t handler);
+
+#endif // _SIGNAL_H_

[PATCH] D90174: [HIP] Fix regressions due to fp contract change

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D90174#2370336 , @rjmccall wrote:

> I agree this is useful.  However, you need to update the manual to cover 
> `faststd`.

will update the manual.




Comment at: clang/test/CodeGenCUDA/fp-contract.cu:203
+
+// AMD-OPT-FAST-IR: fmul contract float
+// AMD-OPT-FAST-IR: fadd contract float

@rjmccall I have IRGen checks in this test. Are they sufficient? Thanks.


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

https://reviews.llvm.org/D90174

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

[PATCH] D90303: [ASTMatchers] Made isExpandedFromMacro Polymorphic

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM aside from testing request.




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:313
+  AST_POLYMORPHIC_SUPPORTED_TYPES(Decl, Stmt, TypeLoc),
+  std::string, MacroName) {
   // Verifies that the statement' beginning and ending are both expanded from

njames93 wrote:
> aaron.ballman wrote:
> > You mentioned that the change from `StringRef` to `std::string` was to 
> > avoid lifetime issues while matching, but I'm wondering if you can expound 
> > on that situation a bit more. I would have assumed that any memoization 
> > that involves `StringRef` would be responsible for the lifetime issues 
> > rather than the matchers themselves, but maybe I'm thinking about a 
> > different way you can hit lifetime issues than you are.
> Take this as contrived, however using ASAN reports a heap-use-after-free for 
> this code when isExpandedFromMacro takes a `StringRef` but works fine when 
> using `std::string`.
> ```lang=c++
> TEST(IsExpandedFromMacro, IsExpandedFromMacro_MatchesDecls) {
>   auto Matcher = 
> isExpandedFromMacro(std::string("MY_MACRO_OVERFLOW_SMALL_STRING_SIZE"));// 
> <-Temporary string created and destroyed here.
>   StringRef input = R"cc(
> #define MY_MACRO_OVERFLOW_SMALL_STRING_SIZE(a) int i = a;
> void Test() { MY_MACRO_OVERFLOW_SMALL_STRING_SIZE(4); }
>   )cc";
>   EXPECT_TRUE(matches(input, varDecl(Matcher))); // <- heap-use-after-free 
> detected down the callstack from here.
> }
> ```
> Obviously this is very contrived to ensure asan detects the use-after-free 
> and to ensure the temporary string is destroyed before the matcher. For these 
> tests it doesn't look like a problem, but in other instances these matchers 
> will outlive a string being passed to them
> ```lang=c++
> void addVarFromMacro(ASTMatchFinder* Finder, std::string MacroName) {
>   Finder->addMatcher(varDecl(isExpandedFromMacro(MacroName)), this);
> }
> ```
Oh, how interesting! I can see now where the lifetime issues come in to play, 
thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90303

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