[PATCH] D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info

2021-09-13 Thread Henry Linjamäki via Phabricator via cfe-commits
linjamaki updated this revision to Diff 372406.
linjamaki added a comment.

Add -verify and expected-no-diagnostics to a SPIR-V test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109144

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/SPIR.cpp
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Headers/opencl-c-base.h
  clang/lib/Headers/opencl-c.h
  clang/test/CodeGenOpenCL/spirv_target.cl
  clang/test/Headers/opencl-c-header.cl
  clang/test/Preprocessor/predefined-macros.c
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/Support/Triple.cpp
  llvm/unittests/ADT/TripleTest.cpp

Index: llvm/unittests/ADT/TripleTest.cpp
===
--- llvm/unittests/ADT/TripleTest.cpp
+++ llvm/unittests/ADT/TripleTest.cpp
@@ -224,6 +224,16 @@
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
   EXPECT_EQ(Triple::UnknownOS, T.getOS());
 
+  T = Triple("spirv32-unknown-unknown");
+  EXPECT_EQ(Triple::spirv32, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv64-unknown-unknown");
+  EXPECT_EQ(Triple::spirv64, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
   T = Triple("x86_64-unknown-ananas");
   EXPECT_EQ(Triple::x86_64, T.getArch());
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
@@ -865,6 +875,16 @@
   EXPECT_FALSE(T.isArch32Bit());
   EXPECT_TRUE(T.isArch64Bit());
 
+  T.setArch(Triple::spirv32);
+  EXPECT_FALSE(T.isArch16Bit());
+  EXPECT_TRUE(T.isArch32Bit());
+  EXPECT_FALSE(T.isArch64Bit());
+
+  T.setArch(Triple::spirv64);
+  EXPECT_FALSE(T.isArch16Bit());
+  EXPECT_FALSE(T.isArch32Bit());
+  EXPECT_TRUE(T.isArch64Bit());
+
   T.setArch(Triple::sparc);
   EXPECT_FALSE(T.isArch16Bit());
   EXPECT_TRUE(T.isArch32Bit());
@@ -1000,6 +1020,14 @@
   EXPECT_EQ(Triple::spir, T.get32BitArchVariant().getArch());
   EXPECT_EQ(Triple::spir64, T.get64BitArchVariant().getArch());
 
+  T.setArch(Triple::spirv32);
+  EXPECT_EQ(Triple::spirv32, T.get32BitArchVariant().getArch());
+  EXPECT_EQ(Triple::spirv64, T.get64BitArchVariant().getArch());
+
+  T.setArch(Triple::spirv64);
+  EXPECT_EQ(Triple::spirv32, T.get32BitArchVariant().getArch());
+  EXPECT_EQ(Triple::spirv64, T.get64BitArchVariant().getArch());
+
   T.setArch(Triple::wasm32);
   EXPECT_EQ(Triple::wasm32, T.get32BitArchVariant().getArch());
   EXPECT_EQ(Triple::wasm64, T.get64BitArchVariant().getArch());
Index: llvm/lib/Support/Triple.cpp
===
--- llvm/lib/Support/Triple.cpp
+++ llvm/lib/Support/Triple.cpp
@@ -67,6 +67,8 @@
   case sparcv9:return "sparcv9";
   case spir64: return "spir64";
   case spir:   return "spir";
+  case spirv32:return "spirv32";
+  case spirv64:return "spirv64";
   case systemz:return "s390x";
   case tce:return "tce";
   case tcele:  return "tcele";
@@ -147,6 +149,10 @@
 
   case spir:
   case spir64:  return "spir";
+
+  case spirv32:
+  case spirv64: return "spirv";
+
   case kalimba: return "kalimba";
   case lanai:   return "lanai";
   case shave:   return "shave";
@@ -323,6 +329,8 @@
 .Case("hsail64", hsail64)
 .Case("spir", spir)
 .Case("spir64", spir64)
+.Case("spirv32", spirv32)
+.Case("spirv64", spirv64)
 .Case("kalimba", kalimba)
 .Case("lanai", lanai)
 .Case("shave", shave)
@@ -456,6 +464,8 @@
 .Case("hsail64", Triple::hsail64)
 .Case("spir", Triple::spir)
 .Case("spir64", Triple::spir64)
+.Case("spirv32", Triple::spirv32)
+.Case("spirv64", Triple::spirv64)
 .StartsWith("kalimba", Triple::kalimba)
 .Case("lanai", Triple::lanai)
 .Case("renderscript32", Triple::renderscript32)
@@ -753,6 +763,11 @@
   case Triple::wasm32:
   case Triple::wasm64:
 return Triple::Wasm;
+
+  case Triple::spirv32:
+  case Triple::spirv64:
+// TODO: In future this will be Triple::SPIRV.
+return Triple::UnknownObjectFormat;
   }
   llvm_unreachable("unknown architecture");
 }
@@ -1298,6 +1313,7 @@
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel:
   case llvm::Triple::spir:
+  case llvm::Triple::spirv32:
   case llvm::Triple::tce:
   case llvm::Triple::tcele:
   case llvm::Triple::thumb:
@@ -1324,6 +1340,7 @@
   case llvm::Triple::riscv64:
   case llvm::Triple::sparcv9:
   case llvm::Triple::spir64:
+  case llvm::Triple::spirv64:
   case llvm::Triple::systemz:
   case llvm::Triple::ve:
   case llvm::Triple::wasm64:
@@ -1383,6 +1400,7 @@
   case Triple::sparc:
   case Triple::sparcel:
   case Triple::spir:
+  case Triple::spirv32:
   case Triple::tce:
   case 

[PATCH] D109740: [OpenCL] Add atomic_half type builtins

2021-09-13 Thread Yang Haonan via Phabricator via cfe-commits
haonanya created this revision.
haonanya added reviewers: svenvh, Anastasia.
haonanya added a project: clang.
Herald added subscribers: ldrumm, yaxunl.
haonanya requested review of this revision.
Herald added a subscriber: cfe-commits.

Add atomic_half types and builtins operating on the types


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109740

Files:
  clang/lib/Headers/opencl-c.h
  clang/lib/Sema/OpenCLBuiltins.td
  clang/lib/Sema/Sema.cpp
  clang/test/SemaOpenCL/atomic-ops.cl

Index: clang/test/SemaOpenCL/atomic-ops.cl
===
--- clang/test/SemaOpenCL/atomic-ops.cl
+++ clang/test/SemaOpenCL/atomic-ops.cl
@@ -19,7 +19,7 @@
 
 atomic_int gn;
 void f(atomic_int *i, const atomic_int *ci,
-   atomic_intptr_t *p, atomic_float *f, atomic_double *d, atomic_half *h, // expected-error {{unknown type name 'atomic_half'}}
+   atomic_intptr_t *p, atomic_float *f, atomic_double *d, atomic_half *h,
int *I, const int *CI,
intptr_t *P, float *D, struct S *s1, struct S *s2,
global atomic_int *i_g, local atomic_int *i_l, private atomic_int *i_p,
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -367,6 +367,11 @@
 AddPointerSizeDependentTypes();
   }
 
+ if (getOpenCLOptions().isSupported("cl_khr_fp16", getLangOpts())) {
+auto AtomicHalfT = Context.getAtomicType(Context.HalfTy);
+addImplicitTypedef("atomic_half", AtomicHalfT);
+  }
+
   std::vector Atomic64BitTypes;
   if (getOpenCLOptions().isSupported("cl_khr_int64_base_atomics",
  getLangOpts()) &&
Index: clang/lib/Sema/OpenCLBuiltins.td
===
--- clang/lib/Sema/OpenCLBuiltins.td
+++ clang/lib/Sema/OpenCLBuiltins.td
@@ -85,16 +85,25 @@
 
 def FuncExtOpenCLCPipes  : FunctionExtension<"__opencl_c_pipes">;
 def FuncExtOpenCLCWGCollectiveFunctions  : FunctionExtension<"__opencl_c_work_group_collective_functions">;
+def FuncExtFloatAtomicsFp16GlobalLoadStore  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_global_atomic_load_store">;
+def FuncExtFloatAtomicsFp16LocalLoadStore   : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_local_atomic_load_store">;
+def FuncExtFloatAtomicsFp16GenericLoadStore : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_global_atomic_load_store __opencl_c_ext_fp16_local_atomic_load_store">;
+def FuncExtFloatAtomicsFp16GlobalAdd : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_global_atomic_add">;
 def FuncExtFloatAtomicsFp32GlobalAdd : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_global_atomic_add">;
 def FuncExtFloatAtomicsFp64GlobalAdd : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp64_global_atomic_add">;
+def FuncExtFloatAtomicsFp16LocalAdd  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_local_atomic_add">;
 def FuncExtFloatAtomicsFp32LocalAdd  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_local_atomic_add">;
 def FuncExtFloatAtomicsFp64LocalAdd  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp64_local_atomic_add">;
+def FuncExtFloatAtomicsFp16GenericAdd: FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_local_atomic_add __opencl_c_ext_fp16_global_atomic_add">;
 def FuncExtFloatAtomicsFp32GenericAdd: FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_local_atomic_add __opencl_c_ext_fp32_global_atomic_add">;
 def FuncExtFloatAtomicsFp64GenericAdd: FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp64_local_atomic_add __opencl_c_ext_fp64_global_atomic_add">;
+def FuncExtFloatAtomicsFp16GlobalMinMax  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_global_atomic_min_max">;
 def FuncExtFloatAtomicsFp32GlobalMinMax  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_global_atomic_min_max">;
 def FuncExtFloatAtomicsFp64GlobalMinMax  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp64_global_atomic_min_max">;
+def FuncExtFloatAtomicsFp16LocalMinMax   : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_local_atomic_min_max">;
 def FuncExtFloatAtomicsFp32LocalMinMax   : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_local_atomic_min_max">;
 def FuncExtFloatAtomicsFp64LocalMinMax   : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp64_local_atomic_min_max">;
+def FuncExtFloatAtomicsFp16GenericMinMax : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_local_atomic_min_max __opencl_c_ext_fp16_global_atomic_min_max">;
 def FuncExtFloatAtomicsFp32GenericMinMax : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_local_atomic_min_max __opencl_c_ext_fp32_global_atomic_min_max">;
 def FuncExtFloatAtomicsFp64GenericMinMax : 

[PATCH] D109658: [X86][FP16] Change the order of the operands in complex FMA intrinsics to allow swap between the mul operands.

2021-09-13 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei updated this revision to Diff 372400.
pengfei added a comment.

Allow MI operands of complex FMA to be commutable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109658

Files:
  clang/lib/Headers/avx512fp16intrin.h
  clang/lib/Headers/avx512vlfp16intrin.h
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86InstrAVX512.td
  llvm/lib/Target/X86/X86InstrFragmentsSIMD.td
  llvm/lib/Target/X86/X86InstrInfo.cpp
  llvm/lib/Target/X86/X86IntrinsicsInfo.h
  llvm/test/CodeGen/X86/avx512cfma-intrinsics.ll
  llvm/test/CodeGen/X86/avx512cfmul-intrinsics.ll
  llvm/test/CodeGen/X86/avx512cfmulsh-instrinsics.ll
  llvm/test/CodeGen/X86/avx512fp16-combine-vfmulc-fadd.ll
  llvm/test/CodeGen/X86/avx512fp16-combine-xor-vfmulc-fadd.ll
  llvm/test/CodeGen/X86/stack-folding-fp-avx512fp16.ll
  llvm/test/CodeGen/X86/stack-folding-fp-avx512fp16vl.ll

Index: llvm/test/CodeGen/X86/stack-folding-fp-avx512fp16vl.ll
===
--- llvm/test/CodeGen/X86/stack-folding-fp-avx512fp16vl.ll
+++ llvm/test/CodeGen/X86/stack-folding-fp-avx512fp16vl.ll
@@ -646,7 +646,7 @@
   ;CHECK-LABEL: stack_fold_fmaddc:
   ;CHECK:   vfmaddcph {{-?[0-9]*}}(%rsp), {{%xmm[0-9][0-9]*}}, {{%xmm[0-9][0-9]*}} {{.*#+}} 16-byte Folded Reload
   %1 = tail call <2 x i64> asm sideeffect "nop", "=x,~{xmm3},~{xmm4},~{xmm5},~{xmm6},~{xmm7},~{xmm8},~{xmm9},~{xmm10},~{xmm11},~{xmm12},~{xmm13},~{xmm14},~{xmm15},~{xmm16},~{xmm17},~{xmm18},~{xmm19},~{xmm20},~{xmm21},~{xmm22},~{xmm23},~{xmm24},~{xmm25},~{xmm26},~{xmm27},~{xmm28},~{xmm29},~{xmm30},~{xmm31},~{flags}"()
-  %2 = call <4 x float> @llvm.x86.avx512fp16.mask.vfmadd.cph.128(<4 x float> %a0, <4 x float> %a1, <4 x float> %a2, i8 -1)
+  %2 = call <4 x float> @llvm.x86.avx512fp16.mask.vfmadd.cph.128(<4 x float> %a1, <4 x float> %a2, <4 x float> %a0, i8 -1)
   ret <4 x float> %2
 }
 declare <4 x float> @llvm.x86.avx512fp16.mask.vfmadd.cph.128(<4 x float>, <4 x float>, <4 x float>, i8)
@@ -656,7 +656,7 @@
   ;CHECK:   vfmaddcph {{-?[0-9]*}}(%rsp), {{%xmm[0-9][0-9]*}}, {{%xmm[0-9][0-9]*}} {{{%k[0-7]}}} {{.*#+}} 16-byte Folded Reload
   %1 = tail call <2 x i64> asm sideeffect "nop", "=x,~{xmm2},~{xmm3},~{xmm4},~{xmm5},~{xmm6},~{xmm7},~{xmm8},~{xmm9},~{xmm10},~{xmm11},~{xmm12},~{xmm13},~{xmm14},~{xmm15},~{xmm16},~{xmm17},~{xmm18},~{xmm19},~{xmm20},~{xmm21},~{xmm22},~{xmm23},~{xmm24},~{xmm25},~{xmm26},~{xmm27},~{xmm28},~{xmm29},~{xmm30},~{xmm31},~{flags}"()
   %a0 = load <4 x float>, <4 x float>* %p
-  %2 = call <4 x float> @llvm.x86.avx512fp16.mask.vfmadd.cph.128(<4 x float> %a0, <4 x float> %a1, <4 x float> %a2, i8 %mask)
+  %2 = call <4 x float> @llvm.x86.avx512fp16.mask.vfmadd.cph.128(<4 x float> %a1, <4 x float> %a2, <4 x float> %a0, i8 %mask)
   ret <4 x float> %2
 }
 
@@ -665,7 +665,7 @@
   ;CHECK:   vfmaddcph {{-?[0-9]*}}(%rsp), {{%xmm[0-9][0-9]*}}, {{%xmm[0-9][0-9]*}} {{{%k[0-7]}}} {z} {{.*#+}} 16-byte Folded Reload
   %1 = tail call <2 x i64> asm sideeffect "nop", "=x,~{xmm2},~{xmm3},~{xmm4},~{xmm5},~{xmm6},~{xmm7},~{xmm8},~{xmm9},~{xmm10},~{xmm11},~{xmm12},~{xmm13},~{xmm14},~{xmm15},~{xmm16},~{xmm17},~{xmm18},~{xmm19},~{xmm20},~{xmm21},~{xmm22},~{xmm23},~{xmm24},~{xmm25},~{xmm26},~{xmm27},~{xmm28},~{xmm29},~{xmm30},~{xmm31},~{flags}"()
   %2 = load i8, i8* %mask
-  %3 = call <4 x float> @llvm.x86.avx512fp16.mask.vfmadd.cph.128(<4 x float> zeroinitializer, <4 x float> %a1, <4 x float> %a2, i8 %2)
+  %3 = call <4 x float> @llvm.x86.avx512fp16.mask.vfmadd.cph.128(<4 x float> %a1, <4 x float> %a2, <4 x float> zeroinitializer, i8 %2)
   ret <4 x float> %3
 }
 declare <4 x float> @llvm.x86.avx512fp16.maskz.vfmadd.cph.128(<4 x float>, <4 x float>, <4 x float>, i8)
@@ -674,7 +674,7 @@
   ;CHECK-LABEL: stack_fold_fcmaddc:
   ;CHECK:   vfcmaddcph {{-?[0-9]*}}(%rsp), {{%xmm[0-9][0-9]*}}, {{%xmm[0-9][0-9]*}} {{.*#+}} 16-byte Folded Reload
   %1 = tail call <2 x i64> asm sideeffect "nop", "=x,~{xmm3},~{xmm4},~{xmm5},~{xmm6},~{xmm7},~{xmm8},~{xmm9},~{xmm10},~{xmm11},~{xmm12},~{xmm13},~{xmm14},~{xmm15},~{xmm16},~{xmm17},~{xmm18},~{xmm19},~{xmm20},~{xmm21},~{xmm22},~{xmm23},~{xmm24},~{xmm25},~{xmm26},~{xmm27},~{xmm28},~{xmm29},~{xmm30},~{xmm31},~{flags}"()
-  %2 = call <4 x float> @llvm.x86.avx512fp16.mask.vfcmadd.cph.128(<4 x float> %a0, <4 x float> %a1, <4 x float> %a2, i8 -1)
+  %2 = call <4 x float> @llvm.x86.avx512fp16.mask.vfcmadd.cph.128(<4 x float> %a1, <4 x float> %a2, <4 x float> %a0, i8 -1)
   ret <4 x float> %2
 }
 declare <4 x float> @llvm.x86.avx512fp16.mask.vfcmadd.cph.128(<4 x float>, <4 x float>, <4 x float>, i8)
@@ -684,7 +684,7 @@
   ;CHECK:   vfcmaddcph {{-?[0-9]*}}(%rsp), {{%xmm[0-9][0-9]*}}, {{%xmm[0-9][0-9]*}} {{{%k[0-7]}}} {{.*#+}} 16-byte Folded Reload
   %1 = tail call <2 x i64> asm sideeffect "nop", 

[PATCH] D36850: [ThinLTO] Add norecurse function attribute propagation

2021-09-13 Thread Di Mo via Phabricator via cfe-commits
modimo updated this revision to Diff 372398.
modimo added a comment.

Add mayThrow flag


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D36850

Files:
  clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
  clang/test/CodeGen/thinlto-distributed-cfi.ll
  clang/test/CodeGen/thinlto-funcattr-prop.ll
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/IR/GlobalValue.h
  llvm/include/llvm/IR/ModuleSummaryIndex.h
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/Transforms/IPO/FunctionAttrs.h
  llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/ModuleSummaryIndex.cpp
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/lib/Transforms/IPO/FunctionAttrs.cpp
  llvm/test/Assembler/thinlto-summary.ll
  llvm/test/Bitcode/thinlto-function-summary-refgraph.ll
  llvm/test/Bitcode/thinlto-type-vcalls.ll
  llvm/test/ThinLTO/X86/deadstrip.ll
  llvm/test/ThinLTO/X86/dot-dumper.ll
  llvm/test/ThinLTO/X86/dot-dumper2.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-exported-internal.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-indirect.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-undefined.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-weak.ll
  llvm/test/ThinLTO/X86/funcattrs-prop.ll
  llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
  llvm/test/ThinLTO/X86/function_entry_count.ll
  llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll

Index: llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
===
--- llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
+++ llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
@@ -3,15 +3,17 @@
 ; verification error.
 ; RUN: opt -module-summary %s -o %t1.bc
 ; RUN: opt -module-summary %p/Inputs/linkonce_resolution_comdat.ll -o %t2.bc
-; RUN: llvm-lto -thinlto-action=run %t1.bc %t2.bc -exported-symbol=f -exported-symbol=g -thinlto-save-temps=%t3.
+; RUN: llvm-lto -thinlto-action=run -disable-thinlto-funcattrs=0 %t1.bc %t2.bc -exported-symbol=f -exported-symbol=g -thinlto-save-temps=%t3.
 
 ; RUN: llvm-dis %t3.0.3.imported.bc -o - | FileCheck %s --check-prefix=IMPORT1
 ; RUN: llvm-dis %t3.1.3.imported.bc -o - | FileCheck %s --check-prefix=IMPORT2
 ; Copy from first module is prevailing and converted to weak_odr, copy
 ; from second module is preempted and converted to available_externally and
 ; removed from comdat.
-; IMPORT1: define weak_odr i32 @f(i8* %0) unnamed_addr comdat($c1) {
-; IMPORT2: define available_externally i32 @f(i8* %0) unnamed_addr {
+; IMPORT1: define weak_odr i32 @f(i8* %0) unnamed_addr [[ATTR:#[0-9]+]] comdat($c1) {
+; IMPORT2: define available_externally i32 @f(i8* %0) unnamed_addr [[ATTR:#[0-9]+]] {
+
+; CHECK-DAG: attributes [[ATTR]] = { norecurse nounwind }
 
 ; RUN: llvm-nm -o - < %t1.bc.thinlto.o | FileCheck %s --check-prefix=NM1
 ; NM1: W f
Index: llvm/test/ThinLTO/X86/function_entry_count.ll
===
--- llvm/test/ThinLTO/X86/function_entry_count.ll
+++ llvm/test/ThinLTO/X86/function_entry_count.ll
@@ -2,7 +2,7 @@
 ; RUN: opt -thinlto-bc %p/Inputs/function_entry_count.ll -write-relbf-to-summary -thin-link-bitcode-file=%t2.thinlink.bc -o %t2.bc
 
 ; First perform the thin link on the normal bitcode file.
-; RUN: llvm-lto2 run %t1.bc %t2.bc -o %t.o -save-temps -thinlto-synthesize-entry-counts \
+; RUN: llvm-lto2 run %t1.bc %t2.bc -o %t.o -save-temps -disable-thinlto-funcattrs=0 -thinlto-synthesize-entry-counts \
 ; RUN: -r=%t1.bc,g, \
 ; RUN: -r=%t1.bc,f,px \
 ; RUN: -r=%t1.bc,h,px \
@@ -10,15 +10,16 @@
 ; RUN: -r=%t2.bc,g,px
 ; RUN: llvm-dis -o - %t.o.1.3.import.bc | FileCheck %s
 
-; RUN: llvm-lto -thinlto-action=run -thinlto-synthesize-entry-counts -exported-symbol=f \
+; RUN: llvm-lto -thinlto-action=run -disable-thinlto-funcattrs=0 -thinlto-synthesize-entry-counts -exported-symbol=f \
 ; RUN: -exported-symbol=g -exported-symbol=h -thinlto-save-temps=%t3. %t1.bc %t2.bc
 ; RUN: llvm-dis %t3.0.3.imported.bc -o - | FileCheck %s
 
-; CHECK: define void @h() !prof ![[PROF2:[0-9]+]]
-; CHECK: define void @f(i32{{.*}}) !prof ![[PROF1:[0-9]+]]
+; CHECK: define void @h() [[ATTR:#[0-9]+]] !prof ![[PROF2:[0-9]+]]
+; CHECK: define void @f(i32{{.*}}) [[ATTR:#[0-9]+]] !prof ![[PROF1:[0-9]+]]
 ; CHECK: define available_externally void @g() !prof ![[PROF2]]
 ; CHECK-DAG: ![[PROF1]] = !{!"synthetic_function_entry_count", i64 10}
 ; CHECK-DAG: ![[PROF2]] = !{!"synthetic_function_entry_count", i64 198}
+; CHECK-DAG: attributes [[ATTR]] = { norecurse nounwind }
 
 target triple = "x86_64-unknown-linux-gnu"
 target datalayout = 

[clang] 2bd8493 - Improve type printing of const arrays to normalize array-of-const and const-array

2021-09-13 Thread David Blaikie via cfe-commits

Author: David Blaikie
Date: 2021-09-13T19:17:05-07:00
New Revision: 2bd84938470bf2e337801faafb8a67710f46429d

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

LOG: Improve type printing of const arrays to normalize array-of-const and 
const-array

Since these map to the same effective type - render them the same/in the
more legible way (const x[n]).

Added: 


Modified: 
clang/lib/AST/TypePrinter.cpp
clang/test/ARCMT/cxx-checking.mm
clang/test/AST/ast-dump-APValue-arithmetic.cpp
clang/test/AST/ast-dump-APValue-array.cpp
clang/test/CXX/basic/basic.types/p10.cpp
clang/test/Sema/assign.c
clang/test/Sema/typedef-retain.c
clang/test/SemaCXX/reinterpret-cast.cpp
clang/test/SemaCXX/static-assert-cxx17.cpp

Removed: 




diff  --git a/clang/lib/AST/TypePrinter.cpp b/clang/lib/AST/TypePrinter.cpp
index aef1e4f3f4953..251db97c7db08 100644
--- a/clang/lib/AST/TypePrinter.cpp
+++ b/clang/lib/AST/TypePrinter.cpp
@@ -200,11 +200,12 @@ bool TypePrinter::canPrefixQualifiers(const Type *T,
   // type expands to a simple string.
   bool CanPrefixQualifiers = false;
   NeedARCStrongQualifier = false;
-  Type::TypeClass TC = T->getTypeClass();
+  const Type *UnderlyingType = T;
   if (const auto *AT = dyn_cast(T))
-TC = AT->desugar()->getTypeClass();
+UnderlyingType = AT->desugar().getTypePtr();
   if (const auto *Subst = dyn_cast(T))
-TC = Subst->getReplacementType()->getTypeClass();
+UnderlyingType = Subst->getReplacementType().getTypePtr();
+  Type::TypeClass TC = UnderlyingType->getTypeClass();
 
   switch (TC) {
 case Type::Auto:
@@ -243,6 +244,9 @@ bool TypePrinter::canPrefixQualifiers(const Type *T,
 
 case Type::ConstantArray:
 case Type::IncompleteArray:
+  return canPrefixQualifiers(
+  cast(UnderlyingType)->getElementType().getTypePtr(),
+  NeedARCStrongQualifier);
 case Type::VariableArray:
 case Type::DependentSizedArray:
   NeedARCStrongQualifier = true;

diff  --git a/clang/test/ARCMT/cxx-checking.mm 
b/clang/test/ARCMT/cxx-checking.mm
index 952f3cdcbb79c..d6441def09b40 100644
--- a/clang/test/ARCMT/cxx-checking.mm
+++ b/clang/test/ARCMT/cxx-checking.mm
@@ -80,7 +80,7 @@
 
 struct FlexibleArrayMember0 {
   int length;
-  id array[]; // expected-error{{flexible array member 'array' of type 'id 
__strong[]' with non-trivial destruction}}
+  id array[]; // expected-error{{flexible array member 'array' of type 
'__strong id []' with non-trivial destruction}}
 };
 
 struct FlexibleArrayMember1 {

diff  --git a/clang/test/AST/ast-dump-APValue-arithmetic.cpp 
b/clang/test/AST/ast-dump-APValue-arithmetic.cpp
index 835d8c8108346..e51c1cee04cfe 100644
--- a/clang/test/AST/ast-dump-APValue-arithmetic.cpp
+++ b/clang/test/AST/ast-dump-APValue-arithmetic.cpp
@@ -36,13 +36,13 @@ void Test() {
   // CHECK-NEXT:  |   |-value: ComplexFloat 3.141500e+00 + 4.20e+01i
 
   constexpr _Complex int ArrayOfComplexInt[10] = {ComplexInt, ComplexInt, 
ComplexInt, ComplexInt};
-  // CHECK:  | `-VarDecl {{.*}}  col:{{.*}} 
ArrayOfComplexInt '_Complex int const[10]' constexpr cinit
+  // CHECK:  | `-VarDecl {{.*}}  col:{{.*}} 
ArrayOfComplexInt 'const _Complex int [10]' constexpr cinit
   // CHECK-NEXT:  |   |-value: Array size=10
   // CHECK-NEXT:  |   | |-elements: ComplexInt 42 + 24i, ComplexInt 42 + 24i, 
ComplexInt 42 + 24i, ComplexInt 42 + 24i
   // CHECK-NEXT:  |   | `-filler: 6 x ComplexInt 0 + 0i
 
   constexpr _Complex float ArrayOfComplexFloat[10] = {ComplexFloat, 
ComplexFloat, ComplexInt, ComplexInt};
-  // CHECK:`-VarDecl {{.*}}  col:{{.*}} 
ArrayOfComplexFloat '_Complex float const[10]' constexpr cinit
+  // CHECK:`-VarDecl {{.*}}  col:{{.*}} 
ArrayOfComplexFloat 'const _Complex float [10]' constexpr cinit
   // CHECK-NEXT:  |-value: Array size=10
   // CHECK-NEXT:  | |-elements: ComplexFloat 3.141500e+00 + 4.20e+01i, 
ComplexFloat 3.141500e+00 + 4.20e+01i, ComplexFloat 4.20e+01 + 
2.40e+01i, ComplexFloat 4.20e+01 + 2.40e+01i
   // CHECK-NEXT:  | `-filler: 6 x ComplexFloat 0.00e+00 + 0.00e+00i

diff  --git a/clang/test/AST/ast-dump-APValue-array.cpp 
b/clang/test/AST/ast-dump-APValue-array.cpp
index f9b38ec332a5b..72e519208ac56 100644
--- a/clang/test/AST/ast-dump-APValue-array.cpp
+++ b/clang/test/AST/ast-dump-APValue-array.cpp
@@ -43,7 +43,7 @@ void Test() {
   constexpr float arr_f[3][5] = {
   {1, 2, 3, 4, 5},
   };
-  // CHECK:  | `-VarDecl {{.*}}  line:{{.*}} arr_f 
'float const[3][5]' constexpr cinit
+  // CHECK:  | `-VarDecl {{.*}}  line:{{.*}} arr_f 
'const float [3][5]' constexpr cinit
   // CHECK-NEXT:  |   |-value: Array size=3
   // CHECK-NEXT:  |   | |-element: Array size=5
   // CHECK-NEXT:  |   | | |-elements: Float 1.00e+00, 

[PATCH] D108243: Put code that avoids heapifying local blocks behind a flag

2021-09-13 Thread Walter Lee via Phabricator via cfe-commits
waltl updated this revision to Diff 372383.
waltl added a comment.

Mark new option as NoDriverOption


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108243

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGObjC.cpp
  clang/test/CodeGenObjC/arc-block-copy-escape.m
  clang/test/CodeGenObjC/arc-blocks.m
  clang/test/CodeGenObjCXX/arc-blocks.mm
  clang/test/PCH/arc-blocks.mm

Index: clang/test/PCH/arc-blocks.mm
===
--- clang/test/PCH/arc-blocks.mm
+++ clang/test/PCH/arc-blocks.mm
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fobjc-arc -fblocks -std=c++1y -emit-pch %s -o %t
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fobjc-arc -fblocks -std=c++1y -include-pch %t -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fobjc-arc -fblocks -std=c++1y -include-pch %t -fobjc-avoid-heapify-local-blocks -emit-llvm -o - %s | FileCheck %s
 
 #ifndef HEADER_INCLUDED
 #define HEADER_INCLUDED
Index: clang/test/CodeGenObjCXX/arc-blocks.mm
===
--- clang/test/CodeGenObjCXX/arc-blocks.mm
+++ clang/test/CodeGenObjCXX/arc-blocks.mm
@@ -1,9 +1,11 @@
 // RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -fexceptions -fobjc-arc-exceptions -o - %s | FileCheck -check-prefix CHECK %s
 // RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -fexceptions -fobjc-arc-exceptions -O1 -o - %s | FileCheck -check-prefix CHECK-O1 %s
 // RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -o - %s | FileCheck -check-prefix CHECK-NOEXCP %s
+// RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -fexceptions -fobjc-arc-exceptions -fobjc-avoid-heapify-local-blocks -o - %s | FileCheck -check-prefix CHECK-NOHEAP %s
 
 // CHECK: [[A:.*]] = type { i64, [10 x i8*] }
 // CHECK: %[[STRUCT_BLOCK_DESCRIPTOR:.*]] = type { i64, i64 }
+// CHECK-NOHEAP: %[[STRUCT_BLOCK_DESCRIPTOR:.*]] = type { i64, i64 }
 // CHECK: %[[STRUCT_TEST1_S0:.*]] = type { i32 }
 // CHECK: %[[STRUCT_TRIVIAL_INTERNAL:.*]] = type { i32 }
 
@@ -209,8 +211,8 @@
 
 namespace test_block_retain {
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain14initializationEP11objc_object(
-// CHECK-NOT: @llvm.objc.retainBlock(
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain14initializationEP11objc_object(
+// CHECK-NOHEAP-NOT: @llvm.objc.retainBlock(
   void initialization(id a) {
 BlockTy b0 = ^{ foo1(a); };
 BlockTy b1 = (^{ foo1(a); });
@@ -218,23 +220,23 @@
 b1();
   }
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain20initializationStaticEP11objc_object(
-// CHECK: @llvm.objc.retainBlock(
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain20initializationStaticEP11objc_object(
+// CHECK-NOHEAP: @llvm.objc.retainBlock(
   void initializationStatic(id a) {
 static BlockTy b0 = ^{ foo1(a); };
 b0();
   }
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain15initialization2EP11objc_object
-// CHECK: %[[B0:.*]] = alloca void ()*, align 8
-// CHECK: %[[B1:.*]] = alloca void ()*, align 8
-// CHECK: load void ()*, void ()** %[[B0]], align 8
-// CHECK-NOT: @llvm.objc.retainBlock
-// CHECK: %[[V9:.*]] = load void ()*, void ()** %[[B0]], align 8
-// CHECK: %[[V10:.*]] = bitcast void ()* %[[V9]] to i8*
-// CHECK: %[[V11:.*]] = call i8* @llvm.objc.retainBlock(i8* %[[V10]])
-// CHECK: %[[V12:.*]] = bitcast i8* %[[V11]] to void ()*
-// CHECK: store void ()* %[[V12]], void ()** %[[B1]], align 8
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain15initialization2EP11objc_object
+// CHECK-NOHEAP: %[[B0:.*]] = alloca void ()*, align 8
+// CHECK-NOHEAP: %[[B1:.*]] = alloca void ()*, align 8
+// CHECK-NOHEAP: load void ()*, void ()** %[[B0]], align 8
+// CHECK-NOHEAP-NOT: @llvm.objc.retainBlock
+// CHECK-NOHEAP: %[[V9:.*]] = load void ()*, void ()** %[[B0]], align 8
+// CHECK-NOHEAP: %[[V10:.*]] = bitcast void ()* %[[V9]] to i8*
+// CHECK-NOHEAP: %[[V11:.*]] = call i8* @llvm.objc.retainBlock(i8* %[[V10]])
+// CHECK-NOHEAP: %[[V12:.*]] = bitcast i8* %[[V11]] to void ()*
+// CHECK-NOHEAP: store void ()* %[[V12]], void ()** %[[B1]], align 8
   void initialization2(id a) {
 BlockTy b0 = ^{ foo1(a); };
 b0();
@@ -242,8 +244,8 @@
 b1();
   }
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain10assignmentEP11objc_object(
-// CHECK-NOT: @llvm.objc.retainBlock(
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain10assignmentEP11objc_object(
+// CHECK-NOHEAP-NOT: @llvm.objc.retainBlock(
   void assignment(id a) {
 BlockTy 

[PATCH] D106343: [OpenCL] Support cl_ext_float_atomics

2021-09-13 Thread Yang Haonan via Phabricator via cfe-commits
haonanya added a comment.

Hi, svenvh. 
I am ok with the patch. Thanks very much.
I'd appreciate it if you help review 
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/1116 as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106343

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


[PATCH] D109710: [PowerPC] Add range checks for P10 Vector Builtins

2021-09-13 Thread Amy Kwan via Phabricator via cfe-commits
amyk added a comment.

`builtins-ppc-p10vector.c` looks like it needs to be updated from the failing 
test case.




Comment at: clang/test/CodeGen/builtins-ppc-p10vector.c:1373
 vector signed int test_vec_vec_splati_ins_si(void) {
+  // CHECK-BE: [[T0:%.+]]] = and %{{.+}}, i32 1
   // CHECK-BE: insertelement <4 x i32> %{{.+}}, i32 %{{.+}}, i32 %{{.+}}

Is the `i32` supposed to be on the first argument?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109710

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


[PATCH] D109624: [clang] Make the driver not diagnose errors on nonexistent linker inputs

2021-09-13 Thread Petr Hosek via Phabricator via cfe-commits
phosek added a comment.

In D109624#2998774 , @saghir wrote:

> In D109624#2998665 , @thakis wrote:
>
>> In D109624#2998550 , @saghir wrote:
>>
>>> Hi, this change also breaks Power PC bots:
>>>
>>> 1. 
>>> https://lab.llvm.org/buildbot/#/builders/19/builds/6451/steps/24/logs/stdio
>>> 2. 
>>> https://lab.llvm.org/buildbot/#/builders/18/builds/2443/steps/23/logs/stdio
>>>
>>> It fails consistently on our bots. Can you please take a look?
>>>
>>> Thanks!
>>
>> This will hopefully be better after b7bac5a172e51ed065b3b4dc64cc2d8831e8081c 
>> .
>
> Yes, my local build succeeded. One of the bots is green already, and the 
> other one is building but should be fine too. Thanks for the prompt fix!

Our builders went back to green as well, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109624

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


[PATCH] D109624: [clang] Make the driver not diagnose errors on nonexistent linker inputs

2021-09-13 Thread Ahsan Saghir via Phabricator via cfe-commits
saghir added a comment.

In D109624#2998665 , @thakis wrote:

> In D109624#2998550 , @saghir wrote:
>
>> Hi, this change also breaks Power PC bots:
>>
>> 1. 
>> https://lab.llvm.org/buildbot/#/builders/19/builds/6451/steps/24/logs/stdio
>> 2. 
>> https://lab.llvm.org/buildbot/#/builders/18/builds/2443/steps/23/logs/stdio
>>
>> It fails consistently on our bots. Can you please take a look?
>>
>> Thanks!
>
> This will hopefully be better after b7bac5a172e51ed065b3b4dc64cc2d8831e8081c 
> .

Yes, my local build succeeded. One of the bots is green already, and the other 
one is building but should be fine too. Thanks for the prompt fix!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109624

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


[PATCH] D109681: [RISCV] add Half-precision test for vle/vse

2021-09-13 Thread Shao-Ce Sun 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 rGd4f25d0046fc: [RISCV] add Half-precision test for vle/vse 
(authored by achieveartificialintelligence).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109681

Files:
  clang/test/CodeGen/RISCV/rvv-intrinsics/vle.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vse.c

Index: clang/test/CodeGen/RISCV/rvv-intrinsics/vse.c
===
--- clang/test/CodeGen/RISCV/rvv-intrinsics/vse.c
+++ clang/test/CodeGen/RISCV/rvv-intrinsics/vse.c
@@ -1195,3 +1195,63 @@
 void test_vse16_v_f16m8(_Float16 *base, vfloat16m8_t value, size_t vl) {
   return vse16_v_f16m8(base, value, vl);
 }
+
+// CHECK-RV64-LABEL: @test_vse16_v_f16mf4_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:call void @llvm.riscv.vse.mask.nxv1f16.i64( [[VALUE:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret void
+//
+void test_vse16_v_f16mf4_m (vbool64_t mask, _Float16 *base, vfloat16mf4_t value, size_t vl) {
+  return vse16_v_f16mf4_m (mask, base, value, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vse16_v_f16mf2_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:call void @llvm.riscv.vse.mask.nxv2f16.i64( [[VALUE:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret void
+//
+void test_vse16_v_f16mf2_m (vbool32_t mask, _Float16 *base, vfloat16mf2_t value, size_t vl) {
+  return vse16_v_f16mf2_m (mask, base, value, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vse16_v_f16m1_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:call void @llvm.riscv.vse.mask.nxv4f16.i64( [[VALUE:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret void
+//
+void test_vse16_v_f16m1_m (vbool16_t mask, _Float16 *base, vfloat16m1_t value, size_t vl) {
+  return vse16_v_f16m1_m (mask, base, value, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vse16_v_f16m2_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:call void @llvm.riscv.vse.mask.nxv8f16.i64( [[VALUE:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret void
+//
+void test_vse16_v_f16m2_m (vbool8_t mask, _Float16 *base, vfloat16m2_t value, size_t vl) {
+  return vse16_v_f16m2_m (mask, base, value, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vse16_v_f16m4_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:call void @llvm.riscv.vse.mask.nxv16f16.i64( [[VALUE:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret void
+//
+void test_vse16_v_f16m4_m (vbool4_t mask, _Float16 *base, vfloat16m4_t value, size_t vl) {
+  return vse16_v_f16m4_m (mask, base, value, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vse16_v_f16m8_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:call void @llvm.riscv.vse.mask.nxv32f16.i64( [[VALUE:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret void
+//
+void test_vse16_v_f16m8_m (vbool2_t mask, _Float16 *base, vfloat16m8_t value, size_t vl) {
+  return vse16_v_f16m8_m (mask, base, value, vl);
+}
Index: clang/test/CodeGen/RISCV/rvv-intrinsics/vle.c
===
--- clang/test/CodeGen/RISCV/rvv-intrinsics/vle.c
+++ clang/test/CodeGen/RISCV/rvv-intrinsics/vle.c
@@ -1195,3 +1195,63 @@
 vfloat16m8_t test_vle16_v_f16m8(const _Float16 *base, size_t vl) {
   return vle16_v_f16m8(base, vl);
 }
+
+// CHECK-RV64-LABEL: @test_vle16_v_f16mf4_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = call  @llvm.riscv.vle.mask.nxv1f16.i64( [[MASKEDOFF:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP1]]
+//
+vfloat16mf4_t test_vle16_v_f16mf4_m (vbool64_t mask, vfloat16mf4_t maskedoff, const _Float16 *base, size_t vl) {
+  return vle16_v_f16mf4_m (mask, maskedoff, base, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vle16_v_f16mf2_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = call  @llvm.riscv.vle.mask.nxv2f16.i64( [[MASKEDOFF:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP1]]
+//
+vfloat16mf2_t test_vle16_v_f16mf2_m (vbool32_t mask, vfloat16mf2_t maskedoff, const _Float16 *base, size_t vl) {
+  return vle16_v_f16mf2_m (mask, maskedoff, base, vl);
+}
+
+// CHECK-RV64-LABEL: 

[clang] d4f25d0 - [RISCV] add Half-precision test for vle/vse

2021-09-13 Thread Shao-Ce Sun via cfe-commits

Author: Shao-Ce Sun
Date: 2021-09-14T08:55:22+08:00
New Revision: d4f25d0046fc9d1a42d9974e75cfba14ff3d535e

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

LOG: [RISCV] add Half-precision test for vle/vse

Reviewed By: craig.topper

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

Added: 


Modified: 
clang/test/CodeGen/RISCV/rvv-intrinsics/vle.c
clang/test/CodeGen/RISCV/rvv-intrinsics/vse.c

Removed: 




diff  --git a/clang/test/CodeGen/RISCV/rvv-intrinsics/vle.c 
b/clang/test/CodeGen/RISCV/rvv-intrinsics/vle.c
index 3e9c6c0e3412c..9da035126fd99 100644
--- a/clang/test/CodeGen/RISCV/rvv-intrinsics/vle.c
+++ b/clang/test/CodeGen/RISCV/rvv-intrinsics/vle.c
@@ -1195,3 +1195,63 @@ vfloat16m4_t test_vle16_v_f16m4(const _Float16 *base, 
size_t vl) {
 vfloat16m8_t test_vle16_v_f16m8(const _Float16 *base, size_t vl) {
   return vle16_v_f16m8(base, vl);
 }
+
+// CHECK-RV64-LABEL: @test_vle16_v_f16mf4_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = call  
@llvm.riscv.vle.mask.nxv1f16.i64( [[MASKEDOFF:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP1]]
+//
+vfloat16mf4_t test_vle16_v_f16mf4_m (vbool64_t mask, vfloat16mf4_t maskedoff, 
const _Float16 *base, size_t vl) {
+  return vle16_v_f16mf4_m (mask, maskedoff, base, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vle16_v_f16mf2_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = call  
@llvm.riscv.vle.mask.nxv2f16.i64( [[MASKEDOFF:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP1]]
+//
+vfloat16mf2_t test_vle16_v_f16mf2_m (vbool32_t mask, vfloat16mf2_t maskedoff, 
const _Float16 *base, size_t vl) {
+  return vle16_v_f16mf2_m (mask, maskedoff, base, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vle16_v_f16m1_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = call  
@llvm.riscv.vle.mask.nxv4f16.i64( [[MASKEDOFF:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP1]]
+//
+vfloat16m1_t test_vle16_v_f16m1_m (vbool16_t mask, vfloat16m1_t maskedoff, 
const _Float16 *base, size_t vl) {
+  return vle16_v_f16m1_m (mask, maskedoff, base, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vle16_v_f16m2_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = call  
@llvm.riscv.vle.mask.nxv8f16.i64( [[MASKEDOFF:%.*]], * [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP1]]
+//
+vfloat16m2_t test_vle16_v_f16m2_m (vbool8_t mask, vfloat16m2_t maskedoff, 
const _Float16 *base, size_t vl) {
+  return vle16_v_f16m2_m (mask, maskedoff, base, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vle16_v_f16m4_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = call  
@llvm.riscv.vle.mask.nxv16f16.i64( [[MASKEDOFF:%.*]], 
* [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP1]]
+//
+vfloat16m4_t test_vle16_v_f16m4_m (vbool4_t mask, vfloat16m4_t maskedoff, 
const _Float16 *base, size_t vl) {
+  return vle16_v_f16m4_m (mask, maskedoff, base, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vle16_v_f16m8_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = call  
@llvm.riscv.vle.mask.nxv32f16.i64( [[MASKEDOFF:%.*]], 
* [[TMP0]],  [[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP1]]
+//
+vfloat16m8_t test_vle16_v_f16m8_m (vbool2_t mask, vfloat16m8_t maskedoff, 
const _Float16 *base, size_t vl) {
+  return vle16_v_f16m8_m (mask, maskedoff, base, vl);
+}

diff  --git a/clang/test/CodeGen/RISCV/rvv-intrinsics/vse.c 
b/clang/test/CodeGen/RISCV/rvv-intrinsics/vse.c
index cdf62055c2b41..23ad316fb90ed 100644
--- a/clang/test/CodeGen/RISCV/rvv-intrinsics/vse.c
+++ b/clang/test/CodeGen/RISCV/rvv-intrinsics/vse.c
@@ -1195,3 +1195,63 @@ void test_vse16_v_f16m4(_Float16 *base, vfloat16m4_t 
value, size_t vl) {
 void test_vse16_v_f16m8(_Float16 *base, vfloat16m8_t value, size_t vl) {
   return vse16_v_f16m8(base, value, vl);
 }
+
+// CHECK-RV64-LABEL: @test_vse16_v_f16mf4_m(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = bitcast half* [[BASE:%.*]] to *
+// CHECK-RV64-NEXT:call void @llvm.riscv.vse.mask.nxv1f16.i64( [[VALUE:%.*]], * [[TMP0]],  
[[MASK:%.*]], i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret void
+//
+void test_vse16_v_f16mf4_m (vbool64_t mask, _Float16 *base, vfloat16mf4_t 
value, size_t 

[PATCH] D109703: [DebugInfo] Fix scope for local static variables

2021-09-13 Thread Ellis Hoag via Phabricator via cfe-commits
ellis added a comment.

In D109703#2998350 , @krisb wrote:

> In D109703#2998155 , @ellis wrote:
>
>> I've added this to the added test case.
>>
>>   !18 = !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !4, 
>> entity: !19, line: 122)
>>   !19 = !DIGlobalVariable(name: "imported_static_var", scope: !6, file: !5, 
>> line: 3, type: !10, isLocal: false, isDefinition: true)
>
> Thank you for pointing to this! Just in case, do you have a C++ example, that 
> reproduces the issue with imported static local declaration? I'm asking, 
> cause in your example `DW_TAG_imported_declaration` has CU as a scope, while 
> `DIGlobalVariable` is function-scoped. This looks a bit strange. I mean, 
> `constructImportedEntityDIE()` called from `DwarfDebug::beginModule()` skips 
> all local-scoped entities, and unless I'm missing something static locals 
> shouldn't go here. Another call for  `constructImportedEntityDIE()` is from 
> `DwarfCompileUnit::createScopeChildrenDIE` where I'd not expect any issue 
> with parents.

No, I designed the test to hit that code path, but I should have found a C++ 
example to back it up. Thanks for looking into this!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109703

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


[PATCH] D109658: [X86][FP16] Change the order of the operands in complex FMA intrinsics to allow swap between the mul operands.

2021-09-13 Thread LuoYuanke via Phabricator via cfe-commits
LuoYuanke added a comment.

It seems in this patch the builtins interface is aligned to intrinsics 
interface. Since AVX512FP16 is pretty new, I assume nobody is using the GCC 
builtin. Can we ask GCC guys change their builtin interface?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109658

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


[PATCH] D109557: Adds an AlignCloseBracket option

2021-09-13 Thread Cameron Mulhern via Phabricator via cfe-commits
csmulhern added a comment.

In D109557#2998213 , 
@HazardyKnusperkeks wrote:

> With context he meant the diff context. 
> https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface

Ah sorry about that. Done.

In D109557#2998226 , 
@HazardyKnusperkeks wrote:

> You state in the documentation that it is also for angle brackets and more, 
> but there are no test cases for that.

Yeah, I wasn't sure exactly how to deal with this. The default behavior is 
already to align angle brackets and braces on newlines. See: 
https://github.com/llvm/llvm-project/blob/8a780a2f18c590e27e51a2ab3cc81b481c42b42a/clang/lib/Format/ContinuationIndenter.cpp#L341
 (BreakBeforeClosingBrace is true when the block was started with a newline). 
Thus, you're already getting this behavior when CBAS_AlwaysBreak is set. I 
didn't want to make DontAlign (the default) explicitly opt out of this 
behavior. I guess we can narrow the scope of CloseBracketAlignmentStyle to just 
parenthesis, but that doesn't feel great either. What are your thoughts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109557

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


[PATCH] D108421: Mark openmp internal global dso_local

2021-09-13 Thread kamlesh kumar via Phabricator via cfe-commits
kamleshbhalui added a comment.

ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108421

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


[PATCH] D109557: Adds an AlignCloseBracket option

2021-09-13 Thread Cameron Mulhern via Phabricator via cfe-commits
csmulhern updated this revision to Diff 372364.
csmulhern added a comment.

Adds more context to the diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109557

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/ContinuationIndenter.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -18507,6 +18507,12 @@
   CHECK_PARSE("AlignAfterOpenBracket: true", AlignAfterOpenBracket,
   FormatStyle::BAS_Align);
 
+  Style.AlignCloseBracket = FormatStyle::CBAS_AlwaysBreak;
+  CHECK_PARSE("AlignCloseBracket: DontAlign", AlignCloseBracket,
+  FormatStyle::CBAS_DontAlign);
+  CHECK_PARSE("AlignCloseBracket: AlwaysBreak", AlignCloseBracket,
+  FormatStyle::CBAS_AlwaysBreak);
+
   Style.AlignEscapedNewlines = FormatStyle::ENAS_Left;
   CHECK_PARSE("AlignEscapedNewlines: DontAlign", AlignEscapedNewlines,
   FormatStyle::ENAS_DontAlign);
@@ -22288,6 +22294,94 @@
   "}";
   EXPECT_EQ(Code, format(Code, Style));
 }
+
+TEST_F(FormatTest, AlignCloseBracket) {
+  auto Style = getLLVMStyle();
+  Style.AlignCloseBracket = FormatStyle::CBAS_AlwaysBreak;
+  StringRef Short = "functionCall(paramA, paramB, paramC);\n"
+"void functionDecl(int a, int b, int c);";
+
+  StringRef Medium = "functionCall(paramA, paramB, paramC, paramD, paramE, "
+ "paramF, paramG, paramH, paramI);\n"
+ "void functionDecl(int argumentA, int argumentB, int "
+ "argumentC, int argumentD, int argumentE);";
+
+  verifyFormat(Short, Style);
+
+  EXPECT_EQ(StringRef("functionCall(paramA, paramB, paramC, paramD, paramE, "
+  "paramF, paramG, paramH,\n"
+  " paramI);\n"
+  "void functionDecl(int argumentA, int argumentB, int "
+  "argumentC, int argumentD,\n"
+  "  int argumentE);"),
+format(Medium, Style));
+
+  Style.AllowAllArgumentsOnNextLine = false;
+  Style.AllowAllConstructorInitializersOnNextLine = false;
+  Style.AllowAllParametersOfDeclarationOnNextLine = false;
+
+  verifyFormat(Short, Style);
+
+  EXPECT_EQ(StringRef("functionCall(paramA, paramB, paramC, paramD, paramE, "
+  "paramF, paramG, paramH,\n"
+  " paramI);\n"
+  "void functionDecl(int argumentA, int argumentB, int "
+  "argumentC, int argumentD,\n"
+  "  int argumentE);"),
+format(Medium, Style));
+
+  Style.AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
+
+  verifyFormat(Short, Style);
+
+  EXPECT_EQ(StringRef("functionCall(\n"
+  "paramA, paramB, paramC, paramD, paramE, paramF, "
+  "paramG, paramH, paramI\n"
+  ");\n"
+  "void functionDecl(\n"
+  "int argumentA, int argumentB, int argumentC, int "
+  "argumentD, int argumentE\n"
+  ");"),
+format(Medium, Style));
+
+  Style.BinPackArguments = false;
+  Style.BinPackParameters = false;
+
+  verifyFormat(Short, Style);
+
+  EXPECT_EQ(StringRef("functionCall(\n"
+  "paramA,\n"
+  "paramB,\n"
+  "paramC,\n"
+  "paramD,\n"
+  "paramE,\n"
+  "paramF,\n"
+  "paramG,\n"
+  "paramH,\n"
+  "paramI\n"
+  ");\n"
+  "void functionDecl(\n"
+  "int argumentA,\n"
+  "int argumentB,\n"
+  "int argumentC,\n"
+  "int argumentD,\n"
+  "int argumentE\n"
+  ");"),
+format(Medium, Style));
+
+  verifyFormat("outerFunctionCall(\n"
+   "nestedFunctionCall(argument1),\n"
+   "nestedLongFunctionCall(\n"
+   "argument1,\n"
+   "argument2,\n"
+   "argument3,\n"
+   "argument4,\n"
+   "argument5\n"
+   ")\n"
+   ");",
+   Style);
+}
+
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/lib/Format/TokenAnnotator.cpp

[PATCH] D109714: Reduce maximum width of _ExtInt from 2^24-1 to 2^23 to workaround SelectionDAG issue.

2021-09-13 Thread Craig Topper via Phabricator via cfe-commits
craig.topper abandoned this revision.
craig.topper added a comment.

Abandoning in favor of D109721 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109714

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


[PATCH] D109721: [IR] Reduce max supported integer from 2^24-1 to 2^23.

2021-09-13 Thread Craig Topper via Phabricator via cfe-commits
craig.topper updated this revision to Diff 372362.
craig.topper added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Update clang tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109721

Files:
  clang/docs/ReleaseNotes.rst
  clang/test/CodeGen/ext-int.c
  clang/test/CodeGenCXX/ext-int.cpp
  clang/test/SemaCXX/ext-int.cpp
  llvm/docs/LangRef.rst
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/IR/DerivedTypes.h
  llvm/test/Assembler/invalid-inttype.ll
  llvm/test/Assembler/max-inttype.ll

Index: llvm/test/Assembler/max-inttype.ll
===
--- llvm/test/Assembler/max-inttype.ll
+++ llvm/test/Assembler/max-inttype.ll
@@ -1,4 +1,4 @@
 ; RUN: llvm-as < %s | llvm-dis
 
-; i16777215 is the maximum integer type represented in LLVM IR
-@i2 = common global i16777215 0, align 4
+; i838608 is the maximum integer type represented in LLVM IR
+@i2 = common global i838608 0, align 4
Index: llvm/test/Assembler/invalid-inttype.ll
===
--- llvm/test/Assembler/invalid-inttype.ll
+++ llvm/test/Assembler/invalid-inttype.ll
@@ -1,5 +1,5 @@
 ; RUN: not llvm-as < %s 2>&1 | FileCheck %s
 
-; i16777216 is the smallest integer type that can't be represented in LLVM IR
-@i2 = common global i16777216 0, align 4
+; i8388609 is the smallest integer type that can't be represented in LLVM IR
+@i2 = common global i8388609 0, align 4
 ; CHECK: expected type
Index: llvm/include/llvm/IR/DerivedTypes.h
===
--- llvm/include/llvm/IR/DerivedTypes.h
+++ llvm/include/llvm/IR/DerivedTypes.h
@@ -49,10 +49,11 @@
   /// This enum is just used to hold constants we need for IntegerType.
   enum {
 MIN_INT_BITS = 1,///< Minimum number of bits that can be specified
-MAX_INT_BITS = (1<<24)-1 ///< Maximum number of bits that can be specified
+MAX_INT_BITS = (1<<23)   ///< Maximum number of bits that can be specified
   ///< Note that bit width is stored in the Type classes SubclassData field
-  ///< which has 24 bits. This yields a maximum bit width of 16,777,215
-  ///< bits.
+  ///< which has 24 bits. SelectionDAG type legalization can require a
+  ///< power of 2 IntegerType, so limit to the largest representable power
+  ///< of 2, 8388608.
   };
 
   /// This static method is the primary way of constructing an IntegerType.
Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -59,6 +59,7 @@
 * Using the legacy pass manager for the optimization pipeline is deprecated and
   will be removed after LLVM 14. In the meantime, only minimal effort will be
   made to maintain the legacy pass manager for the optimization pipeline.
+* Max allowed integer type was reduced from 2^24-1 bits to 2^23 bits.
 
 Changes to building LLVM
 
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -3303,7 +3303,7 @@
 
 The integer type is a very simple type that simply specifies an
 arbitrary bit width for the integer type desired. Any bit width from 1
-bit to 2\ :sup:`23`\ -1 (about 8 million) can be specified.
+bit to 2\ :sup:`23`\ (about 8 million) can be specified.
 
 :Syntax:
 
Index: clang/test/SemaCXX/ext-int.cpp
===
--- clang/test/SemaCXX/ext-int.cpp
+++ clang/test/SemaCXX/ext-int.cpp
@@ -29,8 +29,8 @@
   constexpr _ExtInt(7) o = 33;
 
   // Check LLVM imposed max size.
-  _ExtInt(0xFF) p; // expected-error {{signed _ExtInt of bit sizes greater than 16777215 not supported}}
-  unsigned _ExtInt(0xFF) q; // expected-error {{unsigned _ExtInt of bit sizes greater than 16777215 not supported}}
+  _ExtInt(8388609) p; // expected-error {{signed _ExtInt of bit sizes greater than 8388608 not supported}}
+  unsigned _ExtInt(0xFF) q; // expected-error {{unsigned _ExtInt of bit sizes greater than 8388608 not supported}}
 
 // Ensure template params are instantiated correctly.
   // expected-error@5{{signed _ExtInt must have a bit size of at least 2}}
Index: clang/test/CodeGenCXX/ext-int.cpp
===
--- clang/test/CodeGenCXX/ext-int.cpp
+++ clang/test/CodeGenCXX/ext-int.cpp
@@ -223,23 +223,23 @@
   // WIN: %[[LOADV4:.+]] = load i129, i129* %[[LOADP4]]
   // WIN: store i129 %[[LOADV4]], i129*
 
-  _ExtInt(16777200) E = __builtin_va_arg(args, _ExtInt(16777200));
+  _ExtInt(8388600) E = __builtin_va_arg(args, _ExtInt(8388600));
   // LIN: %[[AD5:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
   // LIN: 

[PATCH] D108823: [PowerPC] Mark splat immediate instructions as rematerializable

2021-09-13 Thread Amy Kwan via Phabricator via cfe-commits
amyk added a comment.

A question I have is, I noticed there are some test case changes involving 
`xxspltidp` and `xxsplti32dx`, but are additional tests needed for `xxspltiw`?




Comment at: llvm/lib/Target/PowerPC/PPCInstrPrefix.td:1887
 
 // XXSPLI32DX needs extra flags to make sure the compiler does not attempt
 // to spill part of the instruction when the values are similar.

nit: Update this comment to include `xxspltiw` and `xxspltidp`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108823

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


[PATCH] D109694: Driver: Add preferred gcc triples for Red Hat operating systems

2021-09-13 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

I uploaded D109727  to clean up suse related 
`*Triples` elements in `CollectLibDirsAndTriples`.
The long-term plan is to remove the `*Triples` variables entirely.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109694

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


[PATCH] D108243: Put code that avoids heapifying local blocks behind a flag

2021-09-13 Thread James Y Knight via Phabricator via cfe-commits
jyknight accepted this revision.
jyknight added inline comments.



Comment at: clang/include/clang/Driver/Options.td:2380
+  NegFlag,
+  BothFlags<[CC1Option], " to avoid heapifying local blocks">>;
 

Needs to be marked `[CC1Option, NoDriverOption]`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108243

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


[PATCH] D109635: [WIP][OpenMP] Support construct trait set for Clang

2021-09-13 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: clang/lib/AST/OpenMPClause.cpp:2488
+addTrait(Property);
+  }
 }

Nit: no braces.



Comment at: clang/lib/Parse/ParseOpenMP.cpp:2052
+/* CurrentFunctionDecl */ nullptr,
+/* ConstructTraits */ ArrayRef());
 

`{}` might do it but this is fine too.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:746
+}
+  }
+  }

So, SmalVector has a pop_back_val which we could use to verify the properties 
are the ones we expect. However, we would need to first put them into a vector 
and if insert is false we would need to reverse the vector.
Maybe that's the way to go:
1) Where you call `handleConstructTrait` right now, just put the traits in a 
vector.
2) Make it `handleConstructTraits` and take a vector of construct traits.
3) For insert == true, just append them all.
4) For insert == falser reverse the vector and do pop_back_val with an 
assertion that they match the result of vector.pop_back_val();

Does that make sense?

(Apologies for making you rewrite this twice.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109635

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


[PATCH] D109624: [clang] Make the driver not diagnose errors on nonexistent linker inputs

2021-09-13 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

In D109624#2998550 , @saghir wrote:

> Hi, this change also breaks Power PC bots:
>
> 1. https://lab.llvm.org/buildbot/#/builders/19/builds/6451/steps/24/logs/stdio
> 2. https://lab.llvm.org/buildbot/#/builders/18/builds/2443/steps/23/logs/stdio
>
> It fails consistently on our bots. Can you please take a look?
>
> Thanks!

This will hopefully be better after b7bac5a172e51ed065b3b4dc64cc2d8831e8081c 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109624

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


[clang] b7bac5a - [clang] Revert gcc-driver part of 648feabc65d8

2021-09-13 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2021-09-13T19:04:29-04:00
New Revision: b7bac5a172e51ed065b3b4dc64cc2d8831e8081c

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

LOG: [clang] Revert gcc-driver part of 648feabc65d8

See discussion on https://reviews.llvm.org/D109624

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/unknown-arg.c

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 50791ec479397..0c6b043b5255d 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2149,11 +2149,10 @@ bool Driver::DiagnoseInputExistence(const 
DerivedArgList , StringRef Value,
 }
   }
 
-  // Don't error on apparently non-existent linker inputs, because they
-  // can be influenced by linker flags the clang driver might not understand.
+  // In CL mode, don't error on apparently non-existent linker inputs, because
+  // they can be influenced by linker flags the clang driver might not
+  // understand.
   // Examples:
-  // - `clang -fuse-ld=lld -Wl,--chroot,some/dir /file.o` will make lld look
-  //   for some/dir/file.o
   // - `clang-cl main.cc ole32.lib` in a a non-MSVC shell will make the driver
   //   module look for an MSVC installation in the registry. (We could ask
   //   the MSVCToolChain object if it can find `ole32.lib`, but the logic to
@@ -2172,9 +2171,19 @@ bool Driver::DiagnoseInputExistence(const DerivedArgList 
, StringRef Value,
   // flag. (Users can use `-Wl,` or `/linker` to launder the flag past the
   // driver in the unlikely case they run into this.)
   //
-  // Don't do this skip in clang-cl mode for inputs that start with a '/' --
-  // else we'd pass options like /libpath: through to the linker silently.
-  if (Ty == types::TY_Object && !(IsCLMode() && Value.startswith("/")))
+  // Don't do this for inputs that start with a '/', else we'd pass options
+  // like /libpath: through to the linker silently.
+  //
+  // Emitting an error for linker inputs can also cause incorrect diagnostics
+  // with the gcc driver. The command
+  // clang -fuse-ld=lld -Wl,--chroot,some/dir /file.o
+  // will make lld look for some/dir/file.o, while we will diagnose here that
+  // `/file.o` does not exist. However, configure scripts check if
+  // `clang /GR-` compiles without error to see if the compiler is cl.exe,
+  // so we can't downgrade diagnostics for `/GR-` from an error to a warning
+  // in cc mode. (We can in cl mode because cl.exe itself only warns on
+  // unknown flags.)
+  if (IsCLMode() && Ty == types::TY_Object && !Value.startswith("/"))
 return true;
 
   Diag(clang::diag::err_drv_no_such_file) << Value;

diff  --git a/clang/test/Driver/unknown-arg.c b/clang/test/Driver/unknown-arg.c
index 75ae18fa76dde..45752e9c7976d 100644
--- a/clang/test/Driver/unknown-arg.c
+++ b/clang/test/Driver/unknown-arg.c
@@ -23,6 +23,9 @@
 // RUN: not %clang -cc1asphalt -help 2>&1 | \
 // RUN: FileCheck %s --check-prefix=UNKNOWN-INTEGRATED
 
+// This needs to exit non-0, for configure scripts.
+// RUN: not %clang /GR-
+
 // CHECK: error: unknown argument: '-cake-is-lie'
 // CHECK: error: unknown argument: '-%0'
 // CHECK: error: unknown argument: '-%d'



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


[PATCH] D109624: [clang] Make the driver not diagnose errors on nonexistent linker inputs

2021-09-13 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

In D109624#2998555 , @phosek wrote:

> In D109624#2998419 , @thakis wrote:
>
>> Does it fail consistently? Or was it a one-time flake?
>
> It's been failing consistently. It might be related to our toolchain setting 
> lld as the default linker: 
> https://github.com/llvm/llvm-project/blob/ce6d512015737643df794a2790fa9627f795ea7f/clang/cmake/caches/Fuchsia-stage2.cmake#L36

I use lld on my machinestoo, so that's not it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109624

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


[PATCH] D109624: [clang] Make the driver not diagnose errors on nonexistent linker inputs

2021-09-13 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

In D109624#2998550 , @saghir wrote:

> Hi, this change also breaks Power PC bots:
>
> 1. https://lab.llvm.org/buildbot/#/builders/19/builds/6451/steps/24/logs/stdio
> 2. https://lab.llvm.org/buildbot/#/builders/18/builds/2443/steps/23/logs/stdio
>
> It fails consistently on our bots. Can you please take a look?
>
> Thanks!

That's a more interesting failure. It fails because:

  clang-13: error: /wd4146: 'linker' input unused 
[-Werror,-Wunused-command-line-argument]
  clang-13: error: /wd4291: 'linker' input unused 
[-Werror,-Wunused-command-line-argument]
  clang-13: error: /wd4391: 'linker' input unused 
[-Werror,-Wunused-command-line-argument]
  clang-13: error: /wd4722: 'linker' input unused 
[-Werror,-Wunused-command-line-argument]
  clang-13: error: /wd4800: 'linker' input unused 
[-Werror,-Wunused-command-line-argument]

compiler-rt\cmake\config-ix.cmake does `check_cxx_compiler_flag(/wd4800 
COMPILER_RT_HAS_WD4800_FLAG)` etc. I suppose this patch does have the effect of 
making flags only warnings if no linking is happening:

  >out\gn\bin\clang-cl --driver-mode=gcc /wd1245 -c main.cc
  clang-cl: warning: /wd1245: 'linker' input unused 
[-Wunused-command-line-argument]

That breaks `check_cxx_compiler_flag()` since it doesn't do its checks with 
`-Werror`. I guess that's an argument to keeping this an error for the 
gcc-style driver. On the other hand, it's a bit weird to use 
`cmake:check_cxx_compiler_flag` to check for MSVC-style flags since MSVC itself 
only emits a warning on unknown flags. (On the third hand, this behavior 
between gcc and cl seems to be used to detect cl in practice :) ).

Just using `-wd...` instead of `/wd...` would inside `check_cxx_compiler_flag` 
would make things go, and we don't use this often currently:

  >git grep check_.*compiler_flag(\/
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/GR 
COMPILER_RT_HAS_GR_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/GS 
COMPILER_RT_HAS_GS_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/MT 
COMPILER_RT_HAS_MT_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/Oy 
COMPILER_RT_HAS_Oy_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/Zi 
COMPILER_RT_HAS_Zi_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/W4 
COMPILER_RT_HAS_W4_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/WX 
COMPILER_RT_HAS_WX_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/wd4146 
COMPILER_RT_HAS_WD4146_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/wd4291 
COMPILER_RT_HAS_WD4291_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/wd4221 
COMPILER_RT_HAS_WD4221_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/wd4391 
COMPILER_RT_HAS_WD4391_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/wd4722 
COMPILER_RT_HAS_WD4722_FLAG)
  compiler-rt/cmake/config-ix.cmake:check_cxx_compiler_flag(/wd4800 
COMPILER_RT_HAS_WD4800_FLAG)
  openmp/runtime/cmake/config-ix.cmake:check_cxx_compiler_flag(/EHsc 
LIBOMP_HAVE_EHSC_FLAG)
  openmp/runtime/cmake/config-ix.cmake:check_cxx_compiler_flag(/GS 
LIBOMP_HAVE_GS_FLAG)
  openmp/runtime/cmake/config-ix.cmake:check_cxx_compiler_flag(/Oy- 
LIBOMP_HAVE_Oy__FLAG)
  openmp/runtime/cmake/config-ix.cmake:check_cxx_compiler_flag(/arch:SSE2 
LIBOMP_HAVE_ARCH_SSE2_FLAG)
  openmp/runtime/cmake/config-ix.cmake:check_cxx_compiler_flag(/Qsafeseh 
LIBOMP_HAVE_QSAFESEH_FLAG)
  openmp/runtime/cmake/config-ix.cmake:  check_cxx_compiler_flag(/Qlong_double 
LIBOMP_HAVE_LONG_DOUBLE_FLAG)
  openmp/runtime/cmake/config-ix.cmake:  
check_cxx_compiler_flag(/Qdiag-disable:177 LIBOMP_HAVE_DIAG_DISABLE_177_FLAG)
  openmp/runtime/cmake/config-ix.cmake:  
check_cxx_compiler_flag(/Qinline-min-size=1 LIBOMP_HAVE_INLINE_MIN_SIZE_FLAG)

But I think it's better to undo this for the gcc-style driver instead. I'll 
land a change for that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109624

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


[PATCH] D63497: Add support for openSUSE RISC-V triple

2021-09-13 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

I created D109727  to clean up the `*Triples` 
variables.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63497

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


[PATCH] D109727: [Driver] Remove unneeded *-suse-* triples

2021-09-13 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay created this revision.
MaskRay added reviewers: asb, schwab, tstellar.
Herald added subscribers: StephenFan, dexonsmith, luismarques, steven.zhang, 
s.egerton, PkmX, simoncook, hiraditya, kristof.beyls.
MaskRay requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

`CollectLibDirsAndTriples` has a number of `*Triples` elements (hack) so that
`--target=aarch64-linux-gnu` can auto detect `lib/aarch64-suse-linux`. IMO
trouble from the magic behavior outweighs its convenience.

For most users (who don't specify `--target`), the CMake
`LLVM_DEFAULT_TARGET_TRIPLE` variable should just point to the correct triple
(e.g. `aarch64-suse-linux`), and Clang driver will find the right
`lib/aarch64-suse-linux` directory without a hard coded element in 
`AArch64LibDirs`.

For people who specify `--target` for cross compilation, they should specify the
full target triple instead of relying on `--target=riscv64` expanding to
`--target=riscv64-suse-linux`.

Also revert rL304670  (normalize gnueabi to 
gnueabihf)

Note: the test added by D63497  works even 
without `riscv64-suse-linux`
in `RISCV64Triples`

I have kept powerpc64-suse-linux in `PPCTriples` because it somehow uses the
multilib behavior for native Clang. That doesn't look right to me.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109727

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/test/Driver/linux-header-search.cpp
  clang/test/Driver/linux-ld.c
  llvm/lib/Support/Triple.cpp
  llvm/unittests/ADT/TripleTest.cpp

Index: llvm/unittests/ADT/TripleTest.cpp
===
--- llvm/unittests/ADT/TripleTest.cpp
+++ llvm/unittests/ADT/TripleTest.cpp
@@ -1552,9 +1552,6 @@
   EXPECT_EQ("armv7eb-unknown-netbsd-eabihf",
 Triple::normalize("armv7eb-netbsd-eabihf"));
 
-  EXPECT_EQ("armv7-suse-linux-gnueabihf",
-Triple::normalize("armv7-suse-linux-gnueabi"));
-
   Triple T;
   T = Triple("armv6--netbsd-eabi");
   EXPECT_EQ(Triple::arm, T.getArch());
Index: llvm/lib/Support/Triple.cpp
===
--- llvm/lib/Support/Triple.cpp
+++ llvm/lib/Support/Triple.cpp
@@ -986,10 +986,6 @@
 }
   }
 
-  // SUSE uses "gnueabi" to mean "gnueabihf"
-  if (Vendor == Triple::SUSE && Environment == llvm::Triple::GNUEABI)
-Components[3] = "gnueabihf";
-
   if (OS == Triple::Win32) {
 Components.resize(4);
 Components[2] = "windows";
Index: clang/test/Driver/linux-ld.c
===
--- clang/test/Driver/linux-ld.c
+++ clang/test/Driver/linux-ld.c
@@ -711,12 +711,12 @@
 //
 // Check openSuse Leap 42.2 on AArch64
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: --target=arm64-unknown-linux-gnu -rtlib=platform \
+// RUN: --target=aarch64-suse-linux -rtlib=platform \
 // RUN: --gcc-toolchain="" \
 // RUN: --sysroot=%S/Inputs/opensuse_42.2_aarch64_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-OPENSUSE-42-2-AARCH64 %s
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: --target=aarch64-unknown-linux-gnu -rtlib=platform \
+// RUN: --target=aarch64-suse-linux -rtlib=platform \
 // RUN: --gcc-toolchain="" \
 // RUN: --sysroot=%S/Inputs/opensuse_42.2_aarch64_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-OPENSUSE-42-2-AARCH64 %s
@@ -791,7 +791,7 @@
 //
 // Check openSUSE Tumbleweed on ppc
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: --target=powerpc-unknown-linux-gnu -rtlib=platform \
+// RUN: --target=powerpc-suse-linux -rtlib=platform \
 // RUN: --gcc-toolchain="" \
 // RUN: --sysroot=%S/Inputs/opensuse_tumbleweed_ppc_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-OPENSUSE-TW-PPC %s
Index: clang/test/Driver/linux-header-search.cpp
===
--- clang/test/Driver/linux-header-search.cpp
+++ clang/test/Driver/linux-header-search.cpp
@@ -278,7 +278,7 @@
 
 // Check header search with Cray's gcc package.
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
-// RUN: -target x86_64-unknown-linux-gnu -stdlib=libstdc++ \
+// RUN: -target x86_64-suse-linux -stdlib=libstdc++ \
 // RUN: --sysroot=%S/Inputs/cray_suse_gcc_tree \
 // RUN: --gcc-toolchain="%S/Inputs/cray_suse_gcc_tree/opt/gcc/8.2.0/snos" \
 // RUN:   | FileCheck --check-prefix=CHECK-CRAY-X86 %s
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2075,10 +2075,16 @@
   // Declare a bunch of static data sets that we'll select between below. These
   // are specifically designed to always refer to string literals to avoid any
   

[PATCH] D109701: [clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

2021-09-13 Thread Vaibhav Yenamandra via Phabricator via cfe-commits
vaibhav.y added a comment.



> Btw, is the intent for this functionality to replace what's in 
> SarifDiagnostics.cpp 
> (https://github.com/llvm/llvm-project/blob/main/clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp)
>  fairly immediately? Or are we going to carry both implementations?

This is intended to replace what's in `SarifDiagnostics.cpp` in the future, it 
copies quite a few functions over from there as well. There is more work 
planned on this, since we've decided that the best way to add this feature 
without too much disrpution would be as follows:

1. Add an interface to create sarif docs
2. Add an adapter that can translate a specific diagnostic type (e.g. 
`PathDiagnostic`) to sarif
3. Rewrite the existing code to use the adapter
4. Introduce the same to clang internals

I think ordering the changes like so will let keep the individual changesets 
narrow, while adding temporary bloat. For now we must keep both implementations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109701

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


[PATCH] D109624: [clang] Make the driver not diagnose errors on nonexistent linker inputs

2021-09-13 Thread Petr Hosek via Phabricator via cfe-commits
phosek added a comment.

In D109624#2998419 , @thakis wrote:

> Does it fail consistently? Or was it a one-time flake?

It's been failing consistently. It might be related to our toolchain setting 
lld as the default linker: 
https://github.com/llvm/llvm-project/blob/ce6d512015737643df794a2790fa9627f795ea7f/clang/cmake/caches/Fuchsia-stage2.cmake#L36


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109624

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


Re: [clang] bdce8d4 - Revert "[X86] Adjust Keylocker handle mem size"

2021-09-13 Thread Craig Topper via cfe-commits
When reverting patches, please include the reason in the commit message.

~Craig


On Mon, Sep 13, 2021 at 3:01 AM Xiang1 Zhang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Xiang1 Zhang
> Date: 2021-09-13T18:00:46+08:00
> New Revision: bdce8d40c6da56f1c95a8d7bfeac12b1ffce79cf
>
> URL:
> https://github.com/llvm/llvm-project/commit/bdce8d40c6da56f1c95a8d7bfeac12b1ffce79cf
> DIFF:
> https://github.com/llvm/llvm-project/commit/bdce8d40c6da56f1c95a8d7bfeac12b1ffce79cf.diff
>
> LOG: Revert "[X86] Adjust Keylocker handle mem size"
>
> This reverts commit 3731de6b7f2d42d40151f9574636bc4d5ccfa5e3.
>
> Added:
>
>
> Modified:
> clang/lib/CodeGen/CGBuiltin.cpp
> clang/lib/Headers/keylockerintrin.h
> clang/test/CodeGen/X86/keylocker.c
> llvm/test/CodeGen/X86/keylocker-intrinsics.ll
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp
> b/clang/lib/CodeGen/CGBuiltin.cpp
> index d485e8e767692..727fc19f1a23f 100644
> --- a/clang/lib/CodeGen/CGBuiltin.cpp
> +++ b/clang/lib/CodeGen/CGBuiltin.cpp
> @@ -14905,7 +14905,7 @@ Value
> *CodeGenFunction::EmitX86BuiltinExpr(unsigned BuiltinID,
>
>  Value *Call = Builder.CreateCall(CGM.getIntrinsic(IID), {Ops[0],
> Ops[1]});
>
> -for (int i = 0; i < 3; ++i) {
> +for (int i = 0; i < 6; ++i) {
>Value *Extract = Builder.CreateExtractValue(Call, i + 1);
>Value *Ptr = Builder.CreateConstGEP1_32(Int8Ty, Ops[2], i * 16);
>Ptr = Builder.CreateBitCast(
> @@ -14921,7 +14921,7 @@ Value
> *CodeGenFunction::EmitX86BuiltinExpr(unsigned BuiltinID,
>  Value *Call =
>  Builder.CreateCall(CGM.getIntrinsic(IID), {Ops[0], Ops[1],
> Ops[2]});
>
> -for (int i = 0; i < 4; ++i) {
> +for (int i = 0; i < 7; ++i) {
>Value *Extract = Builder.CreateExtractValue(Call, i + 1);
>Value *Ptr = Builder.CreateConstGEP1_32(Int8Ty, Ops[3], i * 16);
>Ptr = Builder.CreateBitCast(
>
> diff  --git a/clang/lib/Headers/keylockerintrin.h
> b/clang/lib/Headers/keylockerintrin.h
> index ad9428e6c8b57..68b0a5689618a 100644
> --- a/clang/lib/Headers/keylockerintrin.h
> +++ b/clang/lib/Headers/keylockerintrin.h
> @@ -99,7 +99,7 @@ _mm_loadiwkey (unsigned int __ctl, __m128i __intkey,
>  }
>
>  /// Wrap a 128-bit AES key from __key into a key handle and output in
> -/// ((__m128i*)__h) to ((__m128i*)__h) + 2  and a 32-bit value as return.
> +/// ((__m128i*)__h) to ((__m128i*)__h) + 5  and a 32-bit value as return.
>  /// The explicit source operand __htype specifies handle restrictions.
>  ///
>  /// \headerfile 
> @@ -120,6 +120,9 @@ _mm_loadiwkey (unsigned int __ctl, __m128i __intkey,
>  /// MEM[__h+127:__h] := Handle[127:0]   // AAD
>  /// MEM[__h+255:__h+128] := Handle[255:128] // Integrity Tag
>  /// MEM[__h+383:__h+256] := Handle[383:256] // CipherText
> +/// MEM[__h+511:__h+384] := 0 // Reserved for future usage
> +/// MEM[__h+639:__h+512] := 0 // Reserved for future usage
> +/// MEM[__h+767:__h+640] := 0 // Reserved for future usage
>  /// OF := 0
>  /// SF := 0
>  /// ZF := 0
> @@ -133,7 +136,7 @@ _mm_encodekey128_u32(unsigned int __htype, __m128i
> __key, void *__h) {
>  }
>
>  /// Wrap a 256-bit AES key from __key_hi:__key_lo into a key handle, then
> -/// output handle in ((__m128i*)__h) to ((__m128i*)__h) + 3 and
> +/// output handle in ((__m128i*)__h) to ((__m128i*)__h) + 6 and
>  /// a 32-bit value as return.
>  /// The explicit source operand __htype specifies handle restrictions.
>  ///
> @@ -157,6 +160,9 @@ _mm_encodekey128_u32(unsigned int __htype, __m128i
> __key, void *__h) {
>  /// MEM[__h+255:__h+128] := Handle[255:128] // Tag
>  /// MEM[__h+383:__h+256] := Handle[383:256] // CipherText[127:0]
>  /// MEM[__h+511:__h+384] := Handle[511:384] // CipherText[255:128]
> +/// MEM[__h+639:__h+512] := 0 // Reserved for future usage
> +/// MEM[__h+767:__h+640] := 0 // Reserved for future usage
> +/// MEM[__h+895:__h+768] := 0 Integrity// Reserved for future usage
>  /// OF := 0
>  /// SF := 0
>  /// ZF := 0
>
> diff  --git a/clang/test/CodeGen/X86/keylocker.c
> b/clang/test/CodeGen/X86/keylocker.c
> index a87281c5bd3fc..ded6e57bfb8b6 100644
> --- a/clang/test/CodeGen/X86/keylocker.c
> +++ b/clang/test/CodeGen/X86/keylocker.c
> @@ -98,8 +98,20 @@ void test_loadiwkey(unsigned int ctl, __m128i intkey,
> __m128i enkey_lo, __m128i
>  // CHECK64-NEXT:[[TMP13:%.*]] = getelementptr i8, i8* [[TMP5]], i32 32
>  // CHECK64-NEXT:[[TMP14:%.*]] = bitcast i8* [[TMP13]] to <2 x i64>*
>  // CHECK64-NEXT:store <2 x i64> [[TMP12]], <2 x i64>* [[TMP14]],
> align 1
> -// CHECK64-NEXT:[[TMP15:%.*]] = extractvalue { i32, <2 x i64>, <2 x
> i64>, <2 x i64>, <2 x i64>, <2 x i64>, <2 x i64> } [[TMP6]], 0
> -// CHECK64-NEXT:ret i32 [[TMP15]]
> +// CHECK64-NEXT:[[TMP15:%.*]] = extractvalue { i32, <2 x i64>, <2 x
> i64>, <2 x i64>, <2 x i64>, <2 x i64>, <2 x i64> } [[TMP6]], 4
> +// CHECK64-NEXT:[[TMP16:%.*]] = 

[PATCH] D109624: [clang] Make the driver not diagnose errors on nonexistent linker inputs

2021-09-13 Thread Ahsan Saghir via Phabricator via cfe-commits
saghir added a comment.

Hi, this change also breaks Power PC bots:

1. https://lab.llvm.org/buildbot/#/builders/19/builds/6451/steps/24/logs/stdio
2. https://lab.llvm.org/buildbot/#/builders/18/builds/2443/steps/23/logs/stdio

It fails consistently on our bots. Can you please take a look?

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109624

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


[PATCH] D109635: [WIP][OpenMP] Support construct trait set for Clang

2021-09-13 Thread Chi Chun Chen via Phabricator via cfe-commits
cchen updated this revision to Diff 372347.
cchen added a comment.

Rebase and fix based on suggestions

Haven't ConstructTrait to IRBuilder


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109635

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/lib/AST/OpenMPClause.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/declare_variant_construct_codegen_1.c

Index: clang/test/OpenMP/declare_variant_construct_codegen_1.c
===
--- /dev/null
+++ clang/test/OpenMP/declare_variant_construct_codegen_1.c
@@ -0,0 +1,87 @@
+// RUN: %clang_cc1 -verify -fopenmp -triple x86_64-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefix=CK1
+// RUN: %clang_cc1 -fopenmp -x c -triple x86_64-unknown-linux -emit-pch -o %t -fopenmp-version=45 %s
+// RUN: %clang_cc1 -fopenmp -x c -triple x86_64-unknown-linux -include-pch %t -verify %s -emit-llvm -o - -fopenmp-version=45 | FileCheck %s --check-prefix=CK1
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c -triple x86_64-unknown-linux -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -o - | FileCheck %s --check-prefix=CK1
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c -triple x86_64-unknown-linux -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -o - | FileCheck %s --check-prefix=CK1
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c -triple x86_64-unknown-linux -fopenmp-targets=amdgcn-amd-amdhsa -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c -triple x86_64-unknown-linux -fopenmp-targets=amdgcn-amd-amdhsa -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix=CK1
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -triple x86_64-unknown-linux -emit-llvm %s -o - | FileCheck %s --implicit-check-not="{{__kmpc|__tgt}}"
+// RUN: %clang_cc1 -fopenmp-simd -x c -triple x86_64-unknown-linux -emit-pch -o %t -fopenmp-version=45 %s
+// RUN: %clang_cc1 -fopenmp-simd -x c -triple x86_64-unknown-linux -include-pch %t -verify %s -emit-llvm -o - -fopenmp-version=45 | FileCheck %s --implicit-check-not="{{__kmpc|__tgt}}"
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c -triple x86_64-unknown-linux -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -o - | FileCheck %s --implicit-check-not="{{__kmpc|__tgt}}"
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c -triple x86_64-unknown-linux -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -o - | FileCheck %s --implicit-check-not="{{__kmpc|__tgt}}"
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c -triple x86_64-unknown-linux -fopenmp-targets=amdgcn-amd-amdhsa -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c -triple x86_64-unknown-linux -fopenmp-targets=amdgcn-amd-amdhsa -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --implicit-check-not="{{__kmpc|__tgt}}"
+
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+
+#define N 100
+
+void p_vxv(int *v1, int *v2, int *v3, int n);
+void t_vxv(int *v1, int *v2, int *v3, int n);
+
+#pragma omp declare variant(t_vxv) match(construct={target})
+#pragma omp declare variant(p_vxv) match(construct={parallel})
+void vxv(int *v1, int *v2, int *v3, int n) {
+for (int i = 0; i < n; i++) v3[i] = v1[i] * v2[i];
+}
+// CK1: define dso_local void @vxv
+
+void p_vxv(int *v1, int *v2, int *v3, int n) {
+#pragma omp for
+for (int i = 0; i < n; i++) v3[i] = v1[i] * v2[i] * 3;
+}
+// CK1: define dso_local void @p_vxv
+
+#pragma omp declare target
+void t_vxv(int *v1, int *v2, int *v3, int n) {
+#pragma distribute simd
+for (int i = 0; i < n; i++) v3[i] = v1[i] * v2[i] * 2;
+}
+#pragma omp end declare target
+// CK1: define dso_local void @t_vxv
+
+
+// CK1-LABEL: define {{[^@]+}}@main
+int main() {
+  int v1[N], v2[N], v3[N];
+
+  // init
+  for (int i = 0; i < N; i++) {
+v1[i] = (i + 1);
+v2[i] = -(i + 1);
+v3[i] = 0;
+  }
+
+#pragma omp target teams map(to: v1[:N],v2[:N]) map(from: v3[:N])
+  {
+vxv(v1, v2, v3, N);
+  }
+// CK1: call void @__omp_offloading_[[OFFLOAD:.+]]({{.+}})
+
+  vxv(v1, v2, v3, N);
+// CK1: call void @vxv
+
+#pragma omp parallel
+  {
+vxv(v1, v2, v3, N);
+  }
+// CK1: call void ({{.+}}) @__kmpc_fork_call(%struct.ident_t* {{.+}}, i32 3, void ({{.+}})* bitcast (void (i32*, i32*, [100 x i32]*, [100 x i32]*, [100 x i32]*)* [[PARALLEL_REGION:@.+]] to void
+
+  return 0;
+}
+
+// CK1: define internal void @__omp_offloading_[[OFFLOAD]]({{.+}})
+// CK1: call void ({{.+}}) @__kmpc_fork_teams(%struct.ident_t* {{.+}}, i32 3, void ({{.+}})* bitcast (void (i32*, i32*, [100 x i32]*, [100 x i32]*, [100 x i32]*)* [[TARGET_REGION:@.+]] to void
+
+// CK1: define internal void [[TARGET_REGION]](
+// CK1: call void @t_vxv
+
+// CK1: define internal void [[PARALLEL_REGION]](
+// CK1: call void @p_vxv
+
+#endif // HEADER
Index: clang/lib/Sema/SemaOpenMP.cpp

[PATCH] D109718: [HIP] Diagnose -fopenmp-targets for HIP programs

2021-09-13 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:704
+C.getInputArgs().getLastArg(options::OPT_fopenmp_targets_EQ)) {
+  Diag(clang::diag::err_drv_unsupported_opt) << 
OMPTargetArg->getSpelling();
+  return;

I think "unsupported" here is a bit misleading. We need something along the 
lines of "option X can't be used with option Y".

I think `err_drv_argument_not_allowed_with` might be a better choice.


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

https://reviews.llvm.org/D109718

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


[PATCH] D109635: [WIP][OpenMP] Support construct trait set for Clang

2021-09-13 Thread Chi Chun Chen via Phabricator via cfe-commits
cchen added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:737
+  }
+  void eraseConstructTrait() { ConstructTraits.clear(); }
+

cchen wrote:
> jdoerfert wrote:
> > Modification was made to make it clear what happens but now I think this is 
> > not needed.
> > 
> > See below first. Maybe the interface should be 
> > "handleConstructTrait(Property, bool Insert)" and if Insert is false you 
> > verify it's the last one and delete it. You'd need to traverse them in 
> > opposite order though to verify, unsure if verification is therefore 
> > strictly necessary.
> For the delete part, I'm not sure how passing `Property` would work since I'm 
> not deleting all the construct trait properties inside `ActOnOpenMPRegionEnd` 
> function.
I think I've figured out a way to achieve what you suggest.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:4491
   ArrayRef Clauses) {
+  DSAStack->eraseConstructTrait();
   if (DSAStack->getCurrentDirective() == OMPD_atomic ||

jdoerfert wrote:
> I know think you need to call something like 
> `addDeclareVariantConstructTrait` again and do pop_back() instead of 
> push_back() for each trait matching the DKind. Clearing, or erasing a fixed 
> amount of traits, does not work. 
So you are saying that instead of removing all the construct property inside 
`ActOnOpenMPRegionEnd`, we should delete those construct properties more 
fine-grained? I'd like to do so and has tried putting the insert/delete logic 
inside more specific function such as `ActOnOpenMPParllell`, 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109635

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


[PATCH] D109624: [clang] Make the driver not diagnose errors on nonexistent linker inputs

2021-09-13 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Does it fail consistently? Or was it a one-time flake?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109624

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


[PATCH] D105191: [Clang][OpenMP] Add support for Static Device Libraries

2021-09-13 Thread Ye Luo via Phabricator via cfe-commits
ye-luo added a comment.

the modf test still doesn't work. The issue was from unbundle.
case 1 works.

  clang++ -fopenmp -fopenmp-targets=nvptx64 modf.cpp -c
  clang++ -fopenmp -fopenmp-targets=nvptx64 modf.o

case 2

  clang++ -fopenmp -fopenmp-targets=nvptx64 -Xopenmp-target=nvptx64 
-march=sm_80 modf.cpp -c
  clang++ -fopenmp -fopenmp-targets=nvptx64 -Xopenmp-target=nvptx64 
-march=sm_80 modf.o 

doesn't work. The issue was a failure in unbundling

  "/soft/llvm/main-patched/bin/clang-offload-bundler" -type=o 
-targets=host-x86_64-unknown-linux-gnu,openmp-nvptx64-sm_80 -inputs=modf.o 
-outputs=/tmp/modf-99be57.o,/tmp/modf-88a9eb.cubin -unbundle 
-allow-missing-bundles

ends up an empty cubin file. If I remove -sm_80 on the unbundle line
It seems that we need to have sm_80 when the object file is created.

When clang is compiled CLANG_OPENMP_NVPTX_DEFAULT_ARCH can be used to set the 
default sm_XX so it doesn't needs to be provided at compile time. If not set 
default is sm_35.
So in general sm_XX is always known when the compiler is used for compiling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105191

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


[clang] 0867c01 - [ClangScanDeps][test] Add -fmodules-cache-path=DIR/cache to make diagnostics.c hermetic

2021-09-13 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-09-13T13:17:55-07:00
New Revision: 0867c017e55e3a3d457f26bb778a2cd80d86e1f4

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

LOG: [ClangScanDeps][test] Add -fmodules-cache-path=DIR/cache to make 
diagnostics.c hermetic

Otherwise it may access sys::path::cache_directory/clang/ModuleCache which may 
not be writable.

Added: 


Modified: 
clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template

Removed: 




diff  --git a/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template 
b/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
index 062e202328c86..c729ea980a64d 100644
--- a/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
+++ b/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
@@ -1,7 +1,7 @@
 [
   {
 "directory": "DIR",
-"command": "clang -c DIR/tu.c -fmodules -target 
i386-apple-ios14.0-simulator -Wno-error=invalid-ios-deployment-target -o 
DIR/tu.o",
+"command": "clang -c DIR/tu.c -fmodules -target 
i386-apple-ios14.0-simulator -fmodules-cache-path=DIR/cache 
-Wno-error=invalid-ios-deployment-target -o DIR/tu.o",
 "file": "DIR/tu.c"
   }
 ]



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


[PATCH] D109681: [RISCV] add Half-precision test for vle/vse

2021-09-13 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109681

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


[PATCH] D109686: Check supported architectures in sseXYZ/avxXYZ headers

2021-09-13 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109686

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


[PATCH] D108893: clang-tidy: introduce readability-containter-data-pointer check

2021-09-13 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd marked an inline comment as done.
compnerd added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability-container-data-pointer.cpp:104
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:5: warning: 'data' should be used for 
accessing the data pointer instead of taking the address of the 0-th element 
[readability-container-data-pointer]
+}

aaron.ballman wrote:
> Can you add one more test for how this behaves on uninstantiated templates?
> ```
> template 
> void func(const std::vector ) {
>   const Ty *Ptr = [0]; // Should diagnose and provide a fix-it despite 
> not instantiating func()
> }
> ```
Absolutely!  Thanks for the additional test case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108893

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


[PATCH] D109703: [DebugInfo] Fix scope for local static variables

2021-09-13 Thread Kristina Bessonova via Phabricator via cfe-commits
krisb added a comment.

In D109703#2998155 , @ellis wrote:

> I've added this to the added test case.
>
>   !18 = !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !4, 
> entity: !19, line: 122)
>   !19 = !DIGlobalVariable(name: "imported_static_var", scope: !6, file: !5, 
> line: 3, type: !10, isLocal: false, isDefinition: true)

Thank you for pointing to this! Just in case, do you have a C++ example, that 
reproduces the issue with imported static local declaration? I'm asking, cause 
in your example `DW_TAG_imported_declaration` has CU as a scope, while 
`DIGlobalVariable` is function-scoped. This looks a bit strange. I mean, 
`constructImportedEntityDIE()` called from `DwarfDebug::beginModule()` skips 
all local-scoped entities, and unless I'm missing something static locals 
shouldn't go here. Another call for  `constructImportedEntityDIE()` is from 
`DwarfCompileUnit::createScopeChildrenDIE` where I'd not expect any issue with 
parents.

But it seems imported declarations are broken not just for static locals, but 
for all inlined entities, for example

  namespace ns {
  inline __attribute__((always_inline))
  int foo() {
int a = 42; 
return a;
  }
  }
  
  int main() {
using ns::foo;
return foo();
  }

produces (with or w/o this patch) imported declaration for `foo()` that refers 
to an empty subprogram:

  x002a:   DW_TAG_namespace
  DW_AT_name  ("ns")
  
  0x002f: DW_TAG_subprogram
DW_AT_name  ("foo")
DW_AT_inline  (DW_INL_inlined)
  
  0x003f:   DW_TAG_variable
  DW_AT_name  ("a")
  
  0x004a:   NULL
  
  0x004b: DW_TAG_subprogram
  
  0x004c: NULL
  
  0x0054:   DW_TAG_subprogram
  DW_AT_name  ("main")
  
  0x006d: DW_TAG_imported_declaration
DW_AT_import  (0x004b)

while it should point to `0x002f`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109703

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


[PATCH] D109714: Reduce maximum width of _ExtInt from 2^24-1 to 2^23 to workaround SelectionDAG issue.

2021-09-13 Thread Craig Topper via Phabricator via cfe-commits
craig.topper updated this revision to Diff 372331.
craig.topper added a comment.

Add comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109714

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/ext-int.c
  clang/test/CodeGenCXX/ext-int.cpp
  clang/test/SemaCXX/ext-int.cpp

Index: clang/test/SemaCXX/ext-int.cpp
===
--- clang/test/SemaCXX/ext-int.cpp
+++ clang/test/SemaCXX/ext-int.cpp
@@ -29,8 +29,8 @@
   constexpr _ExtInt(7) o = 33;
 
   // Check LLVM imposed max size.
-  _ExtInt(0xFF) p; // expected-error {{signed _ExtInt of bit sizes greater than 16777215 not supported}}
-  unsigned _ExtInt(0xFF) q; // expected-error {{unsigned _ExtInt of bit sizes greater than 16777215 not supported}}
+  _ExtInt(8388609) p; // expected-error {{signed _ExtInt of bit sizes greater than 8388608 not supported}}
+  unsigned _ExtInt(0xFF) q; // expected-error {{unsigned _ExtInt of bit sizes greater than 8388608 not supported}}
 
 // Ensure template params are instantiated correctly.
   // expected-error@5{{signed _ExtInt must have a bit size of at least 2}}
Index: clang/test/CodeGenCXX/ext-int.cpp
===
--- clang/test/CodeGenCXX/ext-int.cpp
+++ clang/test/CodeGenCXX/ext-int.cpp
@@ -223,23 +223,23 @@
   // WIN: %[[LOADV4:.+]] = load i129, i129* %[[LOADP4]]
   // WIN: store i129 %[[LOADV4]], i129*
 
-  _ExtInt(16777200) E = __builtin_va_arg(args, _ExtInt(16777200));
+  _ExtInt(8388600) E = __builtin_va_arg(args, _ExtInt(8388600));
   // LIN: %[[AD5:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
   // LIN: %[[OFA_P5:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD5]], i32 0, i32 2
   // LIN: %[[OFA5:.+]] = load i8*, i8** %[[OFA_P5]]
-  // LIN: %[[BC5:.+]] = bitcast i8* %[[OFA5]] to i16777200*
-  // LIN: %[[OFANEXT5:.+]] = getelementptr i8, i8* %[[OFA5]], i32 2097152
+  // LIN: %[[BC5:.+]] = bitcast i8* %[[OFA5]] to i8388600*
+  // LIN: %[[OFANEXT5:.+]] = getelementptr i8, i8* %[[OFA5]], i32 1048576
   // LIN: store i8* %[[OFANEXT5]], i8** %[[OFA_P5]]
-  // LIN: %[[LOAD5:.+]] = load i16777200, i16777200* %[[BC5]]
-  // LIN: store i16777200 %[[LOAD5]], i16777200*
+  // LIN: %[[LOAD5:.+]] = load i8388600, i8388600* %[[BC5]]
+  // LIN: store i8388600 %[[LOAD5]], i8388600*
 
   // WIN: %[[CUR5:.+]] = load i8*, i8** %[[ARGS]]
   // WIN: %[[NEXT5:.+]] = getelementptr inbounds i8, i8* %[[CUR5]], i64 8
   // WIN: store i8* %[[NEXT5]], i8** %[[ARGS]]
-  // WIN: %[[BC5:.+]] = bitcast i8* %[[CUR5]] to i16777200**
-  // WIN: %[[LOADP5:.+]] = load i16777200*, i16777200** %[[BC5]]
-  // WIN: %[[LOADV5:.+]] = load i16777200, i16777200* %[[LOADP5]]
-  // WIN: store i16777200 %[[LOADV5]], i16777200*
+  // WIN: %[[BC5:.+]] = bitcast i8* %[[CUR5]] to i8388600**
+  // WIN: %[[LOADP5:.+]] = load i8388600*, i8388600** %[[BC5]]
+  // WIN: %[[LOADV5:.+]] = load i8388600, i8388600* %[[LOADP5]]
+  // WIN: store i8388600 %[[LOADV5]], i8388600*
 
   __builtin_va_end(args);
   // LIN: %[[ENDAD:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
@@ -295,7 +295,7 @@
 
 struct S {
   _ExtInt(17) A;
-  _ExtInt(16777200) B;
+  _ExtInt(8388600) B;
   _ExtInt(17) C;
 };
 
@@ -308,7 +308,7 @@
   auto B = __builtin_offsetof(S,B);
   // CHECK: store i64 8, i64* %{{.+}}
   auto C = __builtin_offsetof(S,C);
-  // CHECK: store i64 2097160, i64* %{{.+}}
+  // CHECK: store i64 1048584, i64* %{{.+}}
 }
 
 
Index: clang/test/CodeGen/ext-int.c
===
--- clang/test/CodeGen/ext-int.c
+++ clang/test/CodeGen/ext-int.c
@@ -28,7 +28,7 @@
 
 struct S {
   _ExtInt(17) A;
-  _ExtInt(16777200) B;
+  _ExtInt(8388600) B;
   _ExtInt(17) C;
 };
 
@@ -41,9 +41,9 @@
   // LIN32: store i32 4, i32* %{{.+}}
   // WINCHECK32: store i32 8, i32* %{{.+}}
   int C = __builtin_offsetof(struct S,C);
-  // CHECK64: store i32 2097160, i32* %{{.+}}
-  // LIN32: store i32 2097156, i32* %{{.+}}
-  // WIN32: store i32 2097160, i32* %{{.+}}
+  // CHECK64: store i32 1048584, i32* %{{.+}}
+  // LIN32: store i32 1048580, i32* %{{.+}}
+  // WIN32: store i32 1048584, i32* %{{.+}}
 }
 
 void Size1ExtIntParam(unsigned _ExtInt(1) A) {
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2269,9 +2269,13 @@
 return QualType();
   }
 
-  if (NumBits > llvm::IntegerType::MAX_INT_BITS) {
-Diag(Loc, diag::err_ext_int_max_size) << IsUnsigned
-  << llvm::IntegerType::MAX_INT_BITS;
+  // For types that aren't natively supported, SelectionDAG type legalization
+  // needs to create a power of 2 

[PATCH] D109718: [HIP] Diagnose -fopenmp-targets for HIP programs

2021-09-13 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl created this revision.
yaxunl added a reviewer: tra.
Herald added a subscriber: guansong.
yaxunl requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added a subscriber: sstefan1.

Diagnose -fopenmp-targets for HIP programs since dual HIP and OpenMP offloading 
in the same compilation
is currently not supported by HIP toolchain.


https://reviews.llvm.org/D109718

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/hip-options.hip


Index: clang/test/Driver/hip-options.hip
===
--- clang/test/Driver/hip-options.hip
+++ clang/test/Driver/hip-options.hip
@@ -87,3 +87,15 @@
 // THINLTO-NOT: clang{{.*}}" "-triple" "amdgcn-amd-amdhsa" {{.*}} 
"-fwhole-program-vtables"
 // THINLTO: clang{{.*}}" "-triple" "x86_64-unknown-linux-gnu" {{.*}} 
"-flto=thin" {{.*}} "-fwhole-program-vtables"
 // THINLTO-NOT: clang{{.*}}" "-triple" "amdgcn-amd-amdhsa" {{.*}} 
"-fwhole-program-vtables"
+
+// Check -fopenmp is allowed with HIP but -fopenmp-targets= is not allowed.
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --offload-arch=gfx906 -fopenmp %s 2>&1 | FileCheck -check-prefix=OMP 
%s
+// OMP-NOT: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} "-fopenmp"
+// OMP: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} "-fopenmp"
+
+// RUN: not %clang -target x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --offload-arch=gfx906 -fopenmp -fopenmp-targets=amdgcn %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=OMPTGT %s
+// OMPTGT: unsupported option '-fopenmp-targets='
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -699,6 +699,11 @@
 }
 C.addOffloadDeviceToolChain(CudaTC.get(), OFK);
   } else if (IsHIP) {
+if (auto *OMPTargetArg =
+C.getInputArgs().getLastArg(options::OPT_fopenmp_targets_EQ)) {
+  Diag(clang::diag::err_drv_unsupported_opt) << 
OMPTargetArg->getSpelling();
+  return;
+}
 const ToolChain *HostTC = C.getSingleOffloadToolChain();
 const llvm::Triple  = HostTC->getTriple();
 auto OFK = Action::OFK_HIP;


Index: clang/test/Driver/hip-options.hip
===
--- clang/test/Driver/hip-options.hip
+++ clang/test/Driver/hip-options.hip
@@ -87,3 +87,15 @@
 // THINLTO-NOT: clang{{.*}}" "-triple" "amdgcn-amd-amdhsa" {{.*}} "-fwhole-program-vtables"
 // THINLTO: clang{{.*}}" "-triple" "x86_64-unknown-linux-gnu" {{.*}} "-flto=thin" {{.*}} "-fwhole-program-vtables"
 // THINLTO-NOT: clang{{.*}}" "-triple" "amdgcn-amd-amdhsa" {{.*}} "-fwhole-program-vtables"
+
+// Check -fopenmp is allowed with HIP but -fopenmp-targets= is not allowed.
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --offload-arch=gfx906 -fopenmp %s 2>&1 | FileCheck -check-prefix=OMP %s
+// OMP-NOT: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} "-fopenmp"
+// OMP: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} "-fopenmp"
+
+// RUN: not %clang -target x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --offload-arch=gfx906 -fopenmp -fopenmp-targets=amdgcn %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=OMPTGT %s
+// OMPTGT: unsupported option '-fopenmp-targets='
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -699,6 +699,11 @@
 }
 C.addOffloadDeviceToolChain(CudaTC.get(), OFK);
   } else if (IsHIP) {
+if (auto *OMPTargetArg =
+C.getInputArgs().getLastArg(options::OPT_fopenmp_targets_EQ)) {
+  Diag(clang::diag::err_drv_unsupported_opt) << OMPTargetArg->getSpelling();
+  return;
+}
 const ToolChain *HostTC = C.getSingleOffloadToolChain();
 const llvm::Triple  = HostTC->getTriple();
 auto OFK = Action::OFK_HIP;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D105876: OMPIRBuilder for Interop directive

2021-09-13 Thread Sri Hari Krishna Narayanan via Phabricator via cfe-commits
sriharikrishna updated this revision to Diff 372329.
sriharikrishna added a comment.

OMPIRBuilder for Interop directive


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105876

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/OpenMP/interop_irbuilder.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPConstants.h
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp

Index: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+++ llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
@@ -2736,6 +2736,87 @@
   return Builder.CreateCall(Fn, Args, Name);
 }
 
+CallInst *OpenMPIRBuilder::createOMPInteropInit(
+const LocationDescription , Value *InteropVar,
+omp::OMPInteropType InteropType, Value *Device, Value *NumDependences,
+Value *DependenceAddress, bool HaveNowaitClause) {
+  IRBuilder<>::InsertPointGuard IPG(Builder);
+  Builder.restoreIP(Loc.IP);
+
+  Constant *SrcLocStr = getOrCreateSrcLocStr(Loc);
+  Value *Ident = getOrCreateIdent(SrcLocStr);
+  Value *ThreadId = getOrCreateThreadID(Ident);
+  if (Device == NULL)
+Device = ConstantInt::get(Int32, -1);
+  Constant *InteropTypeVal = ConstantInt::get(Int64, (int)InteropType);
+  if (NumDependences == nullptr) {
+NumDependences = ConstantInt::get(Int32, 0);
+PointerType *PointerTypeVar = Type::getInt8PtrTy(M.getContext());
+DependenceAddress = ConstantPointerNull::get(PointerTypeVar);
+  }
+  Value *HaveNowaitClauseVal = ConstantInt::get(Int32, HaveNowaitClause);
+  Value *Args[] = {
+  Ident,  ThreadId,   InteropVar,InteropTypeVal,
+  Device, NumDependences, DependenceAddress, HaveNowaitClauseVal};
+
+  Function *Fn = getOrCreateRuntimeFunctionPtr(OMPRTL___tgt_interop_init);
+
+  return Builder.CreateCall(Fn, Args);
+}
+
+CallInst *OpenMPIRBuilder::createOMPInteropDestroy(
+const LocationDescription , Value *InteropVar, Value *Device,
+Value *NumDependences, Value *DependenceAddress, bool HaveNowaitClause) {
+  IRBuilder<>::InsertPointGuard IPG(Builder);
+  Builder.restoreIP(Loc.IP);
+
+  Constant *SrcLocStr = getOrCreateSrcLocStr(Loc);
+  Value *Ident = getOrCreateIdent(SrcLocStr);
+  Value *ThreadId = getOrCreateThreadID(Ident);
+  if (Device == NULL)
+Device = ConstantInt::get(Int32, -1);
+  if (NumDependences == nullptr) {
+NumDependences = ConstantInt::get(Int32, 0);
+PointerType *PointerTypeVar = Type::getInt8PtrTy(M.getContext());
+DependenceAddress = ConstantPointerNull::get(PointerTypeVar);
+  }
+  Value *HaveNowaitClauseVal = ConstantInt::get(Int32, HaveNowaitClause);
+  Value *Args[] = {
+  Ident,  ThreadId,  InteropVar, Device,
+  NumDependences, DependenceAddress, HaveNowaitClauseVal};
+
+  Function *Fn = getOrCreateRuntimeFunctionPtr(OMPRTL___tgt_interop_destroy);
+
+  return Builder.CreateCall(Fn, Args);
+}
+
+CallInst *OpenMPIRBuilder::createOMPInteropUse(const LocationDescription ,
+   Value *InteropVar, Value *Device,
+   Value *NumDependences,
+   Value *DependenceAddress,
+   bool HaveNowaitClause) {
+  IRBuilder<>::InsertPointGuard IPG(Builder);
+  Builder.restoreIP(Loc.IP);
+  Constant *SrcLocStr = getOrCreateSrcLocStr(Loc);
+  Value *Ident = getOrCreateIdent(SrcLocStr);
+  Value *ThreadId = getOrCreateThreadID(Ident);
+  if (Device == NULL)
+Device = ConstantInt::get(Int32, -1);
+  if (NumDependences == nullptr) {
+NumDependences = ConstantInt::get(Int32, 0);
+PointerType *PointerTypeVar = Type::getInt8PtrTy(M.getContext());
+DependenceAddress = ConstantPointerNull::get(PointerTypeVar);
+  }
+  Value *HaveNowaitClauseVal = ConstantInt::get(Int32, HaveNowaitClause);
+  Value *Args[] = {
+  Ident,  ThreadId,  InteropVar, Device,
+  NumDependences, DependenceAddress, HaveNowaitClauseVal};
+
+  Function *Fn = getOrCreateRuntimeFunctionPtr(OMPRTL___tgt_interop_use);
+
+  return Builder.CreateCall(Fn, Args);
+}
+
 CallInst *OpenMPIRBuilder::createCachedThreadPrivate(
 const LocationDescription , llvm::Value *Pointer,
 llvm::ConstantInt *Size, const llvm::Twine ) {
Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -374,6 +374,15 @@
 __OMP_RTL(__kmpc_alloc, false, VoidPtr, /* Int */ Int32, SizeTy, VoidPtr)
 __OMP_RTL(__kmpc_free, false, Void, /* Int */ Int32, VoidPtr, VoidPtr)
 

[PATCH] D109635: [WIP][OpenMP] Support construct trait set for Clang

2021-09-13 Thread Chi Chun Chen via Phabricator via cfe-commits
cchen added a comment.

> One thing I wanted to do though is keep track of the constructs in the 
> OpenMPIRBuilder instead. So move the
>
>   /// Vector of declare variant construct traits.
>   SmallVector ConstructTraits;
>
> into OpenMPIRBuilder and add/delete the things there. It's not a conceptual 
> difference but makes it easier
> to opt-in for Flang later.

We don't have any OpenMPIRBuilder instance inside `SemaOpenMP` yet and the 
OpenMPIRBuilder constructor requires a `Module` parameter so I'm not sure how 
to achieve this, can you give me some suggestions?




Comment at: clang/lib/Sema/SemaOpenMP.cpp:737
+  }
+  void eraseConstructTrait() { ConstructTraits.clear(); }
+

jdoerfert wrote:
> Modification was made to make it clear what happens but now I think this is 
> not needed.
> 
> See below first. Maybe the interface should be 
> "handleConstructTrait(Property, bool Insert)" and if Insert is false you 
> verify it's the last one and delete it. You'd need to traverse them in 
> opposite order though to verify, unsure if verification is therefore strictly 
> necessary.
For the delete part, I'm not sure how passing `Property` would work since I'm 
not deleting all the construct trait properties inside `ActOnOpenMPRegionEnd` 
function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109635

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


[PATCH] D109714: Reduce maximum width of _ExtInt from 2^24-1 to 2^23 to workaround SelectionDAG issue.

2021-09-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM modulo a request for some comments in the code. It makes me sad that we 
have a max number of bits specified by LLVM that's kinda useless. "You can 
store this many bits into this integer value, but if you attempt to add 0 to 
that value, it sometimes breaks" doesn't sound like a useful maximum. :-D




Comment at: clang/lib/Sema/SemaType.cpp:2272
 
-  if (NumBits > llvm::IntegerType::MAX_INT_BITS) {
-Diag(Loc, diag::err_ext_int_max_size) << IsUnsigned
-  << llvm::IntegerType::MAX_INT_BITS;
+  int MaxBits = PowerOf2Floor(llvm::IntegerType::MAX_INT_BITS);
+  if (NumBits > MaxBits) {

I'd appreciate some extra comments here explaining why the max int bit width is 
insufficient.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109714

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


[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

2021-09-13 Thread Philippe Antoine via Phabricator via cfe-commits
catenacyber added a comment.

> Even if `INSTR_PROF_RAW_VERSION` is bumped, I think it is very likely your 
> Rust downstream will observe an `if (GET_VERSION(Version) != 
> RawInstrProf::Version)` error in llvm-profdata,
> because from your description it seems you are likely mixing raw profile 
> files produced by compiler-rt/lib/profile built at different commits.

For the record, bumping `INSTR_PROF_RAW_VERSION` on top of main branch, (or 
after reverting this commit), in both 
compiler-rt/include/profile/InstrProfData.inc and 
llvm/include/llvm/ProfileData/InstrProfData.inc, I indeed get the error message 
`unsupported instrumentation profile format version`

The output for `file default.profraw` is `default.profraw: LLVM raw profile 
data, version 7`

> Bumping INSTR_PROF_RAW_VERSION will give a better diagnostic but won't 
> address the root cause that only one version is supported, which I totally 
> agree since otherwise this would add too much burden on the upstream LLVM 
> developer side.

Well, now I have my diagnostic :-) (it is not like 
https://github.com/rust-lang/rust/issues/82875 for instance)

> this is "Support for older format versions in RawInstrProfReader" 
> https://lists.llvm.org/pipermail/llvm-dev/2021-August/152287.html

Thanks for the pointer

> You'll need to rebuild everything on the Rust side if you want to use git 
> LLVM.

Indeed, I will try to rebuild rust with clang-14


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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


[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

2021-09-13 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 marked an inline comment as done.
gandhi21299 added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5069
   // where aliases aren't supported.
-  if (!RawTriple.isOSDarwin() && !RawTriple.isNVPTX() && !RawTriple.isAMDGPU())
 CmdArgs.push_back("-mconstructor-aliases");

arsenm wrote:
> This looks like an unrelated change?
Ahh yes, I will get rid of it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109707

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


[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

2021-09-13 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D104556#2998159 , @catenacyber 
wrote:

>> .profraw are files with the raw profile format. The compiler-rt/lib/profile 
>> runtime and llvm-profdata only support one version at any commit.
>
> Ok.
>
>> Mixing .profraw files produced by different compiler-rt/lib/profile runtimes 
>> is unsupported.
>
> I do not think I am mixing profraw files as I have only one profraw file.
> If my llvm-profdata is not supporting the profraw file produced by rust + 
> linker, should it not error with
> ` Unsupported instrumentation profile format version` instead of `malformed 
> instrumentation profile data`
> As it does with rust nightly and clang 12 ?
>
>> I don't know what rustc and https://github.com/ctz/rustls do.
>
> Rustls is just an example rust project, I think we get the same result with 
> every rust project.

Wild guess:
this is "Support for older format versions in RawInstrProfReader" 
https://lists.llvm.org/pipermail/llvm-dev/2021-August/152287.html

>> I don't think this change is responsible as the change has been well 
>> released/tested by many C++ groups.
>
> I guess I did not mean to use the word responsible.
> I am just saying that if I `git revert 
> a1532ed27582038e2d9588108ba0fe8237f01844` and solve the conflicts on top of 
> main, I get my scenario to work again
>
>> If Rust adapts compiler-rt and does something different, I think the 
>> investigation responsibility is on Rust's side.
>>
>> Perhaps you can get some help from rustc folks who do the compiler-rt 
>> adaptation in rustc.
>
> I am asking indeed

The error only happens when you have mix-and-match .profraw files. You'll need 
to rebuild everything on the Rust side if you want to use git LLVM.
I guess that rustc itself or some prebuilt executable is using an old format.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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


[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

2021-09-13 Thread Philippe Antoine via Phabricator via cfe-commits
catenacyber added a comment.

> .profraw are files with the raw profile format. The compiler-rt/lib/profile 
> runtime and llvm-profdata only support one version at any commit.

Ok.

> Mixing .profraw files produced by different compiler-rt/lib/profile runtimes 
> is unsupported.

I do not think I am mixing profraw files as I have only one profraw file.
If my llvm-profdata is not supporting the profraw file produced by rust + 
linker, should it not error with
` Unsupported instrumentation profile format version` instead of `malformed 
instrumentation profile data`
As it does with rust nightly and clang 12 ?

> I don't know what rustc and https://github.com/ctz/rustls do.

Rustls is just an example rust project, I think we get the same result with 
every rust project.

> I don't think this change is responsible as the change has been well 
> released/tested by many C++ groups.

I guess I did not mean to use the word responsible.
I am just saying that if I `git revert 
a1532ed27582038e2d9588108ba0fe8237f01844` and solve the conflicts on top of 
main, I get my scenario to work again

> If Rust adapts compiler-rt and does something different, I think the 
> investigation responsibility is on Rust's side.
>
> Perhaps you can get some help from rustc folks who do the compiler-rt 
> adaptation in rustc.

I am asking indeed


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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


[PATCH] D109654: [clang] disable implicit moves when not in CPlusPLus

2021-09-13 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

Thanks a lot!! This seems to take care of my issues.

Can you also include the following test case somewhere into, say, 
`test/Analysis/blocks-nrvo.c`? It crashes without this patch.

  // RUN: %clang_analyze_cc1 -w -analyzer-checker=core -fblocks -verify %s
  
  // expected-no-diagnostics
  
  typedef struct {
int x;
  } S;
  
  void foo() {
^{
  S s;
  return s; // no-crash
};
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109654

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


[PATCH] D109714: Reduce maximum width of _ExtInt from 2^24-1 to 2^23 to workaround SelectionDAG issue.

2021-09-13 Thread Erich Keane via Phabricator via cfe-commits
erichkeane accepted this revision.
erichkeane added a comment.
This revision is now accepted and ready to land.

Changes to the tests are less intense than I would have thought!  In general 
I'm Ok with this, I don't think anyone would really notice/mind this all that 
much, and since we can't actually implement this in the backends, it doesn't 
really make sense to have some sort of flag for this.  I have a slight bit of 
sympathy for the backends that could consume this, but I'd think we need to 
have our implementation-limit be the least-common-denominator of our backends 
anyway.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109714

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


[PATCH] D109557: Adds an AlignCloseBracket option

2021-09-13 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added a comment.

You state in the documentation that it is also for angle brackets and more, but 
there are no test cases for that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109557

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


[PATCH] D109714: Reduce maximum width of _ExtInt from 2^24-1 to 2^23 to workaround SelectionDAG issue.

2021-09-13 Thread Craig Topper via Phabricator via cfe-commits
craig.topper created this revision.
craig.topper added reviewers: aaron.ballman, erichkeane.
craig.topper requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

SelectionDAG type legalization requires a power of 2 type with at
least as many bits as the _ExtInt. This power of 2 type size must
fit in 24 bits since an llvm::IntegerType will be created. This
places an effective limit of 2^23 on any integer types if they go
through SelectionDAG.

Fixes part of PR51829.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109714

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/ext-int.c
  clang/test/CodeGenCXX/ext-int.cpp
  clang/test/SemaCXX/ext-int.cpp

Index: clang/test/SemaCXX/ext-int.cpp
===
--- clang/test/SemaCXX/ext-int.cpp
+++ clang/test/SemaCXX/ext-int.cpp
@@ -29,8 +29,8 @@
   constexpr _ExtInt(7) o = 33;
 
   // Check LLVM imposed max size.
-  _ExtInt(0xFF) p; // expected-error {{signed _ExtInt of bit sizes greater than 16777215 not supported}}
-  unsigned _ExtInt(0xFF) q; // expected-error {{unsigned _ExtInt of bit sizes greater than 16777215 not supported}}
+  _ExtInt(8388609) p; // expected-error {{signed _ExtInt of bit sizes greater than 8388608 not supported}}
+  unsigned _ExtInt(0xFF) q; // expected-error {{unsigned _ExtInt of bit sizes greater than 8388608 not supported}}
 
 // Ensure template params are instantiated correctly.
   // expected-error@5{{signed _ExtInt must have a bit size of at least 2}}
Index: clang/test/CodeGenCXX/ext-int.cpp
===
--- clang/test/CodeGenCXX/ext-int.cpp
+++ clang/test/CodeGenCXX/ext-int.cpp
@@ -223,23 +223,23 @@
   // WIN: %[[LOADV4:.+]] = load i129, i129* %[[LOADP4]]
   // WIN: store i129 %[[LOADV4]], i129*
 
-  _ExtInt(16777200) E = __builtin_va_arg(args, _ExtInt(16777200));
+  _ExtInt(8388600) E = __builtin_va_arg(args, _ExtInt(8388600));
   // LIN: %[[AD5:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
   // LIN: %[[OFA_P5:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD5]], i32 0, i32 2
   // LIN: %[[OFA5:.+]] = load i8*, i8** %[[OFA_P5]]
-  // LIN: %[[BC5:.+]] = bitcast i8* %[[OFA5]] to i16777200*
-  // LIN: %[[OFANEXT5:.+]] = getelementptr i8, i8* %[[OFA5]], i32 2097152
+  // LIN: %[[BC5:.+]] = bitcast i8* %[[OFA5]] to i8388600*
+  // LIN: %[[OFANEXT5:.+]] = getelementptr i8, i8* %[[OFA5]], i32 1048576
   // LIN: store i8* %[[OFANEXT5]], i8** %[[OFA_P5]]
-  // LIN: %[[LOAD5:.+]] = load i16777200, i16777200* %[[BC5]]
-  // LIN: store i16777200 %[[LOAD5]], i16777200*
+  // LIN: %[[LOAD5:.+]] = load i8388600, i8388600* %[[BC5]]
+  // LIN: store i8388600 %[[LOAD5]], i8388600*
 
   // WIN: %[[CUR5:.+]] = load i8*, i8** %[[ARGS]]
   // WIN: %[[NEXT5:.+]] = getelementptr inbounds i8, i8* %[[CUR5]], i64 8
   // WIN: store i8* %[[NEXT5]], i8** %[[ARGS]]
-  // WIN: %[[BC5:.+]] = bitcast i8* %[[CUR5]] to i16777200**
-  // WIN: %[[LOADP5:.+]] = load i16777200*, i16777200** %[[BC5]]
-  // WIN: %[[LOADV5:.+]] = load i16777200, i16777200* %[[LOADP5]]
-  // WIN: store i16777200 %[[LOADV5]], i16777200*
+  // WIN: %[[BC5:.+]] = bitcast i8* %[[CUR5]] to i8388600**
+  // WIN: %[[LOADP5:.+]] = load i8388600*, i8388600** %[[BC5]]
+  // WIN: %[[LOADV5:.+]] = load i8388600, i8388600* %[[LOADP5]]
+  // WIN: store i8388600 %[[LOADV5]], i8388600*
 
   __builtin_va_end(args);
   // LIN: %[[ENDAD:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
@@ -295,7 +295,7 @@
 
 struct S {
   _ExtInt(17) A;
-  _ExtInt(16777200) B;
+  _ExtInt(8388600) B;
   _ExtInt(17) C;
 };
 
@@ -308,7 +308,7 @@
   auto B = __builtin_offsetof(S,B);
   // CHECK: store i64 8, i64* %{{.+}}
   auto C = __builtin_offsetof(S,C);
-  // CHECK: store i64 2097160, i64* %{{.+}}
+  // CHECK: store i64 1048584, i64* %{{.+}}
 }
 
 
Index: clang/test/CodeGen/ext-int.c
===
--- clang/test/CodeGen/ext-int.c
+++ clang/test/CodeGen/ext-int.c
@@ -28,7 +28,7 @@
 
 struct S {
   _ExtInt(17) A;
-  _ExtInt(16777200) B;
+  _ExtInt(8388600) B;
   _ExtInt(17) C;
 };
 
@@ -41,9 +41,9 @@
   // LIN32: store i32 4, i32* %{{.+}}
   // WINCHECK32: store i32 8, i32* %{{.+}}
   int C = __builtin_offsetof(struct S,C);
-  // CHECK64: store i32 2097160, i32* %{{.+}}
-  // LIN32: store i32 2097156, i32* %{{.+}}
-  // WIN32: store i32 2097160, i32* %{{.+}}
+  // CHECK64: store i32 1048584, i32* %{{.+}}
+  // LIN32: store i32 1048580, i32* %{{.+}}
+  // WIN32: store i32 1048584, i32* %{{.+}}
 }
 
 void Size1ExtIntParam(unsigned _ExtInt(1) A) {
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp

[PATCH] D109557: Adds an AlignCloseBracket option

2021-09-13 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added a comment.

In D109557#2997899 , @csmulhern wrote:

> I've added more information to my original message. Please let me know if 
> further context is desired.

With context he meant the diff context. 
https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109557

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


[PATCH] D105191: [Clang][OpenMP] Add support for Static Device Libraries

2021-09-13 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam added a comment.

In D105191#2997272 , @ye-luo wrote:

> @saiislam did you turn on offload? 
> https://github.com/ye-luo/openmp-target/wiki/OpenMP-offload-compilers#llvm-clang
> On NVIDIA, it fails at CMake step. On AMD, make step stops because of 
> unrelated issue.
>
> Please make the exact reproducer 1 working. Right now I got
>
>   $ clang++ -fopenmp -fopenmp-targets=nvptx64 -Xopenmp-target=nvptx64 
> -march=sm_80 modf.o
>   nvlink fatal   : Could not open input file '/tmp/modf-88b730.cubin'
>   /soft/llvm/main-patched/bin/clang-nvlink-wrapper: error: 'nvlink' failed
>   clang-14: error: nvlink command failed with exit code 1 (use -v to see 
> invocation)

@ye-luo 
Can you please take this latest update and verify if it is working for you?
It is working for me.

Following modifications were also required for the compile.sh and 
compile-amd.sh.
Assuming name of your fat archive is **libmylib.a** and it is present in the 
**current directory**, the command to use it will be as follows:

> clang++ -fopenmp -fopenmp-targets=nvptx64 main.cpp **-L. -lmylib**

or

> clang++ -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
> -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 main.cpp** -L. -lmylib**

So, compile.sh should be:

> clang++ -fopenmp -fopenmp-targets=nvptx64 -c -Xopenmp-target=nvptx64 
> -march=sm_50 classA.cpp
> rm -f libmylib.a
> ar qc libmylib.a classA.o
> ranlib libmylib.a
> clang++ -fopenmp -fopenmp-targets=nvptx64 main.cpp **-L. -lmylib**
> ./a.out

And compile-amd.sh should be:

> clang++ -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
> -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 -c classA.cpp
> rm -f libmylib.a
> llvm-ar qc libmylib.a classA.o
> llvm-ranlib libmylib.a
> clang++ -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
> -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 main.cpp **-L. -lmylib**
> ./a.out


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105191

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


[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

2021-09-13 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D109707#2998095 , @aeubanks wrote:

> should the `amdgpu-early-inline-all` flag be deleted?

No. It is still used by HIP. We will deprecate it in the feature, but it is not 
ready yet.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109707

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


[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

2021-09-13 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D104556#2998137 , @catenacyber 
wrote:

>> Bump the raw profile format version to 6. (Last bump happened in 2019-10.)
>
> This does not seem to be in the patch, ie no change of 
> `INSTR_PROF_RAW_VERSION` in compiler-rt/include/profile/InstrProfData.inc
> Is that missing ?

`INSTR_PROF_RAW_VERSION` is not bumped. It was bumped in the first revision of 
this patch if you looked at the history.

Somehow the binary ID change got pushed before this and it has been rolled 
back/forward several times in main.
The version is not updated to not cause unnecessary conflict with that patch.

Even if `INSTR_PROF_RAW_VERSION` is bumped, I think it is very likely your Rust 
downstream will observe an `if (GET_VERSION(Version) != RawInstrProf::Version)` 
error in llvm-profdata,
because from your description it seems you are likely mixing raw profile files 
produced by compiler-rt/lib/profile built at different commits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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


[PATCH] D109703: [DebugInfo] Fix scope for local static variables

2021-09-13 Thread Ellis Hoag via Phabricator via cfe-commits
ellis added a comment.

Thanks for working on this! `getOrCreateGlobalVariableDIE()` is also called in 
`constructImportedEntityDIE()` which means that there could be some globals 
without DIE parents. In D108492  I've added 
this to the added test case.

  !18 = !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !4, entity: 
!19, line: 122)
  !19 = !DIGlobalVariable(name: "imported_static_var", scope: !6, file: !5, 
line: 3, type: !10, isLocal: false, isDefinition: true)

But maybe we can fix this in another diff?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109703

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


[PATCH] D105191: [Clang][OpenMP] Add support for Static Device Libraries

2021-09-13 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam updated this revision to Diff 372307.
saiislam added a comment.

Fix for file types in fat archive.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105191

Files:
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/test/Driver/Inputs/hip_dev_lib/libFatArchive.a
  clang/test/Driver/fat_archive.cpp
  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
@@ -180,6 +180,29 @@
   }
 };
 
+static StringRef getDeviceFileExtension(StringRef Device) {
+  if (Device.contains("gfx"))
+return ".bc";
+  if (Device.contains("sm_"))
+return ".cubin";
+  else {
+WithColor::warning() << "Could not determine extension for archive"
+"members, using \".o\"\n";
+return ".o";
+  }
+}
+
+static std::string getDeviceLibraryFileName(StringRef BundleFileName,
+StringRef Device) {
+  StringRef LibName = sys::path::stem(BundleFileName);
+  StringRef Extension = getDeviceFileExtension(Device);
+
+  std::string Result;
+  Result += LibName;
+  Result += Extension;
+  return Result;
+}
+
 /// Generic file handler interface.
 class FileHandler {
 public:
@@ -1229,7 +1252,9 @@
   BundledObjectFileName.assign(BundledObjectFile);
   auto OutputBundleName =
   Twine(llvm::sys::path::stem(BundledObjectFileName) + "-" +
-CodeObject)
+CodeObject +
+getDeviceLibraryFileName(BundledObjectFileName,
+ CodeObjectInfo.GPUArch))
   .str();
   // Replace ':' in optional target feature list with '_' to ensure
   // cross-platform validity.
Index: clang/test/Driver/fat_archive.cpp
===
--- /dev/null
+++ clang/test/Driver/fat_archive.cpp
@@ -0,0 +1,91 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+
+// See the steps to create a fat archive near the end of the file.
+
+// Test succeeds if no linked error i.e. all external symbols in the archive
+// could be resolved correctly.
+// RUN: env LIBRARY_PATH=%T/../../../../../runtimes/runtimes-bins/openmp/libomptarget %clang -O2 -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s -L%S/Inputs/hip_dev_lib -lFatArchive -o - | FileCheck %s -check-prefix=LINKERROR
+// LINKERROR-NOT: error: linker command failed with exit code 1
+
+// Given a FatArchive, clang-offload-bundler should be called to create a
+// device specific archive, which should be passed to llvm-link.
+// RUN: env LIBRARY_PATH=%T/../../../../../runtimes/runtimes-bins/openmp/libomptarget %clang -O2 -### -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s -L%S/Inputs/hip_dev_lib -lFatArchive 2>&1 | FileCheck %s
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-pc-linux-gnu"{{.*}}"-o" "[[HOSTOBJ:.*.o]]" "-x" "ir"{{.*}}
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa"{{.*}}"-emit-llvm-bc"{{.*}}"-target-cpu" "gfx906"{{.*}}"-o" "[[HOSTBC:.*.bc]]" "-x" "c++"{{.*}}.cpp
+// CHECK: clang-offload-bundler" "-unbundle" "-type=a" "-inputs={{.*}}/Inputs/hip_dev_lib/libFatArchive.a" "-targets=openmp-amdgcn-amd-amdhsa-gfx906" "-outputs=[[DEVICESPECIFICARCHIVE:.*.a]]" "-allow-missing-bundles"
+// CHECK: llvm-link{{.*}}"[[HOSTBC]]" "[[DEVICESPECIFICARCHIVE]]" "-o" "{{.*}}-gfx906-linked-{{.*}}.bc"
+// CHECK: ld.lld"{{.*}}" "-L{{.*}}/Inputs/hip_dev_lib" "{{.*}}"[[HOSTOBJ]]" "-lFatArchive" "{{.*}}" "-lomp{{.*}}-lomptarget"
+// expected-no-diagnostics
+
+// Tests for linker and loader errors in case external symbols are not found in
+// the FatArchive.
+// RUN: env LIBRARY_PATH=%T/../../../../../runtimes/runtimes-bins/openmp/libomptarget not %clang -O2 -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s -L%S/Inputs/hip_dev_lib -lFatArchive -DMISSING=1 2>&1 | FileCheck %s -check-prefix=MISSINGSYM
+// MISSINGSYM: ld.lld: error: undefined symbol: func_missing
+// MISSINGSYM: error: linker command failed with exit code 1
+
+#ifndef HEADER
+#define HEADER
+
+#define N 10
+
+#pragma omp declare target
+// Functions defined in Fat Archive.
+extern "C" void func_present(float *, float *, unsigned);
+
+#ifdef MISSING
+// Function not defined in the fat archive.
+extern "C" 

[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

2021-09-13 Thread Philippe Antoine via Phabricator via cfe-commits
catenacyber added a comment.

> Bump the raw profile format version to 6. (Last bump happened in 2019-10.)

This does not seem to be in the patch, ie no change of `INSTR_PROF_RAW_VERSION` 
in compiler-rt/include/profile/InstrProfData.inc
Is that missing ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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


[PATCH] D108243: Put code that avoids heapifying local blocks behind a flag

2021-09-13 Thread Walter Lee via Phabricator via cfe-commits
waltl added a comment.

In D108243#2998077 , @ahatanak wrote:

> I was just asking for test cases as I thought it was already a driver option, 
> but it turns out it wasn't. I agree that this shouldn't be a driver option.
>
> Sorry @waltl, please revert the changes that made it a driver option in the 
> last patch.

Done.  Thanks for the clarification.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108243

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


[PATCH] D108243: Put code that avoids heapifying local blocks behind a flag

2021-09-13 Thread Walter Lee via Phabricator via cfe-commits
waltl updated this revision to Diff 372306.
waltl added a comment.

Remove driver flags and corresponding tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108243

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGObjC.cpp
  clang/test/CodeGenObjC/arc-block-copy-escape.m
  clang/test/CodeGenObjC/arc-blocks.m
  clang/test/CodeGenObjCXX/arc-blocks.mm
  clang/test/PCH/arc-blocks.mm

Index: clang/test/PCH/arc-blocks.mm
===
--- clang/test/PCH/arc-blocks.mm
+++ clang/test/PCH/arc-blocks.mm
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fobjc-arc -fblocks -std=c++1y -emit-pch %s -o %t
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fobjc-arc -fblocks -std=c++1y -include-pch %t -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fobjc-arc -fblocks -std=c++1y -include-pch %t -fobjc-avoid-heapify-local-blocks -emit-llvm -o - %s | FileCheck %s
 
 #ifndef HEADER_INCLUDED
 #define HEADER_INCLUDED
Index: clang/test/CodeGenObjCXX/arc-blocks.mm
===
--- clang/test/CodeGenObjCXX/arc-blocks.mm
+++ clang/test/CodeGenObjCXX/arc-blocks.mm
@@ -1,9 +1,11 @@
 // RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -fexceptions -fobjc-arc-exceptions -o - %s | FileCheck -check-prefix CHECK %s
 // RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -fexceptions -fobjc-arc-exceptions -O1 -o - %s | FileCheck -check-prefix CHECK-O1 %s
 // RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -o - %s | FileCheck -check-prefix CHECK-NOEXCP %s
+// RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -fexceptions -fobjc-arc-exceptions -fobjc-avoid-heapify-local-blocks -o - %s | FileCheck -check-prefix CHECK-NOHEAP %s
 
 // CHECK: [[A:.*]] = type { i64, [10 x i8*] }
 // CHECK: %[[STRUCT_BLOCK_DESCRIPTOR:.*]] = type { i64, i64 }
+// CHECK-NOHEAP: %[[STRUCT_BLOCK_DESCRIPTOR:.*]] = type { i64, i64 }
 // CHECK: %[[STRUCT_TEST1_S0:.*]] = type { i32 }
 // CHECK: %[[STRUCT_TRIVIAL_INTERNAL:.*]] = type { i32 }
 
@@ -209,8 +211,8 @@
 
 namespace test_block_retain {
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain14initializationEP11objc_object(
-// CHECK-NOT: @llvm.objc.retainBlock(
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain14initializationEP11objc_object(
+// CHECK-NOHEAP-NOT: @llvm.objc.retainBlock(
   void initialization(id a) {
 BlockTy b0 = ^{ foo1(a); };
 BlockTy b1 = (^{ foo1(a); });
@@ -218,23 +220,23 @@
 b1();
   }
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain20initializationStaticEP11objc_object(
-// CHECK: @llvm.objc.retainBlock(
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain20initializationStaticEP11objc_object(
+// CHECK-NOHEAP: @llvm.objc.retainBlock(
   void initializationStatic(id a) {
 static BlockTy b0 = ^{ foo1(a); };
 b0();
   }
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain15initialization2EP11objc_object
-// CHECK: %[[B0:.*]] = alloca void ()*, align 8
-// CHECK: %[[B1:.*]] = alloca void ()*, align 8
-// CHECK: load void ()*, void ()** %[[B0]], align 8
-// CHECK-NOT: @llvm.objc.retainBlock
-// CHECK: %[[V9:.*]] = load void ()*, void ()** %[[B0]], align 8
-// CHECK: %[[V10:.*]] = bitcast void ()* %[[V9]] to i8*
-// CHECK: %[[V11:.*]] = call i8* @llvm.objc.retainBlock(i8* %[[V10]])
-// CHECK: %[[V12:.*]] = bitcast i8* %[[V11]] to void ()*
-// CHECK: store void ()* %[[V12]], void ()** %[[B1]], align 8
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain15initialization2EP11objc_object
+// CHECK-NOHEAP: %[[B0:.*]] = alloca void ()*, align 8
+// CHECK-NOHEAP: %[[B1:.*]] = alloca void ()*, align 8
+// CHECK-NOHEAP: load void ()*, void ()** %[[B0]], align 8
+// CHECK-NOHEAP-NOT: @llvm.objc.retainBlock
+// CHECK-NOHEAP: %[[V9:.*]] = load void ()*, void ()** %[[B0]], align 8
+// CHECK-NOHEAP: %[[V10:.*]] = bitcast void ()* %[[V9]] to i8*
+// CHECK-NOHEAP: %[[V11:.*]] = call i8* @llvm.objc.retainBlock(i8* %[[V10]])
+// CHECK-NOHEAP: %[[V12:.*]] = bitcast i8* %[[V11]] to void ()*
+// CHECK-NOHEAP: store void ()* %[[V12]], void ()** %[[B1]], align 8
   void initialization2(id a) {
 BlockTy b0 = ^{ foo1(a); };
 b0();
@@ -242,8 +244,8 @@
 b1();
   }
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain10assignmentEP11objc_object(
-// CHECK-NOT: @llvm.objc.retainBlock(
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain10assignmentEP11objc_object(
+// CHECK-NOHEAP-NOT: @llvm.objc.retainBlock(
   void assignment(id a) {
 

[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

2021-09-13 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D104556#2998091 , @catenacyber 
wrote:

> Thanks for the quick reply
>
>> I don't think this change is responsible. This has been tested by many C++ 
>> downstream groups.
>
> What did I do wrong ?
> Adding this only commit makes the scenario fail.
>
>> Rust should use upgrade its lib/ProfileData and compiler-rt/lib/profile, and 
>> not mix raw profile files at different commits.
>
> I am not sure I understand.
> What are raw profiles ? 
> In my scenario, only `llvm-profdata` acts on default.profraw
> And before that, the linker, not the rust compiler, mixes together the 
> different coverage sections...
> So, how would Rust mix raw profiles ?

.profraw are files with the raw profile format. The compiler-rt/lib/profile 
runtime and llvm-profdata only support one version at any commit.
Mixing .profraw files produced by different compiler-rt/lib/profile runtimes is 
unsupported.

I don't know what rustc and https://github.com/ctz/rustls do.

I don't think this change is responsible as the change has been well 
released/tested by many C++ groups.
If Rust adapts compiler-rt and does something different, I think the 
investigation responsibility is on Rust's side.

Perhaps you can get some help from rustc folks who do the compiler-rt 
adaptation in rustc.

>> The binary ID change has caused a bit of churn to ProfileData but it is 
>> unrelated to this patch.
>
> Well, there may be other bugs, but this is not a problem in my scenario...




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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


[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

2021-09-13 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

should the `amdgpu-early-inline-all` flag be deleted?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109707

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


[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

2021-09-13 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

We cannot disable early inline all since this will cause performance 
regressions. Instead, the early inline all pass should be fixed so it does not 
remove aliases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109707

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


[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

2021-09-13 Thread Philippe Antoine via Phabricator via cfe-commits
catenacyber added a comment.

Thanks for the quick reply

> I don't think this change is responsible. This has been tested by many C++ 
> downstream groups.

What did I do wrong ?
Adding this only commit makes the scenario fail.

> Rust should use upgrade its lib/ProfileData and compiler-rt/lib/profile, and 
> not mix raw profile files at different commits.

I am not sure I understand.
What are raw profiles ? 
In my scenario, only `llvm-profdata` acts on default.profraw
And before that, the linker, not the rust compiler, mixes together the 
different coverage sections...
So, how would Rust mix raw profiles ?

> The binary ID change has caused a bit of churn to ProfileData but it is 
> unrelated to this patch.

Well, there may be other bugs, but this is not a problem in my scenario...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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


[PATCH] D109608: [clang][ASTImporter] Generic attribute import handling (first step).

2021-09-13 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:8448
+
+class AttrImporter {
+  Error Err = Error::success();

shafik wrote:
> @martong the `ASTImporter` file is quite large as it is and I think it makes 
> sense to have `AttrImporter` but perhaps it would help long-term 
> maintainability to split it out into its own source file? What do you think?
Yes, good idea, I agree. Although, I wouldn't insist to do that in this patch, 
a following patch is okay for me.

After all, it would make sense to split ASTNodeImporter into it's own 
implementation file. Or, even better,  we could put Visit*Type, Visit*Decl and 
Visit*Stmt into separate files. Other than that, the ASTImporterTest.cpp test 
file compiles painfully slow, so that is among my TODOs for a while to split 
that up as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109608

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


[PATCH] D108243: Put code that avoids heapifying local blocks behind a flag

2021-09-13 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added a comment.

I was just asking for test cases as I thought it was already a driver option, 
but it turns out it wasn't. I agree that this shouldn't be a driver option.

Sorry @waltl, please revert the changes that made it a driver option in the 
last patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108243

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


[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

2021-09-13 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5069
   // where aliases aren't supported.
-  if (!RawTriple.isOSDarwin() && !RawTriple.isNVPTX() && !RawTriple.isAMDGPU())
 CmdArgs.push_back("-mconstructor-aliases");

This looks like an unrelated change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109707

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


[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

2021-09-13 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

While I think the early inliner is largely obsolete, it should still handle 
aliases correctly


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109707

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


[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

2021-09-13 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 created this revision.
gandhi21299 added reviewers: yaxunl, aeubanks.
Herald added subscribers: foad, kerbowa, hiraditya, tpr, nhaehnle, jvesely, 
arsenm.
gandhi21299 requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

By default clang emits complete contructors as alias of base constructors if 
they are the same. The backend is supposed to emit symbols for the alias, 
otherwise it causes undefined symbols. @yaxunl observed that this issue is 
related to the llvm options `-amdgpu-early-inline-all=true` and 
`-amdgpu-function-calls=false`. Disabling the AlwaysInliner fixes this issue.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109707

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/amdgpu-alias-undef-symbols.hip
  llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp


Index: llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
===
--- llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
+++ llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
@@ -689,8 +689,6 @@
 if (InternalizeSymbols) {
   PM.addPass(GlobalDCEPass());
 }
-if (EarlyInlineAll && !EnableFunctionCalls)
-  PM.addPass(AMDGPUAlwaysInlinePass());
   });
 
   PB.registerCGSCCOptimizerLateEPCallback(
Index: clang/test/CodeGen/amdgpu-alias-undef-symbols.hip
===
--- /dev/null
+++ clang/test/CodeGen/amdgpu-alias-undef-symbols.hip
@@ -0,0 +1,14 @@
+// RUN: %clang -c --offload-arch=gfx906 --cuda-device-only -emit-llvm -S -o - 
%s
+//  -fgpu-rdc -O3 -mllvm -amdgpu-early-inline-all=true -mllvm 
-amdgpu-function-calls=false
+//  FileCheck %s
+
+// CHECK: %struct.B = type { i8 }
+struct B {
+
+  // CHECK: @_ZN1BC1Ei = hidden unnamed_addr alias void (%struct.B*, i32), 
void (%struct.B*, i32)* @_ZN1BC2Ei
+  __device__ B(int x);
+};
+
+__device__ B::B(int x) {
+
+}
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5066,7 +5066,7 @@
   // Enable -mconstructor-aliases except on darwin, where we have to work 
around
   // a linker bug (see ), and CUDA/AMDGPU device code,
   // where aliases aren't supported.
-  if (!RawTriple.isOSDarwin() && !RawTriple.isNVPTX() && !RawTriple.isAMDGPU())
+  if (!RawTriple.isOSDarwin() && !RawTriple.isNVPTX())
 CmdArgs.push_back("-mconstructor-aliases");
 
   // Darwin's kernel doesn't support guard variables; just die if we


Index: llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
===
--- llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
+++ llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
@@ -689,8 +689,6 @@
 if (InternalizeSymbols) {
   PM.addPass(GlobalDCEPass());
 }
-if (EarlyInlineAll && !EnableFunctionCalls)
-  PM.addPass(AMDGPUAlwaysInlinePass());
   });
 
   PB.registerCGSCCOptimizerLateEPCallback(
Index: clang/test/CodeGen/amdgpu-alias-undef-symbols.hip
===
--- /dev/null
+++ clang/test/CodeGen/amdgpu-alias-undef-symbols.hip
@@ -0,0 +1,14 @@
+// RUN: %clang -c --offload-arch=gfx906 --cuda-device-only -emit-llvm -S -o - %s
+//  -fgpu-rdc -O3 -mllvm -amdgpu-early-inline-all=true -mllvm -amdgpu-function-calls=false
+//  FileCheck %s
+
+// CHECK: %struct.B = type { i8 }
+struct B {
+
+  // CHECK: @_ZN1BC1Ei = hidden unnamed_addr alias void (%struct.B*, i32), void (%struct.B*, i32)* @_ZN1BC2Ei
+  __device__ B(int x);
+};
+
+__device__ B::B(int x) {
+
+}
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5066,7 +5066,7 @@
   // Enable -mconstructor-aliases except on darwin, where we have to work around
   // a linker bug (see ), and CUDA/AMDGPU device code,
   // where aliases aren't supported.
-  if (!RawTriple.isOSDarwin() && !RawTriple.isNVPTX() && !RawTriple.isAMDGPU())
+  if (!RawTriple.isOSDarwin() && !RawTriple.isNVPTX())
 CmdArgs.push_back("-mconstructor-aliases");
 
   // Darwin's kernel doesn't support guard variables; just die if we
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D109710: [PowerPC] Add range checks for P10 Vector Builtins

2021-09-13 Thread Quinn Pham via Phabricator via cfe-commits
quinnp created this revision.
Herald added subscribers: shchenz, kbarton, nemanjai.
quinnp requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch adds range checking for some Power10 altivec builtins and
changes the signature of a builtin to match documentation. For `vec_cntm`,
range checking is done via SemaChecking. For `vec_splati_ins`, the second
argument is masked to extract the 0th bit so that we always receive either a `0`
or a `1`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109710

Files:
  clang/lib/Headers/altivec.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-p10vector-error.c
  clang/test/CodeGen/builtins-ppc-p10vector.c

Index: clang/test/CodeGen/builtins-ppc-p10vector.c
===
--- clang/test/CodeGen/builtins-ppc-p10vector.c
+++ clang/test/CodeGen/builtins-ppc-p10vector.c
@@ -1370,10 +1370,12 @@
 }
 
 vector signed int test_vec_vec_splati_ins_si(void) {
+  // CHECK-BE: [[T0:%.+]]] = and %{{.+}}, i32 1
   // CHECK-BE: insertelement <4 x i32> %{{.+}}, i32 %{{.+}}, i32 %{{.+}}
   // CHECK-BE:  [[T1:%.+]] = add i32 2, %{{.+}}
   // CHECK-BE: insertelement <4 x i32> %{{.+}}, i32 %{{.+}}, i32 [[T1]]
   // CHECK-BE: ret <4 x i32>
+  // CHECK-LE: [[T0:%.+]]] = and %{{.+}}, i32 1
   // CHECK-LE:  [[T1:%.+]] = sub i32 1, %{{.+}}
   // CHECK-LE: insertelement <4 x i32> %{{.+}}, i32 %{{.+}}, i32 [[T1]]
   // CHECK-LE:  [[T2:%.+]] = sub i32 3, %{{.+}}
@@ -1383,10 +1385,12 @@
 }
 
 vector unsigned int test_vec_vec_splati_ins_ui(void) {
+  // CHECK-BE: [[T0:%.+]]] = and %{{.+}}, i32 1
   // CHECK-BE: insertelement <4 x i32> %{{.+}}, i32 %{{.+}}, i32 %{{.+}}
   // CHECK-BE:  [[T1:%.+]] = add i32 2, %{{.+}}
   // CHECK-BE: insertelement <4 x i32> %{{.+}}, i32 %{{.+}}, i32 [[T1]]
   // CHECK-BE: ret <4 x i32>
+  // CHECK-LE: [[T0:%.+]]] = and %{{.+}}, i32 1
   // CHECK-LE:  [[T1:%.+]] = sub i32 1, %{{.+}}
   // CHECK-LE: insertelement <4 x i32> %{{.+}}, i32 %{{.+}}, i32 [[T1]]
   // CHECK-LE:  [[T2:%.+]] = sub i32 3, %{{.+}}
@@ -1396,10 +1400,12 @@
 }
 
 vector float test_vec_vec_splati_ins_f(void) {
+  // CHECK-BE: [[T0:%.+]]] = and %{{.+}}, i32 1
   // CHECK-BE: insertelement <4 x float> %{{.+}}, float %{{.+}}, i32 %{{.+}}
   // CHECK-BE:  [[T1:%.+]] = add i32 2, %{{.+}}
   // CHECK-BE: insertelement <4 x float> %{{.+}}, float %{{.+}}, i32 [[T1]]
   // CHECK-BE: ret <4 x float>
+  // CHECK-LE: [[T0:%.+]]] = and %{{.+}}, i32 1
   // CHECK-LE:  [[T1:%.+]] = sub i32 1, %{{.+}}
   // CHECK-LE: insertelement <4 x float> %{{.+}}, float %{{.+}}, i32 [[T1]]
   // CHECK-LE:  [[T2:%.+]] = sub i32 3, %{{.+}}
Index: clang/test/CodeGen/builtins-ppc-p10vector-error.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-p10vector-error.c
@@ -0,0 +1,32 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -target-cpu pwr10 \
+// RUN:   -fsyntax-only -Wall -Werror -verify %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr10 \
+// RUN:   -fsyntax-only -Wall -Werror -verify %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -target-cpu pwr10 \
+// RUN:   -fsyntax-only -Wall -Werror -verify %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -target-cpu pwr10 \
+// RUN:   -fsyntax-only -Wall -Werror -verify %s
+
+#include 
+
+vector unsigned char vuca;
+vector unsigned short vusa;
+vector unsigned int vuia;
+vector unsigned long long vulla;
+
+unsigned long long test_vec_cntm_uc(void) {
+  return vec_cntm(vuca, -1); // expected-error 1+ {{argument value 255 is outside the valid range [0, 1]}}
+}
+
+unsigned long long test_vec_cntm_us(void) {
+  return vec_cntm(vusa, -1); // expected-error 1+ {{argument value 255 is outside the valid range [0, 1]}}
+}
+
+unsigned long long test_vec_cntm_ui(void) {
+  return vec_cntm(vuia, 2); // expected-error 1+ {{argument value 2 is outside the valid range [0, 1]}}
+}
+
+unsigned long long test_vec_cntm_ull(void) {
+  return vec_cntm(vulla, 2); // expected-error 1+  {{argument value 2 is outside the valid range [0, 1]}}
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -3473,6 +3473,11 @@
 return SemaFeatureCheck(*this, TheCall, "isa-v207-instructions",
 diag::err_ppc_builtin_only_on_arch, "8") ||
SemaBuiltinConstantArgRange(TheCall, 1, 1, 16);
+  case PPC::BI__builtin_altivec_vcntmbb:
+  case PPC::BI__builtin_altivec_vcntmbh:
+  case PPC::BI__builtin_altivec_vcntmbw:
+  case PPC::BI__builtin_altivec_vcntmbd:
+return SemaBuiltinConstantArgRange(TheCall, 1, 0, 1);
 #define CUSTOM_BUILTIN(Name, Intr, Types, Acc) \
   case PPC::BI__builtin_##Name: \
 return SemaBuiltinPPCMMACall(TheCall, Types);
Index: 

[PATCH] D109624: [clang] Make the driver not diagnose errors on nonexistent linker inputs

2021-09-13 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Hm, it passes on my win box and on the one running the presubmit test. Do you 
know if there's anything special about your bot? Any idea how I could reproduce 
this? The output is `error: command failed with exit status: True`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109624

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


[PATCH] D108893: clang-tidy: introduce readability-containter-data-pointer check

2021-09-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added inline comments.
This revision is now accepted and ready to land.



Comment at: 
clang-tools-extra/clang-tidy/readability/ContainerDataPointerCheck.cpp:63
+hasType(Container),
+hasType(pointsTo(Container)),
+hasType(references(Container))

compnerd wrote:
> aaron.ballman wrote:
> > Same question here about `pointsTo()`.
> This is actually meant to catch cases such as references to UnOp(DRE).
Good catch and thank you for all the off-list discussion on this point!



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability-container-data-pointer.cpp:104
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:5: warning: 'data' should be used for 
accessing the data pointer instead of taking the address of the 0-th element 
[readability-container-data-pointer]
+}

Can you add one more test for how this behaves on uninstantiated templates?
```
template 
void func(const std::vector ) {
  const Ty *Ptr = [0]; // Should diagnose and provide a fix-it despite not 
instantiating func()
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108893

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


[PATCH] D69764: [clang-format] Add Left/Right Const fixer capability

2021-09-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D69764#2997910 , @MyDeveloperDay 
wrote:

> I think the relevance of Left/Right  East/West as a setting is less 
> important, as its more about an ordering, allowing some tokens to go to the 
> Left and some to the Right of the "type"
>
>   QualifierAlignment: Custom
>   QualifierOrder: [ inline, static, type, const, volatile, restrict ]
>
> While I currently include the Left/Right for some form of completeness I sort 
> of feel i should kill them before we landing this, as I think even my 
> defaults are a little subjective. (unless we can get concencus), hence I 
> don't feel the need to bring back up the Left/Right/East/West debate. If its 
> still a problem later we can add them.

+1, I think this style of configuration is easier to reason about than 
left/right, east/west, before/after, etc because it's an explicit ordering.


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

https://reviews.llvm.org/D69764

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


[PATCH] D69764: [clang-format] Add Left/Right Const fixer capability

2021-09-13 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 372292.
MyDeveloperDay added a comment.

QualifierAlignmentFixer need to process all the Left/Right passes internally 
before return the fixes on the original code. So now QualifierAlignmentFixer 
has its own inner set of passes which will be processed, and then "no op" fixes 
(replacements which make no change to the original code are removed (this was a 
problem before, as multiple passes causes changes that changed one way then 
changed it back  "static const int a;" -> "const static int a;" -> "static 
const a;"

Move QualifierAlignmentFixer tests out to its own unit test file so Ultimately 
I can add more "Unit tests" on the functions

Still WIP but getting much closer.


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

https://reviews.llvm.org/D69764

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/CMakeLists.txt
  clang/lib/Format/Format.cpp
  clang/lib/Format/QualifierAlignmentFixer.cpp
  clang/lib/Format/QualifierAlignmentFixer.h
  clang/tools/clang-format/ClangFormat.cpp
  clang/unittests/Format/CMakeLists.txt
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/QualifierFixerTest.cpp

Index: clang/unittests/Format/QualifierFixerTest.cpp
===
--- /dev/null
+++ clang/unittests/Format/QualifierFixerTest.cpp
@@ -0,0 +1,643 @@
+//===- unittest/Format/QualifierFixerTest.cpp - Formatting unit tests -===//
+//
+// 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
+//
+//===--===//
+
+#include "clang/Format/Format.h"
+
+#include "FormatTestUtils.h"
+#include "TestLexer.h"
+#include "gtest/gtest.h"
+
+#include "../../lib/Format/QualifierAlignmentFixer.h"
+
+#define DEBUG_TYPE "format-qualifier-fixer-test"
+
+using testing::ScopedTrace;
+
+namespace clang {
+namespace format {
+namespace {
+
+#define CHECK_PARSE(TEXT, FIELD, VALUE)\
+  EXPECT_NE(VALUE, Style.FIELD) << "Initial value already the same!";  \
+  EXPECT_EQ(0, parseConfiguration(TEXT, ).value());  \
+  EXPECT_EQ(VALUE, Style.FIELD) << "Unexpected value after parsing!"
+
+#define FAIL_PARSE(TEXT, FIELD, VALUE) \
+  EXPECT_NE(0, parseConfiguration(TEXT, ).value());  \
+  EXPECT_EQ(VALUE, Style.FIELD) << "Unexpected value after parsing!"
+
+class QualifierFixerTest : public ::testing::Test {
+protected:
+  enum StatusCheck { SC_ExpectComplete, SC_ExpectIncomplete, SC_DoNotCheck };
+
+  std::string format(llvm::StringRef Code,
+ const FormatStyle  = getLLVMStyle(),
+ StatusCheck CheckComplete = SC_ExpectComplete) {
+LLVM_DEBUG(llvm::errs() << "---\n");
+LLVM_DEBUG(llvm::errs() << Code << "\n\n");
+std::vector Ranges(1, tooling::Range(0, Code.size()));
+FormattingAttemptStatus Status;
+tooling::Replacements Replaces =
+reformat(Style, Code, Ranges, "", );
+if (CheckComplete != SC_DoNotCheck) {
+  bool ExpectedCompleteFormat = CheckComplete == SC_ExpectComplete;
+  EXPECT_EQ(ExpectedCompleteFormat, Status.FormatComplete)
+  << Code << "\n\n";
+}
+ReplacementCount = Replaces.size();
+auto Result = applyAllReplacements(Code, Replaces);
+EXPECT_TRUE(static_cast(Result));
+LLVM_DEBUG(llvm::errs() << "\n" << *Result << "\n\n");
+return *Result;
+  }
+
+  FormatStyle getStyleWithColumns(FormatStyle Style, unsigned ColumnLimit) {
+Style.ColumnLimit = ColumnLimit;
+return Style;
+  }
+
+  FormatStyle getLLVMStyleWithColumns(unsigned ColumnLimit) {
+return getStyleWithColumns(getLLVMStyle(), ColumnLimit);
+  }
+
+  void _verifyFormat(const char *File, int Line, llvm::StringRef Expected,
+ llvm::StringRef Code,
+ const FormatStyle  = getLLVMStyle()) {
+ScopedTrace t(File, Line, ::testing::Message() << Code.str());
+EXPECT_EQ(Expected.str(), format(Expected, Style))
+<< "Expected code is not stable";
+EXPECT_EQ(Expected.str(), format(Code, Style));
+if (Style.Language == FormatStyle::LK_Cpp) {
+  // Objective-C++ is a superset of C++, so everything checked for C++
+  // needs to be checked for Objective-C++ as well.
+  FormatStyle ObjCStyle = Style;
+  ObjCStyle.Language = FormatStyle::LK_ObjC;
+  EXPECT_EQ(Expected.str(), format(test::messUp(Code), ObjCStyle));
+}
+  }
+
+  void _verifyFormat(const char *File, int Line, llvm::StringRef Code,
+ const FormatStyle  = getLLVMStyle()) {
+_verifyFormat(File, Line, Code, test::messUp(Code), Style);
+  }
+
+  void 

[PATCH] D109701: [clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

2021-09-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman edited reviewers, added: aaron.ballman; removed: rsmith.
aaron.ballman added a subscriber: lattner.
aaron.ballman added a comment.

In D109701#2997892 , @lattner wrote:

> I'm not sure who the best person is to review this, but it isn't me anymore 
> sadly.  Richard, can you recommend someone?

It's likely me -- I added the original SARIF implementation. It'll be a bit 
before I have the chance to give this a thorough review though, in case others 
who know SARIF would like to chime in.

Btw, is the intent for this functionality to replace what's in 
SarifDiagnostics.cpp 
(https://github.com/llvm/llvm-project/blob/main/clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp)
 fairly immediately? Or are we going to carry both implementations? (Having put 
very little consideration into it, it seems like the static analysis output 
would be a good test of how well your changes work in practice as there are 
tools out there already consuming that output.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109701

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


[PATCH] D108243: Put code that avoids heapifying local blocks behind a flag

2021-09-13 Thread James Y Knight via Phabricator via cfe-commits
jyknight added a comment.

In D108243#2995898 , @waltl wrote:

> Added driver flags, and tests for them

@ahatanak did you intend to ask Walt to add a driver flag for this?

I think we should not have one, since this isn't something we should be telling 
users to specify, or that we want to promise stability for.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108243

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


[PATCH] D69764: [clang-format] Add Left/Right Const fixer capability

2021-09-13 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

I think the relevance of Left/Right  East/West as a setting is less important, 
as its more about an ordering, allowing some tokens to go to the Left and some 
to the Right of the "type"

  QualifierAlignment: Custom
  QualifierOrder: [ inline, static, type, const, volatile, restrict ]

While I currently include the Left/Right for some form of completeness I sort 
of feel i should kill them before we landing this, as I think even my defaults 
are a little subjective. (unless we can get concencus), hence I don't feel the 
need to bring back up the Left/Right/East/West debate. If its still a problem 
later we can add them.

  if (Style.QualifierAlignment == FormatStyle::QAS_Right) {
Style.QualifierOrder.clear();
Style.QualifierOrder.push_back("type");
Style.QualifierOrder.push_back("const");
Style.QualifierOrder.push_back("volatile");
  } else if (Style.QualifierAlignment == FormatStyle::QAS_Left) {
Style.QualifierOrder.clear();
Style.QualifierOrder.push_back("const");
Style.QualifierOrder.push_back("volatile");
Style.QualifierOrder.push_back("type");
  }


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

https://reviews.llvm.org/D69764

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


[PATCH] D109557: Adds an AlignCloseBracket option

2021-09-13 Thread Cameron Mulhern via Phabricator via cfe-commits
csmulhern added a comment.

I've added more information to my original message. Please let me know if 
further context is desired.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109557

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


[PATCH] D109701: [clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

2021-09-13 Thread Chris Lattner via Phabricator via cfe-commits
lattner resigned from this revision.
lattner edited reviewers, added: rsmith; removed: lattner.
lattner added a comment.

I'm not sure who the best person is to review this, but it isn't me anymore 
sadly.  Richard, can you recommend someone?




Comment at: clang/lib/Basic/Sarif.cpp:1
+#include "clang/Basic/Sarif.h"
+#include "clang/Basic/LangOptions.h"

THis nees the standard header boilerplate per the coding standards doc



Comment at: clang/lib/Basic/Sarif.cpp:27
+
+StringRef getFileName(const FileEntry ) {
+  StringRef Filename = FE.tryGetRealPathName();

vaibhav.y wrote:
> A lot of these are copied from [[ 
> https://github.com/llvm/llvm-project/blob/181d18ef53db1e5810bf6b905fbafc91da9b5baa/clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp#L64
>  | SarifDiagnostics.cpp ]]
Please use static methods instead of anonymous namespaces, per the coding 
standards doc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109701

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


[PATCH] D109701: [clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

2021-09-13 Thread Vaibhav Yenamandra via Phabricator via cfe-commits
vaibhav.y added inline comments.



Comment at: clang/include/clang/Basic/Sarif.h:69
+/// Reference:
+/// 1. https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html#_Toc34317427;>artifactLocation
 object
+/// 2. \ref SarifArtifact

I'm not sure how to deal with overlength links in docs directly, turning clang 
format off & on on comments also seems counter-productive. Would it be okay to 
add an alias in the doxyfile for the root page of SARIF docs?

E.g.:

```
ALIASES = 
sarifDocs="https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html;
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109701

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


[PATCH] D109701: [clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

2021-09-13 Thread Vaibhav Yenamandra via Phabricator via cfe-commits
vaibhav.y updated this revision to Diff 372289.
vaibhav.y added a comment.

[clangBasic] Fixup header guard


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109701

Files:
  clang/include/clang/Basic/Sarif.h
  clang/include/clang/Basic/SourceLocation.h
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Sarif.cpp
  clang/lib/Basic/SourceLocation.cpp
  clang/unittests/Basic/CMakeLists.txt
  clang/unittests/Basic/SarifTest.cpp

Index: clang/unittests/Basic/SarifTest.cpp
===
--- /dev/null
+++ clang/unittests/Basic/SarifTest.cpp
@@ -0,0 +1,153 @@
+//===- unittests/Basic/SarifTest.cpp - Test writing SARIF documents ---===//
+//
+// 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
+//
+//===--===//
+
+#include "clang/Basic/Sarif.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include 
+
+#include "gmock/gmock.h"
+#include "gtest/gtest-death-test.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+using namespace llvm;
+
+namespace {
+
+TEST(SarifDocumentWriterTest, createEmptyDocument) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+
+  // WHEN:
+  const json::Object  = writer.createDocument();
+  std::vector keys(emptyDocument.size());
+  std::transform(emptyDocument.begin(), emptyDocument.end(), keys.begin(),
+ [](auto item) { return item.getFirst(); });
+
+  // THEN:
+  ASSERT_THAT(keys, testing::UnorderedElementsAre("$schema", "version"));
+}
+
+// Test that a newly inserted run will associate correct tool names
+TEST(SarifDocumentWriterTest, documentWithARun) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+  const char *shortName = "sariftest";
+  const char *longName = "sarif writer test";
+
+  // WHEN:
+  writer.createRun(shortName, longName);
+  writer.endRun();
+  const json::Object  = writer.createDocument();
+  const json::Array *runs = document.getArray("runs");
+
+  // THEN:
+  // A run was created
+  ASSERT_THAT(runs, testing::NotNull());
+
+  // It is the only run
+  ASSERT_EQ(runs->size(), 1UL);
+
+  // The tool associated with the run was the tool
+  const json::Object *driver =
+  runs->begin()->getAsObject()->getObject("tool")->getObject("driver");
+  ASSERT_THAT(driver, testing::NotNull());
+
+  ASSERT_TRUE(driver->getString("name").hasValue());
+  ASSERT_TRUE(driver->getString("fullName").hasValue());
+  ASSERT_TRUE(driver->getString("language").hasValue());
+
+  EXPECT_EQ(driver->getString("name").getValue(), shortName);
+  EXPECT_EQ(driver->getString("fullName").getValue(), longName);
+  EXPECT_EQ(driver->getString("language").getValue(), "en-US");
+}
+
+// Test adding result without a run causes a crash
+TEST(SarifDocumentWriterTest, addingResultsWillCrashIfThereIsNoRun) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+  SarifResult & = SarifResult::create();
+
+  // WHEN:
+  //  A SarifDocumentWriter::createRun(...) was not called prior to
+  //  SarifDocumentWriter::appendResult(...)
+  // But a rule exists
+  auto ruleIdx = writer.createRule(SarifRule::create());
+
+  // THEN:
+  ASSERT_DEATH({ writer.appendResult(ruleIdx, emptyResult); },
+   ".*create a run first.*");
+}
+
+// Test adding result for invalid ruleIdx causes a crash
+TEST(SarifDocumentWriterTest, addingResultsWithoutRuleWillCrash) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+  SarifResult & = SarifResult::create();
+
+  // WHEN:
+  writer.createRun("sarif test", "sarif test runner");
+  // But caller forgot to create a rule for this run:
+
+  // THEN:
+  ASSERT_DEATH({ writer.appendResult(0, emptyResult); },
+   "Trying to reference a rule that doesn't exist");
+}
+
+// Test adding rule and result shows up in the final document
+TEST(SarifDocumentWriterTest, addResultWIthValidRuleIsOk) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+  const SarifResult  = SarifResult::create();
+  const SarifRule  =
+  SarifRule::create()
+  .setRuleId("clang.unittest")
+  .setDescription("Example rule created during unit tests")
+  .setName("clang unit test");
+
+  // WHEN:
+  writer.createRun("sarif test", "sarif test runner");
+  unsigned ruleIdx = writer.createRule(rule);
+  writer.appendResult(ruleIdx, result);
+  const json::Object  = writer.createDocument();
+
+  // THEN:
+  // A document with a valid schema and version exists
+  ASSERT_THAT(document.get("$schema"), ::testing::NotNull());
+  ASSERT_THAT(document.get("version"), ::testing::NotNull());
+  const json::Array *runs = document.getArray("runs");
+
+  // A run exists on this document
+  ASSERT_THAT(runs, ::testing::NotNull());
+  ASSERT_EQ(runs->size(), 1UL);
+  const json::Object *theRun = 

[PATCH] D109461: [clang][darwin] Add support for --emit-static-lib

2021-09-13 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl accepted this revision.
yaxunl added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109461

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


[PATCH] D109461: [clang][darwin] Add support for --emit-static-lib

2021-09-13 Thread Keith Smiley via Phabricator via cfe-commits
keith updated this revision to Diff 372287.
keith added a comment.

Revert unrelated formatting fixes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109461

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/test/Driver/bindings.c
  clang/test/Driver/darwin-static-lib.c

Index: clang/test/Driver/darwin-static-lib.c
===
--- /dev/null
+++ clang/test/Driver/darwin-static-lib.c
@@ -0,0 +1,5 @@
+// RUN: %clang -target i386-apple-darwin9 %s -### --emit-static-lib 2>&1 | FileCheck %s
+// CHECK: "{{.*}}libtool" "-static" "-D" "-no_warning_for_no_symbols" "-o" "a.out" "{{.*o}}"
+
+// RUN: %clang -target i386-apple-darwin9 %s -### --emit-static-lib -o libfoo.a 2>&1 | FileCheck %s --check-prefix=OUTPUT
+// OUTPUT: "{{.*}}libtool" "-static" "-D" "-no_warning_for_no_symbols" "-o" "libfoo.a" "{{.*o}}"
Index: clang/test/Driver/bindings.c
===
--- clang/test/Driver/bindings.c
+++ clang/test/Driver/bindings.c
@@ -27,3 +27,7 @@
 // GNU StaticLibTool binding
 // RUN: %clang -target x86_64-linux-gnu -ccc-print-bindings --emit-static-lib %s 2>&1 | FileCheck %s --check-prefix=CHECK15
 // CHECK15: "x86_64-unknown-linux-gnu" - "GNU::StaticLibTool", inputs: ["{{.*}}.o"], output: "a.out"
+
+// Darwin StaticLibTool binding
+// RUN: %clang -target i386-apple-darwin9 -ccc-print-bindings --emit-static-lib %s 2>&1 | FileCheck %s --check-prefix=CHECK16
+// CHECK16: "i386-apple-darwin9" - "darwin::StaticLibTool", inputs: ["{{.*}}.o"], output: "a.out"
Index: clang/lib/Driver/ToolChains/Darwin.h
===
--- clang/lib/Driver/ToolChains/Darwin.h
+++ clang/lib/Driver/ToolChains/Darwin.h
@@ -78,6 +78,20 @@
 const char *LinkingOutput) const override;
 };
 
+class LLVM_LIBRARY_VISIBILITY StaticLibTool : public MachOTool {
+public:
+  StaticLibTool(const ToolChain )
+  : MachOTool("darwin::StaticLibTool", "static-lib-linker", TC) {}
+
+  bool hasIntegratedCPP() const override { return false; }
+  bool isLinkJob() const override { return true; }
+
+  void ConstructJob(Compilation , const JobAction ,
+const InputInfo , const InputInfoList ,
+const llvm::opt::ArgList ,
+const char *LinkingOutput) const override;
+};
+
 class LLVM_LIBRARY_VISIBILITY Lipo : public MachOTool {
 public:
   Lipo(const ToolChain ) : MachOTool("darwin::Lipo", "lipo", TC) {}
@@ -125,6 +139,7 @@
 protected:
   Tool *buildAssembler() const override;
   Tool *buildLinker() const override;
+  Tool *buildStaticLibTool() const override;
   Tool *getTool(Action::ActionClass AC) const override;
 
 private:
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -729,6 +729,54 @@
   C.addCommand(std::move(Cmd));
 }
 
+void darwin::StaticLibTool::ConstructJob(Compilation , const JobAction ,
+ const InputInfo ,
+ const InputInfoList ,
+ const ArgList ,
+ const char *LinkingOutput) const {
+  const Driver  = getToolChain().getDriver();
+
+  // Silence warning for "clang -g foo.o -o foo"
+  Args.ClaimAllArgs(options::OPT_g_Group);
+  // and "clang -emit-llvm foo.o -o foo"
+  Args.ClaimAllArgs(options::OPT_emit_llvm);
+  // and for "clang -w foo.o -o foo". Other warning options are already
+  // handled somewhere else.
+  Args.ClaimAllArgs(options::OPT_w);
+  // Silence warnings when linking C code with a C++ '-stdlib' argument.
+  Args.ClaimAllArgs(options::OPT_stdlib_EQ);
+
+  // libtool   
+  ArgStringList CmdArgs;
+  // Create and insert file members with a deterministic index.
+  CmdArgs.push_back("-static");
+  CmdArgs.push_back("-D");
+  CmdArgs.push_back("-no_warning_for_no_symbols");
+  CmdArgs.push_back("-o");
+  CmdArgs.push_back(Output.getFilename());
+
+  for (const auto  : Inputs) {
+if (II.isFilename()) {
+  CmdArgs.push_back(II.getFilename());
+}
+  }
+
+  // Delete old output archive file if it already exists before generating a new
+  // archive file.
+  const auto *OutputFileName = Output.getFilename();
+  if (Output.isFilename() && llvm::sys::fs::exists(OutputFileName)) {
+if (std::error_code EC = llvm::sys::fs::remove(OutputFileName)) {
+  D.Diag(diag::err_drv_unable_to_remove_file) << EC.message();
+  return;
+}
+  }
+
+  const char *Exec = Args.MakeArgString(getToolChain().GetStaticLibToolPath());
+  C.addCommand(std::make_unique(JA, *this,
+ 

[PATCH] D109557: Adds an AlignCloseBracket option

2021-09-13 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

Please resubmit the patch with full context


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109557

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


[PATCH] D108893: clang-tidy: introduce readability-containter-data-pointer check

2021-09-13 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd updated this revision to Diff 372285.
compnerd added a comment.

Address review feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108893

Files:
  clang-tools-extra/clang-tidy/readability/CMakeLists.txt
  clang-tools-extra/clang-tidy/readability/ContainerDataPointerCheck.cpp
  clang-tools-extra/clang-tidy/readability/ContainerDataPointerCheck.h
  clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-data-pointer.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-container-data-pointer.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-container-data-pointer.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability-container-data-pointer.cpp
@@ -0,0 +1,104 @@
+// RUN: %check_clang_tidy %s readability-container-data-pointer %t
+
+typedef __SIZE_TYPE__ size_t;
+
+namespace std {
+template 
+struct vector {
+  using size_type = size_t;
+
+  vector();
+  explicit vector(size_type);
+
+  T *data();
+  const T *data() const;
+
+  T [](size_type);
+  const T [](size_type) const;
+};
+
+template 
+struct basic_string {
+  using size_type = size_t;
+
+  basic_string();
+
+  T *data();
+  const T *data() const;
+
+  T [](size_t);
+  const T [](size_type) const;
+};
+
+typedef basic_string string;
+typedef basic_string wstring;
+
+template 
+struct is_integral;
+
+template <>
+struct is_integral {
+  static const bool value = true;
+};
+
+template 
+struct enable_if { };
+
+template 
+struct enable_if {
+  typedef T type;
+};
+}
+
+template 
+void f(const T *);
+
+#define z (0)
+
+void g(size_t s) {
+  std::vector b(s);
+  f(&((b)[(z)]));
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'data' should be used for accessing the data pointer instead of taking the address of the 0-th element [readability-container-data-pointer]
+  // CHECK-FIXES: {{^  }}f(b.data());{{$}}
+}
+
+void h() {
+  std::string s;
+  f(&((s).operator[]((z;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'data' should be used for accessing the data pointer instead of taking the address of the 0-th element [readability-container-data-pointer]
+  // CHECK-FIXES: {{^  }}f(s.data());{{$}}
+
+  std::wstring w;
+  f(&((&(w))->operator[]((z;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'data' should be used for accessing the data pointer instead of taking the address of the 0-th element [readability-container-data-pointer]
+  // CHECK-FIXES: {{^  }}f(w.data());{{$}}
+}
+
+template ::value>::type>
+void i(U s) {
+  std::vector b(s);
+  f([0]);
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'data' should be used for accessing the data pointer instead of taking the address of the 0-th element [readability-container-data-pointer]
+  // CHECK-FIXES: {{^  }}f(b.data());{{$}}
+}
+
+template void i(size_t);
+
+void j(std::vector * const v) {
+  f(&(*v)[0]);
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'data' should be used for accessing the data pointer instead of taking the address of the 0-th element [readability-container-data-pointer]
+  // CHECK-FIXES: {{^  }}f(v->data());{{$}}
+}
+
+void k(const std::vector ) {
+  f([0]);
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'data' should be used for accessing the data pointer instead of taking the address of the 0-th element [readability-container-data-pointer]
+  // CHECK-FIXES: {{^  }}f(v.data());{{$}}
+}
+
+void l() {
+  unsigned char b[32];
+  f([0]);
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:5: warning: 'data' should be used for accessing the data pointer instead of taking the address of the 0-th element [readability-container-data-pointer]
+}
Index: clang-tools-extra/docs/clang-tidy/checks/readability-data-pointer.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/readability-data-pointer.rst
@@ -0,0 +1,13 @@
+.. title:: clang-tidy - readability-data-pointer
+
+readability-data-pointer
+
+
+Finds cases where code could use ``data()`` rather than the address of the
+element at index 0 in a container.  This pattern is commonly used to materialize
+a pointer to the backing data of a container.  ``std::vector`` and
+``std::string`` provide a ``data()`` accessor to retrieve the data pointer which
+should be preferred.
+
+This also ensures that in the case that the container is empty, the data pointer
+access does not perform an errant memory access.
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -91,6 +91,11 @@
   variables and function parameters only.
 
 
+- New :doc:`readability-data-pointer (
 

[PATCH] D109461: [clang][darwin] Add support for --emit-static-lib

2021-09-13 Thread Keith Smiley via Phabricator via cfe-commits
keith updated this revision to Diff 372286.
keith marked an inline comment as done.
keith added a comment.

Fix formatting and comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109461

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/test/Driver/bindings.c
  clang/test/Driver/darwin-static-lib.c

Index: clang/test/Driver/darwin-static-lib.c
===
--- /dev/null
+++ clang/test/Driver/darwin-static-lib.c
@@ -0,0 +1,5 @@
+// RUN: %clang -target i386-apple-darwin9 %s -### --emit-static-lib 2>&1 | FileCheck %s
+// CHECK: "{{.*}}libtool" "-static" "-D" "-no_warning_for_no_symbols" "-o" "a.out" "{{.*o}}"
+
+// RUN: %clang -target i386-apple-darwin9 %s -### --emit-static-lib -o libfoo.a 2>&1 | FileCheck %s --check-prefix=OUTPUT
+// OUTPUT: "{{.*}}libtool" "-static" "-D" "-no_warning_for_no_symbols" "-o" "libfoo.a" "{{.*o}}"
Index: clang/test/Driver/bindings.c
===
--- clang/test/Driver/bindings.c
+++ clang/test/Driver/bindings.c
@@ -27,3 +27,7 @@
 // GNU StaticLibTool binding
 // RUN: %clang -target x86_64-linux-gnu -ccc-print-bindings --emit-static-lib %s 2>&1 | FileCheck %s --check-prefix=CHECK15
 // CHECK15: "x86_64-unknown-linux-gnu" - "GNU::StaticLibTool", inputs: ["{{.*}}.o"], output: "a.out"
+
+// Darwin StaticLibTool binding
+// RUN: %clang -target i386-apple-darwin9 -ccc-print-bindings --emit-static-lib %s 2>&1 | FileCheck %s --check-prefix=CHECK16
+// CHECK16: "i386-apple-darwin9" - "darwin::StaticLibTool", inputs: ["{{.*}}.o"], output: "a.out"
Index: clang/lib/Driver/ToolChains/Darwin.h
===
--- clang/lib/Driver/ToolChains/Darwin.h
+++ clang/lib/Driver/ToolChains/Darwin.h
@@ -78,6 +78,20 @@
 const char *LinkingOutput) const override;
 };
 
+class LLVM_LIBRARY_VISIBILITY StaticLibTool : public MachOTool {
+public:
+  StaticLibTool(const ToolChain )
+  : MachOTool("darwin::StaticLibTool", "static-lib-linker", TC) {}
+
+  bool hasIntegratedCPP() const override { return false; }
+  bool isLinkJob() const override { return true; }
+
+  void ConstructJob(Compilation , const JobAction ,
+const InputInfo , const InputInfoList ,
+const llvm::opt::ArgList ,
+const char *LinkingOutput) const override;
+};
+
 class LLVM_LIBRARY_VISIBILITY Lipo : public MachOTool {
 public:
   Lipo(const ToolChain ) : MachOTool("darwin::Lipo", "lipo", TC) {}
@@ -125,6 +139,7 @@
 protected:
   Tool *buildAssembler() const override;
   Tool *buildLinker() const override;
+  Tool *buildStaticLibTool() const override;
   Tool *getTool(Action::ActionClass AC) const override;
 
 private:
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -196,8 +196,8 @@
   return true;
 if (A->getOption().matches(options::OPT_O))
   return llvm::StringSwitch(A->getValue())
-.Case("1", true)
-.Default(false);
+  .Case("1", true)
+  .Default(false);
 return false; // OPT_Ofast & OPT_O4
   }
 
@@ -296,8 +296,8 @@
 if ((A = Args.getLastArg(options::OPT_compatibility__version)) ||
 (A = Args.getLastArg(options::OPT_current__version)) ||
 (A = Args.getLastArg(options::OPT_install__name)))
-  D.Diag(diag::err_drv_argument_only_allowed_with) << A->getAsString(Args)
-   << "-dynamiclib";
+  D.Diag(diag::err_drv_argument_only_allowed_with)
+  << A->getAsString(Args) << "-dynamiclib";
 
 Args.AddLastArg(CmdArgs, options::OPT_force__flat__namespace);
 Args.AddLastArg(CmdArgs, options::OPT_keep__private__externs);
@@ -312,8 +312,8 @@
 (A = Args.getLastArg(options::OPT_force__flat__namespace)) ||
 (A = Args.getLastArg(options::OPT_keep__private__externs)) ||
 (A = Args.getLastArg(options::OPT_private__bundle)))
-  D.Diag(diag::err_drv_argument_not_allowed_with) << A->getAsString(Args)
-  << "-dynamiclib";
+  D.Diag(diag::err_drv_argument_not_allowed_with)
+  << A->getAsString(Args) << "-dynamiclib";
 
 Args.AddAllArgsTranslated(CmdArgs, options::OPT_compatibility__version,
   "-dylib_compatibility_version");
@@ -729,6 +729,54 @@
   C.addCommand(std::move(Cmd));
 }
 
+void darwin::StaticLibTool::ConstructJob(Compilation , const JobAction ,
+ const InputInfo ,
+ const InputInfoList ,
+  

[PATCH] D108893: clang-tidy: introduce readability-containter-data-pointer check

2021-09-13 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd marked 7 inline comments as done.
compnerd added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/ContainerDataPointerCheck.cpp:63
+hasType(Container),
+hasType(pointsTo(Container)),
+hasType(references(Container))

aaron.ballman wrote:
> Same question here about `pointsTo()`.
This is actually meant to catch cases such as references to UnOp(DRE).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108893

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


[PATCH] D109624: [clang] Make the driver not diagnose errors on nonexistent linker inputs

2021-09-13 Thread Petr Hosek via Phabricator via cfe-commits
phosek added a comment.

`Clang :: Driver/cl.c` started failing on our Windows bots after this change 
landed. Here 

 is the error output is, would it be possible to take a look and revert the 
change if needed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109624

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


[PATCH] D109608: [clang][ASTImporter] Generic attribute import handling (first step).

2021-09-13 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:711
+
+/*template
+friend struct AttrArgImporter;

Looks like left over unused code?



Comment at: clang/lib/AST/ASTImporter.cpp:8448
+
+class AttrImporter {
+  Error Err = Error::success();

@martong the `ASTImporter` file is quite large as it is and I think it makes 
sense to have `AttrImporter` but perhaps it would help long-term 
maintainability to split it out into its own source file? What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109608

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


[PATCH] D109703: [DebugInfo] Fix scope for local static variables

2021-09-13 Thread Kristina Bessonova via Phabricator via cfe-commits
krisb created this revision.
krisb added reviewers: dblaikie, probinson.
Herald added a subscriber: hiraditya.
krisb requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This fixes https://bugs.llvm.org/show_bug.cgi?id=44695 (and likely
https://bugs.llvm.org/show_bug.cgi?id=30637).

On clang side we need to place static locals defined within a bracketed
block into a correct scope. Since getContextDescriptor() does no access lexical
blocks, just pick the innermost lexical scope early.

On llvm side the patch proposes to delay emission of static locals until their
parent scopes are created (just like normal local variables).
In case of inlined function, static locals are created only for abstract
entities (as per suggestions from https://bugs.llvm.org/show_bug.cgi?id=30637).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109703

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/debug-info-static.c
  llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
  llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.h
  llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
  llvm/test/DebugInfo/Generic/static-locals.ll
  llvm/test/DebugInfo/X86/gnu-public-names.ll

Index: llvm/test/DebugInfo/X86/gnu-public-names.ll
===
--- llvm/test/DebugInfo/X86/gnu-public-names.ll
+++ llvm/test/DebugInfo/X86/gnu-public-names.ll
@@ -137,19 +137,6 @@
 ; CHECK-NOT: {{DW_TAG|NULL}}
 ; CHECK: DW_AT_name {{.*}} "global_namespace_function"
 
-; CHECK: DW_TAG_subprogram
-; CHECK-NOT: {{DW_TAG|NULL}}
-; CHECK:   DW_AT_name {{.*}} "f3"
-; CHECK-NOT: {{DW_TAG|NULL}}
-; CHECK: [[F3_Z:.*]]:   DW_TAG_variable
-; CHECK-NOT: DW_TAG
-; CHECK: DW_AT_name {{.*}} "z"
-; CHECK-NOT: {{DW_TAG|NULL}}
-; CHECK: DW_AT_location
-; CHECK-NOT: {{DW_TAG|NULL}}
-; CHECK:   NULL
-; CHECK-NOT: {{DW_TAG|NULL}}
-
 ; CHECK: [[ANON:.*]]: DW_TAG_namespace
 ; CHECK-NOT:   DW_AT_name
 ; CHECK: [[ANON_I:.*]]: DW_TAG_variable
@@ -237,6 +224,19 @@
 ; CHECK: DW_AT_linkage_name
 ; CHECK-NOT: {{DW_TAG|NULL}}
 ; CHECK: DW_AT_name {{.*}} "global_function"
+; CHECK-NOT: {{DW_TAG|NULL}}
+
+; CHECK: DW_TAG_subprogram
+; CHECK-NOT: {{DW_TAG|NULL}}
+; CHECK:   DW_AT_name {{.*}} "f3"
+; CHECK-NOT: {{DW_TAG|NULL}}
+; CHECK: [[F3_Z:.*]]:   DW_TAG_variable
+; CHECK-NOT: DW_TAG
+; CHECK: DW_AT_name {{.*}} "z"
+; CHECK-NOT: {{DW_TAG|NULL}}
+; CHECK: DW_AT_location
+; CHECK-NOT: {{DW_TAG|NULL}}
+; CHECK:   NULL
 
 ; CHECK-LABEL: .debug_gnu_pubnames contents:
 ; CHECK-NEXT: length = {{.*}}, version = 0x0002, unit_offset = 0x, unit_size = {{.*}}
@@ -250,8 +250,8 @@
 ; comes out naturally from LLVM's implementation, so I'm OK with it for now. If
 ; it's demonstrated that this is a major size concern or degrades debug info
 ; consumer behavior, feel free to change it.
-; CHECK-NEXT:  [[F3_Z]] STATIC VARIABLE "f3::z"
 ; CHECK-NEXT:  [[ANON]] EXTERNAL TYPE "(anonymous namespace)"
+; CHECK-NEXT:  [[F3_Z]] STATIC VARIABLE "f3::z"
 ; CHECK-NEXT:  [[OUTER_ANON]] EXTERNAL TYPE "outer::(anonymous namespace)"
 ; CHECK-NEXT:  [[ANON_INNER_B]] STATIC VARIABLE "(anonymous namespace)::inner::b"
 ; CHECK-NEXT:  [[OUTER]] EXTERNAL TYPE "outer"
Index: llvm/test/DebugInfo/Generic/static-locals.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/Generic/static-locals.ll
@@ -0,0 +1,204 @@
+; RUN: %llc_dwarf -O0 -filetype=obj < %s \
+; RUN:   | llvm-dwarfdump -debug-info -  \
+; RUN:   | FileCheck --implicit-check-not "{{DW_TAG|NULL}}" %s
+
+; Generated from:
+
+; static int global = 42;
+;
+; inline __attribute__((always_inline))
+; int inlined() {
+;   static int inlined_a = 1;
+;   if (global > 100) {
+; static int inlined_b = 2;
+; return inlined_b;
+;   }
+;   {
+; static int inlined_c = 3;
+; inlined_a = inlined_c;
+;   }
+;   return inlined_a;
+; }
+;
+; int foo() {
+;   static int a = 1;
+;   if (global < 100) {
+; static int b = 2;
+; return b;
+;   }
+;   {
+; static int c = 3;
+; a = c;
+;   }
+;   return a;
+; }
+;
+; int far() {
+;   return inlined();
+; }
+
+; CHECK: DW_TAG_compile_unit
+; CHECK: DW_TAG_variable
+; CHECK: DW_AT_name	("global")
+; CHECK: DW_TAG_base_type
+
+; foo().
+; CHECK: DW_TAG_subprogram
+; CHECK:   DW_AT_name	("foo")
+; CHECK:   DW_TAG_variable
+; CHECK: DW_AT_name	("a")
+; CHECK:   DW_TAG_lexical_block
+; CHECK: DW_TAG_variable
+; CHECK:   DW_AT_name	("b")
+; CHECK: NULL
+; CHECK:   DW_TAG_lexical_block
+; CHECK: DW_TAG_variable
+; CHECK:   DW_AT_name	("c")
+; CHECK:   NULL
+; CHECK: NULL
+
+; inlined().
+; CHECK: DW_TAG_subprogram
+; CHECK:   DW_AT_name  ("inlined")
+; CHECK:   DW_AT_inline  (DW_INL_inlined)
+; CHECK:   DW_TAG_variable
+; CHECK: DW_AT_name	("inlined_a")
+; CHECK:   DW_TAG_lexical_block
+; CHECK: DW_TAG_variable
+; CHECK:   DW_AT_name	("inlined_b")
+; CHECK: NULL
+; 

[PATCH] D109128: [VFS] Use original path when falling back to external FS

2021-09-13 Thread Keith Smiley via Phabricator via cfe-commits
keith added a comment.

In D109128#2997588 , @JDevlieghere 
wrote:

> If I understand correctly, this patch does that, but swaps 2 and 3. What's 
> the motivation for trying the non-canonical path first? If we treat the 
> current working directory as a property directory (which is what the 
> canonicalization is all about), then it seems like we should exhaust those 
> options first.

Using the canonical path first is the root of the problem, using that first the 
behavior to return the absolute path virtually always, for example in my new 
test these assertions

  EXPECT_EQ("a", Name.get());
  EXPECT_EQ("a", OpenedS->getName());

fail and would have to be converted to:

  EXPECT_EQ("//root/foo/a", Name.get());
  EXPECT_EQ("//root/foo/a", OpenedS->getName());


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109128

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


[PATCH] D109701: [clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

2021-09-13 Thread Vaibhav Yenamandra via Phabricator via cfe-commits
vaibhav.y created this revision.
vaibhav.y added a reviewer: lattner.
Herald added subscribers: dexonsmith, wenlei, mgorny.
vaibhav.y edited the summary of this revision.
vaibhav.y added a project: clang.
vaibhav.y added subscribers: aaron.ballman, lebedev.ri.
vaibhav.y added a comment.
vaibhav.y edited the summary of this revision.
vaibhav.y edited the summary of this revision.
vaibhav.y edited the summary of this revision.
vaibhav.y published this revision for review.
Herald added a subscriber: cfe-commits.

I've added Roman Lebedev and Aaron Ballman as subscribers from the original RFC 
thread




Comment at: clang/lib/Basic/Sarif.cpp:27
+
+StringRef getFileName(const FileEntry ) {
+  StringRef Filename = FE.tryGetRealPathName();

A lot of these are copied from [[ 
https://github.com/llvm/llvm-project/blob/181d18ef53db1e5810bf6b905fbafc91da9b5baa/clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp#L64
 | SarifDiagnostics.cpp ]]


Create an interface for writing SARIF documents from within `clang`:

The primary intent of this change is to introduce the interface 
`clang::SarifDocumentWriter`, which allows incrementally adding diagnostic data 
to a JSON backed document. The proposed interface is not yet connected to the 
compiler internals, which will be covered in future work. As such this change 
will not change the input/output interface of `clang`.

This change also introduces the `clang::FullSourceRange` type that is modeled 
after `clang::SourceRange` + `clang::FullSourceLoc`, this is useful for 
packaging a pair of `clang::SourceLocation` objects with their corresponding 
`SourceManager`s.

Previous discussions:

- RFC for this change: 
https://lists.llvm.org/pipermail/cfe-dev/2021-March/067907.html
- https://lists.llvm.org/pipermail/cfe-dev/2021-July/068480.html

SARIF Standard (2.1.0):

- https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109701

Files:
  clang/include/clang/Basic/Sarif.h
  clang/include/clang/Basic/SourceLocation.h
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Sarif.cpp
  clang/lib/Basic/SourceLocation.cpp
  clang/unittests/Basic/CMakeLists.txt
  clang/unittests/Basic/SarifTest.cpp

Index: clang/unittests/Basic/SarifTest.cpp
===
--- /dev/null
+++ clang/unittests/Basic/SarifTest.cpp
@@ -0,0 +1,153 @@
+//===- unittests/Basic/SarifTest.cpp - Test writing SARIF documents ---===//
+//
+// 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
+//
+//===--===//
+
+#include "clang/Basic/Sarif.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include 
+
+#include "gmock/gmock.h"
+#include "gtest/gtest-death-test.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+using namespace llvm;
+
+namespace {
+
+TEST(SarifDocumentWriterTest, createEmptyDocument) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+
+  // WHEN:
+  const json::Object  = writer.createDocument();
+  std::vector keys(emptyDocument.size());
+  std::transform(emptyDocument.begin(), emptyDocument.end(), keys.begin(),
+ [](auto item) { return item.getFirst(); });
+
+  // THEN:
+  ASSERT_THAT(keys, testing::UnorderedElementsAre("$schema", "version"));
+}
+
+// Test that a newly inserted run will associate correct tool names
+TEST(SarifDocumentWriterTest, documentWithARun) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+  const char *shortName = "sariftest";
+  const char *longName = "sarif writer test";
+
+  // WHEN:
+  writer.createRun(shortName, longName);
+  writer.endRun();
+  const json::Object  = writer.createDocument();
+  const json::Array *runs = document.getArray("runs");
+
+  // THEN:
+  // A run was created
+  ASSERT_THAT(runs, testing::NotNull());
+
+  // It is the only run
+  ASSERT_EQ(runs->size(), 1UL);
+
+  // The tool associated with the run was the tool
+  const json::Object *driver =
+  runs->begin()->getAsObject()->getObject("tool")->getObject("driver");
+  ASSERT_THAT(driver, testing::NotNull());
+
+  ASSERT_TRUE(driver->getString("name").hasValue());
+  ASSERT_TRUE(driver->getString("fullName").hasValue());
+  ASSERT_TRUE(driver->getString("language").hasValue());
+
+  EXPECT_EQ(driver->getString("name").getValue(), shortName);
+  EXPECT_EQ(driver->getString("fullName").getValue(), longName);
+  EXPECT_EQ(driver->getString("language").getValue(), "en-US");
+}
+
+// Test adding result without a run causes a crash
+TEST(SarifDocumentWriterTest, addingResultsWillCrashIfThereIsNoRun) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+  SarifResult & = SarifResult::create();
+
+  // WHEN:
+  //  A SarifDocumentWriter::createRun(...) was not called prior to
+  //  

[PATCH] D109694: Driver: Add preferred gcc triples for Red Hat operating systems

2021-09-13 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

Haven't looked closely at this particular commit, but I think hard coding the 
detected triples is almost always a bad idea.

See https://reviews.llvm.org/D63497#2993662 for a longer comment.

The proper way is (1) making sure CMake `LLVM_DEFAULT_TARGET_TRIPLE` is correct 
at configure time (2) the user should specify the complete --target=.

Inferring random target triple from an incomplete `--target=x86_64` really 
should not be supported.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109694

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


[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

2021-09-13 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D104556#2997674 , @catenacyber 
wrote:

> This commit has broken oss-fuzz workflow for rust projects.
> I do not know if the fix is 
> https://reviews.llvm.org/rG66e2772e4285588ccc3bcdb5f392c8326debbd7d
>
> Scenario is
>
>   export RUSTFLAGS="--cfg fuzzing -Cdebuginfo=1 -Cforce-frame-pointers 
> -Zinstrument-coverage -C link-dead-code -C link-arg=-lc++"
>   git clone https://github.com/ctz/rustls && cd rustls
>   cargo fuzz build -O
>   ./fuzz/target/x86_64-unknown-linux-gnu/release/client 
> ./fuzz/target/x86_64-unknown-linux-gnu/release/client
>   llvm-profdata merge -sparse default.profraw -o profdata
>
> Current output is
>
>   warning: default.profraw: malformed instrumentation profile data
>   error: no profile can be merged
>
> Scenario does not output error for in 13.0.0-rc2
>
> Error does not happen on commit 69cdadddecaf97f572c311aa07044f79a5b8329a 
>  just 
> previous this integration, if we add `git cherry-pick 
> a6c14fba70e170a279f7e77f068368f09d8c5eaf` to fix the other pending bug which 
> was fixed in 13.0.0-rc2
> Error happens on commit a1532ed27582038e2d9588108ba0fe8237f01844 
>  even if 
> we `git cherry-pick a6c14fba70e170a279f7e77f068368f09d8c5eaf` and fix the 
> conflict about only llvm/test/tools/llvm-profdata/Inputs/c-general.profraw

I don't think this change is responsible. This has been used by many C++ 
downstream groups.

Rust should use upgrade its lib/ProfileData and compiler-rt/lib/profile.
The binary ID change has caused a bit of churn to ProfileData but it is 
unrelated to this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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


[PATCH] D97699: [analyzer] Add InvalidPtrChecker

2021-09-13 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt:42
   DynamicTypeChecker.cpp
+  cert/InvalidPtrChecker.cpp
   EnumCastOutOfRangeChecker.cpp

Please, insert this in its sorted place.


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

https://reviews.llvm.org/D97699

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


  1   2   >