[PATCH] D108320: Add semantic token modifier for non-const reference parameter

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

I'm happy to commit it. Did you want to make the `SmallVector<1>` --> 
`uint32_t` change, or should I just commit it as is?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108320

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

[PATCH] D109199: [compiler-rt][Fuchsia] Support building + running compiler-rt tests on fuchsia's host toolchain

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109199

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

[PATCH] D109321: [clang][OpenMP] Fix the bug in codegen for ordered directive

[Peixin Qiao via Phabricator via cfe-commits]

peixin added a comment.

In D109321#2987783 , @jdoerfert wrote:

> As noted before, this is not the right fix. Not inlining should not cause a 
> semantic difference here, the problem is something else.

@jdoerfert Yes, I agree that this is not the right fix. What I mean is to 
abandon this PR and post this bug in bugzilla to let someone who knows more 
about optimization passes to solve it considering this may not be one frontend 
bug according to the result of the command `clang++ -fopenmp simd.cpp -O1 
-Xclang -disable-llvm-passes`. I have to admit that always inlining the 
outlined function gives correct results since optmization passes vectorize the 
statements if there is no dependence (eg. a[i] = 1.0) and add memcheck if there 
may be dependence (eg. a[i] = b[i] + 1.0). Although this vectorization violate 
the definition of `ordered` construct in OpenMP 5.0 standard, it's safe to do 
it. Anyway, I think it's not one big problem here.

> Just to prevent the IR from changing when optimizations aren't enabled.

@jhuber6  Thanks for the reply. I think not generating outlined function is the 
right way when there is no optimization. Using the code for `ordered threads` 
like the following should be ok. This should not be one big deal since few 
users use `O0` to run their applications. Do you think if we should make this 
change?

  diff --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
  index 6ede4c3189d4..0ca5c7b71084 100644
  --- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
  +++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
  @@ -5443,11 +5443,12 @@ void CodeGenFunction::EmitOMPOrderedDirective(const 
OMPOrderedDirective &S) {
 CGM.getOpenMPRuntime().emitDoacrossOrdered(*this, DC);
   return;
 }
  +  unsigned OptLevel = CGM.getCodeGenOpts().OptimizationLevel;
 const auto *C = S.getSingleClause();
  -  auto &&CodeGen = [&S, C, this](CodeGenFunction &CGF,
  - PrePostActionTy &Action) {
  +  auto &&CodeGen = [&S, OptLevel, C, this](CodeGenFunction &CGF,
  +   PrePostActionTy &Action) {
   const CapturedStmt *CS = S.getInnermostCapturedStmt();
  -if (C) {
  +if (C && OptLevel > 0) {
 llvm::SmallVector CapturedVars;
 CGF.GenerateOpenMPCapturedVars(*CS, CapturedVars);
 llvm::Function *OutlinedFn =


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109321

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

[PATCH] D108320: Add semantic token modifier for non-const reference parameter

[Tom Praschan via Phabricator via cfe-commits]

tom-anders added a comment.

I’d say commit as is and have a look at the SmallVector -> unit32_t thing 
together with the std::map issue afterwards


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108320

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

[PATCH] D109424: [OpenCL] Supports atomics in C++ for OpenCL 2021

[Justas Janickas via Phabricator via cfe-commits]

Topotuna created this revision.
Topotuna added a reviewer: Anastasia.
Herald added subscribers: ldrumm, yaxunl.
Topotuna requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Atomics in C++ for OpenCL 2021 are now handled the same way as in
OpenCL C 3.0. This is a header-only change.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109424

Files:
  clang/lib/Headers/opencl-c-base.h
  clang/lib/Headers/opencl-c.h

Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -13256,7 +13256,7 @@
 #endif //cl_khr_fp64
 #endif
 #endif //defined(__opencl_c_generic_address_space)
-#if __OPENCL_C_VERSION__ >= CL_VERSION_3_0
+#if (__OPENCL_C_VERSION__ >= CL_VERSION_3_0 || __OPENCL_CPP_VERSION__ >= 202100)
 void __ovld atomic_init(volatile __global atomic_int *object, int value);
 void __ovld atomic_init(volatile __local atomic_int *object, int value);
 void __ovld atomic_init(volatile __global atomic_uint *object, uint value);
@@ -13273,7 +13273,7 @@
 void __ovld atomic_init(volatile __local atomic_double *object, double value);
 #endif //cl_khr_fp64
 #endif
-#endif //__OPENCL_C_VERSION__ >= CL_VERSION_3_0
+#endif // (__OPENCL_C_VERSION__ >= CL_VERSION_3_0 || __OPENCL_CPP_VERSION__ >= 202100)
 
 // atomic_work_item_fence()
 void __ovld atomic_work_item_fence(cl_mem_fence_flags flags, memory_order order, memory_scope scope);
@@ -13317,7 +13317,7 @@
 uintptr_t __ovld atomic_fetch_sub(volatile atomic_uintptr_t *object, ptrdiff_t operand);
 #endif //defined(cl_khr_int64_base_atomics) && defined(cl_khr_int64_extended_atomics)
 #endif //defined(__opencl_c_generic_address_space)
-#if __OPENCL_C_VERSION__ >= CL_VERSION_3_0
+#if (__OPENCL_C_VERSION__ >= CL_VERSION_3_0 || __OPENCL_CPP_VERSION__ >= 202100)
 int __ovld atomic_fetch_add(volatile __global atomic_int *object, int operand);
 int __ovld atomic_fetch_add(volatile __local atomic_int *object, int operand);
 uint __ovld atomic_fetch_add(volatile __global atomic_uint *object, uint operand);
@@ -13398,7 +13398,7 @@
 uintptr_t __ovld atomic_fetch_add(volatile __global atomic_uintptr_t *object, ptrdiff_t operand);
 uintptr_t __ovld atomic_fetch_sub(volatile __local atomic_uintptr_t *object, ptrdiff_t operand);
 #endif //defined(cl_khr_int64_base_atomics) && defined(cl_khr_int64_extended_atomics)
-#endif //__OPENCL_C_VERSION__ >= CL_VERSION_3_0
+#endif // (__OPENCL_C_VERSION__ >= CL_VERSION_3_0 || __OPENCL_CPP_VERSION__ >= 202100)
 #endif
 
 #if defined(__opencl_c_atomic_scope_device)
@@ -13436,7 +13436,7 @@
 uintptr_t __ovld atomic_fetch_sub_explicit(volatile atomic_uintptr_t *object, ptrdiff_t operand, memory_order order);
 #endif //defined(cl_khr_int64_base_atomics) && defined(cl_khr_int64_extended_atomics)
 #endif //defined(__opencl_c_generic_address_space)
-#if __OPENCL_C_VERSION__ >= CL_VERSION_3_0
+#if (__OPENCL_C_VERSION__ >= CL_VERSION_3_0 || __OPENCL_CPP_VERSION__ >= 202100)
 int __ovld atomic_fetch_add_explicit(volatile __global atomic_int *object, int operand, memory_order order);
 int __ovld atomic_fetch_add_explicit(volatile __local atomic_int *object, int operand, memory_order order);
 uint __ovld atomic_fetch_add_explicit(volatile __global atomic_uint *object, uint operand, memory_order order);
@@ -13517,7 +13517,7 @@
 uintptr_t __ovld atomic_fetch_add_explicit(volatile __global atomic_uintptr_t *object, ptrdiff_t operand, memory_order order);
 uintptr_t __ovld atomic_fetch_sub_explicit(volatile __local atomic_uintptr_t *object, ptrdiff_t operand, memory_order order);
 #endif //defined(cl_khr_int64_base_atomics) && defined(cl_khr_int64_extended_atomics)
-#endif //__OPENCL_C_VERSION__ >= CL_VERSION_3_0
+#endif // (__OPENCL_C_VERSION__ >= CL_VERSION_3_0 || __OPENCL_CPP_VERSION__ >= 202100)
 #endif
 
 #if defined(__opencl_c_generic_address_space)
@@ -13554,7 +13554,7 @@
 uintptr_t __ovld atomic_fetch_sub_explicit(volatile atomic_uintptr_t *object, ptrdiff_t operand, memory_order order, memory_scope scope);
 #endif
 #endif //defined(__opencl_c_generic_address_space)
-#if __OPENCL_C_VERSION__ >= CL_VERSION_3_0
+#if (__OPENCL_C_VERSION__ >= CL_VERSION_3_0 || __OPENCL_CPP_VERSION__ >= 202100)
 int __ovld atomic_fetch_add_explicit(volatile __global atomic_int *object, int operand, memory_order order, memory_scope scope);
 int __ovld atomic_fetch_add_explicit(volatile __local atomic_int *object, int operand, memory_order order, memory_scope scope);
 uint __ovld atomic_fetch_add_explicit(volatile __global atomic_uint *object, uint operand, memory_order order, memory_scope scope);
@@ -13635,7 +13635,7 @@
 uintptr_t __ovld atomic_fetch_add_explicit(volatile __global atomic_uintptr_t *object, ptrdiff_t operand, memory_order order, memory_scope scope);
 uintptr_t __ovld atomic_fetch_sub_explicit(volatile __local atomic_uintptr_t *object, ptrdiff_t operand, memory_order order, memory_scope sc

[PATCH] D103136: [AVR] Add support for the tinyAVR 0-series and tinyAVR 1-seriesø

[Justin Latimer via Phabricator via cfe-commits]

justinlatimer added a comment.

Thanks a lot @benshi001!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103136

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

[PATCH] D106809: [clang-offload-bundler] Make Bundle Entry ID backward compatible

[Saiyedul Islam via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG98380762c3b7: [clang-offload-bundler] Make Bundle Entry ID 
backward compatible (authored by saiislam).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106809

Files:
  clang/docs/ClangOffloadBundler.rst
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/clang-offload-bundler.c
  clang/test/Driver/hip-rdc-device-only.hip
  clang/test/Driver/hip-toolchain-rdc-separate.hip
  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
@@ -14,6 +14,7 @@
 ///
 //===--===//
 
+#include "clang/Basic/Cuda.h"
 #include "clang/Basic/Version.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/SmallString.h"
@@ -134,21 +135,28 @@
 ///  * Offload Kind - Host, OpenMP, or HIP
 ///  * Triple - Standard LLVM Triple
 ///  * GPUArch (Optional) - Processor name, like gfx906 or sm_30
-/// In presence of Proc, the Triple should contain separator "-" for all
-/// standard four components, even if they are empty.
+
 struct OffloadTargetInfo {
   StringRef OffloadKind;
   llvm::Triple Triple;
   StringRef GPUArch;
 
   OffloadTargetInfo(const StringRef Target) {
-SmallVector Components;
-Target.split(Components, '-', 5);
-Components.resize(6);
-this->OffloadKind = Components[0];
-this->Triple = llvm::Triple(Components[1], Components[2], Components[3],
-Components[4]);
-this->GPUArch = Components[5];
+auto TargetFeatures = Target.split(':');
+auto TripleOrGPU = TargetFeatures.first.rsplit('-');
+
+if (clang::StringToCudaArch(TripleOrGPU.second) !=
+clang::CudaArch::UNKNOWN) {
+  auto KindTriple = TripleOrGPU.first.split('-');
+  this->OffloadKind = KindTriple.first;
+  this->Triple = llvm::Triple(KindTriple.second);
+  this->GPUArch = Target.substr(Target.find(TripleOrGPU.second));
+} else {
+  auto KindTriple = TargetFeatures.first.split('-');
+  this->OffloadKind = KindTriple.first;
+  this->Triple = llvm::Triple(KindTriple.second);
+  this->GPUArch = "";
+}
   }
 
   bool hasHostKind() const { return this->OffloadKind == "host"; }
@@ -1063,9 +1071,10 @@
 
   // Compatible in case of exact match.
   if (CodeObjectInfo == TargetInfo) {
-DEBUG_WITH_TYPE(
-"CodeObjectCompatibility",
-dbgs() << "Compatible: Exact match: " << CodeObjectInfo.str() << "\n");
+DEBUG_WITH_TYPE("CodeObjectCompatibility",
+dbgs() << "Compatible: Exact match: \t[CodeObject: "
+   << CodeObjectInfo.str()
+   << "]\t:\t[Target: " << TargetInfo.str() << "]\n");
 return true;
   }
 
@@ -1276,9 +1285,19 @@
 } else if (!AllowMissingBundles) {
   std::string ErrMsg =
   Twine("no compatible code object found for the target '" + Target +
-"' in heterogenous archive library: " + IFName)
+"' in heterogeneous archive library: " + IFName)
   .str();
   return createStringError(inconvertibleErrorCode(), ErrMsg);
+} else { // Create an empty archive file if no compatible code object is
+ // found and "allow-missing-bundles" is enabled. It ensures that
+ // the linker using output of this step doesn't complain about
+ // the missing input file.
+  std::vector EmptyArchive;
+  EmptyArchive.clear();
+  if (Error WriteErr = writeArchive(FileName, EmptyArchive, true,
+getDefaultArchiveKindForHost(), true,
+false, nullptr))
+return WriteErr;
 }
   }
 
Index: clang/test/Driver/hip-toolchain-rdc-separate.hip
===
--- clang/test/Driver/hip-toolchain-rdc-separate.hip
+++ clang/test/Driver/hip-toolchain-rdc-separate.hip
@@ -44,7 +44,7 @@
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
 // CHECK: [[BUNDLER:".*clang-offload-bundler"]] "-type=o"
-// CHECK-SAME: "-targets=hip-amdgcn-amd-amdhsa--gfx803,hip-amdgcn-amd-amdhsa--gfx900,host-x86_64-unknown-linux-gnu"
+// CHECK-SAME: "-targets=hip-amdgcn-amd-amdhsa-gfx803,hip-amdgcn-amd-amdhsa-gfx900,host-x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-outputs=[[A_O:.*a.o]]" "-inputs=[[A_BC1]],[[A_BC2]],[[A_OBJ_HOST]]"
 
 // CHECK: [[CLANG]] "-cc1" "-triple" "amdgcn-amd-amdhsa"
@@ -79,7 +79,7 @@
 // CHECK-SAME: {{.*}} [[B_SRC]]
 
 // CHECK: [[BUNDLER:".*clang-offload-bundler"]] "-type=o"
-// CHECK-SAME: "-targets=hip-amdgcn-amd-amdhsa--gfx803,hip-amdgcn-amd-amdhsa--gfx900,host-x86_6

[clang] 9838076 - [clang-offload-bundler] Make Bundle Entry ID backward compatible

[Saiyedul Islam via cfe-commits]

Author: Saiyedul Islam
Date: 2021-09-08T16:06:12+05:30
New Revision: 98380762c3b734c23d206182605ab9e035c93caa

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

LOG: [clang-offload-bundler] Make Bundle Entry ID backward compatible

Earlier BundleEntryID used to be --.
This used to work because the clang-offload-bundler didn't need
GPUArch explicitly for any bundling/unbundling action. With
unbundleArchive it needs GPUArch to ensure compatibility between
device specific code objects. D93525 enforced triples to have
separators for all 4 components irrespective of number of
components, like "amdgcn-amd-amdhsa--". It was required to
to correctly parse a possible 4th environment component or a GPU.
But, this condition is breaking backward compatibility with
archive libraries compiled with compilers older than D93525.

This patch allows triples to have any number of components with
and without extra separator for empty environment field. Thus,
both the following bundle entry IDs are same:
openmp-amdgcn-amd-amdhsa--gfx906
openmp-amdgcn-amd-amdhsa-gfx906

Reviewed By: yaxunl, grokos

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

Added: 


Modified: 
clang/docs/ClangOffloadBundler.rst
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/clang-offload-bundler.c
clang/test/Driver/hip-rdc-device-only.hip
clang/test/Driver/hip-toolchain-rdc-separate.hip
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Removed: 




diff  --git a/clang/docs/ClangOffloadBundler.rst 
b/clang/docs/ClangOffloadBundler.rst
index c92d8a94cfb54..a0e446f766eea 100644
--- a/clang/docs/ClangOffloadBundler.rst
+++ b/clang/docs/ClangOffloadBundler.rst
@@ -121,15 +121,7 @@ Where:
   = 
==
 
 **target-triple**
-The target triple of the code object:
-
-.. code::
-
-  ---
-
-It is required to have all four components present, if target-id is present.
-Components are hyphen separated. If a component is not specified then the
-empty string must be used in its place.
+The target triple of the code object.
 
 **target-id**
   The canonical target ID of the code object. Present only if the target

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 65e377f6a7f7a..5d817aa480bf4 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -7686,16 +7686,12 @@ void OffloadBundler::ConstructJob(Compilation &C, const 
JobAction &JA,
   });
 }
 Triples += Action::GetOffloadKindName(CurKind);
-Triples += "-";
-std::string NormalizedTriple = CurTC->getTriple().normalize();
-Triples += NormalizedTriple;
-
-if (CurDep->getOffloadingArch() != nullptr) {
-  // If OffloadArch is present it can only appear as the 6th hypen
-  // sepearated field of Bundle Entry ID. So, pad required number of
-  // hyphens in Triple.
-  for (int i = 4 - StringRef(NormalizedTriple).count("-"); i > 0; i--)
-Triples += "-";
+Triples += '-';
+Triples += CurTC->getTriple().normalize();
+if ((CurKind == Action::OFK_HIP || CurKind == Action::OFK_OpenMP ||
+ CurKind == Action::OFK_Cuda) &&
+CurDep->getOffloadingArch()) {
+  Triples += '-';
   Triples += CurDep->getOffloadingArch();
 }
   }
@@ -7768,17 +7764,13 @@ void OffloadBundler::ConstructJobMultipleOutputs(
 
 auto &Dep = DepInfo[I];
 Triples += Action::GetOffloadKindName(Dep.DependentOffloadKind);
-Triples += "-";
-std::string NormalizedTriple =
-Dep.DependentToolChain->getTriple().normalize();
-Triples += NormalizedTriple;
-
-if (!Dep.DependentBoundArch.empty()) {
-  // If OffloadArch is present it can only appear as the 6th hypen
-  // sepearated field of Bundle Entry ID. So, pad required number of
-  // hyphens in Triple.
-  for (int i = 4 - StringRef(NormalizedTriple).count("-"); i > 0; i--)
-Triples += "-";
+Triples += '-';
+Triples += Dep.DependentToolChain->getTriple().normalize();
+if ((Dep.DependentOffloadKind == Action::OFK_HIP ||
+ Dep.DependentOffloadKind == Action::OFK_OpenMP ||
+ Dep.DependentOffloadKind == Action::OFK_Cuda) &&
+!Dep.DependentBoundArch.empty()) {
+  Triples += '-';
   Triples += Dep.DependentBoundArch;
 }
   }

diff  --git a/clang/test/Driver/clang-offload-bundler.c 
b/clang/test/Driver/clang-offload-bundler.c
index e1afa19570ec3..d201dd4103892 100644
--- a/clang/test/Driver/clang-offload-bundler.c
+++ b/clang/test/Driver/clang-offload-bundler.c
@@ -382,16 +382,30 @@
 // Check archive unbundling
 //
 // Create few code object bundles and archive them to create an input archive
-// R

[PATCH] D108560: [clang-tidy] Add support for NOLINTBEGIN ... NOLINTEND comments to suppress clang-tidy warnings over multiple lines

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz updated this revision to Diff 371308.
salman-javed-nz added a comment.

clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp:

- Added test to check what happens when NOLINTEND marker is used before 
NOLINTBEGIN marker (class B1 , line 7).
  - Warning is still displayed (NOLINTEND ends suppression but this is 
redundant as there was no suppression in the first place).

- Added test to check what happens when NOLINTBEGIN marker is used but no 
NOLINTEND marker is used afterwards (classes H1 , 
H2 ; lines 87, 88).
  - Warning is suppressed for the remainder of the file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108560

Files:
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/index.rst
  
clang-tools-extra/test/clang-tidy/infrastructure/Inputs/nolintbeginend/error_in_include.inc
  
clang-tools-extra/test/clang-tidy/infrastructure/Inputs/nolintbeginend/nolint_in_include.inc
  clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp

Index: clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp
@@ -0,0 +1,90 @@
+// RUN: %check_clang_tidy %s google-explicit-constructor %t -- --header-filter=.* -system-headers -- -isystem %S/Inputs/nolintbeginend
+
+class A { A(int i); };
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: single-argument constructors must be marked explicit
+
+// NOLINTEND
+class B1 { B1(int i); };
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
+
+// NOLINTBEGIN
+class B2 { B2(int i); };
+// NOLINTEND
+
+// NOLINTBEGIN
+// NOLINTEND
+// NOLINTBEGIN
+class B3 { B3(int i); };
+// NOLINTEND
+
+// NOLINTBEGIN
+// NOLINTEND
+class B4 { B4(int i); };
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
+
+// NOLINTBEGIN(google-explicit-constructor)
+class C1 { C1(int i); };
+// NOLINTEND(google-explicit-constructor)
+
+// NOLINTBEGIN(*)
+class C2 { C2(int i); };
+// NOLINTEND(*)
+
+// NOLINTBEGIN(some-other-check)
+class C3 { C3(int i); };
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
+// NOLINTEND(some-other-check)
+
+// NOLINTBEGIN(some-other-check, google-explicit-constructor)
+class C4 { C4(int i); };
+// NOLINTEND(some-other-check, google-explicit-constructor)
+
+// NOLINTBEGIN(some-other-check, google-explicit-constructor)
+// NOLINTEND(some-other-check)
+class C5 { C5(int i); };
+// NOLINTEND(google-explicit-constructor)
+
+// NOLINTBEGIN(some-other-check, google-explicit-constructor)
+// NOLINTEND(google-explicit-constructor)
+class C6 { C6(int i); };
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
+// NOLINTEND(some-other-check)
+
+// NOLINTBEGIN(google-explicit-constructor)
+// NOLINTBEGIN(some-other-check)
+class C7 { C7(int i); };
+// NOLINTEND(some-other-check)
+// NOLINTEND(google-explicit-constructor)
+
+// NOLINTBEGIN(not-closed-bracket-is-treated-as-skip-all
+class C8 { C8(int i); };
+// NOLINTEND(not-closed-bracket-is-treated-as-skip-all
+
+// NOLINTBEGIN without-brackets-skip-all, another-check
+class C9 { C9(int i); };
+// NOLINTEND without-brackets-skip-all, another-check
+
+#define MACRO(X) class X { X(int i); };
+
+MACRO(D1)
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: single-argument constructors must be marked explicit
+
+// NOLINTBEGIN
+MACRO(D2)
+// NOLINTEND
+
+#define MACRO_NOARG class E { E(int i); };
+// NOLINTBEGIN
+MACRO_NOARG
+// NOLINTEND
+
+#include "error_in_include.inc"
+// CHECK-MESSAGES: warning: single-argument constructors must be marked explicit
+
+#include "nolint_in_include.inc"
+
+// NOLINTBEGIN
+class H1 { H1(int i); };
+class H2 { H2(int i); };
+
+// CHECK-MESSAGES: Suppressed 14 warnings (14 NOLINT)
Index: clang-tools-extra/test/clang-tidy/infrastructure/Inputs/nolintbeginend/nolint_in_include.inc
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/Inputs/nolintbeginend/nolint_in_include.inc
@@ -0,0 +1,3 @@
+// NOLINTBEGIN
+class G { G(int i); };
+// NOLINTEND
Index: clang-tools-extra/test/clang-tidy/infrastructure/Inputs/nolintbeginend/error_in_include.inc
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/Inputs/nolintbeginend/error_in_include.inc
@@ -0,0 +1 @@
+class F { F(int i); };
Index: clang-tools-extra/docs/clang-tidy/index.rst
===
--- clang-tools-extra/do

[PATCH] D109234: [PGO] Change ThinLTO test for targets with loop unrolling disabled

[Sherwin via Phabricator via cfe-commits]

sherwin-dc marked 2 inline comments as done.
sherwin-dc added inline comments.



Comment at: clang/test/CodeGen/pgo-sample-thinlto-summary.c:1
-// RUN: %clang_cc1 -O2 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -o 
- 2>&1 | FileCheck %s -check-prefix=SAMPLEPGO
-// RUN: %clang_cc1 -O2 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm 
-flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO
-// RUN: %clang_cc1 -O2 -fexperimental-new-pass-manager 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -o 
- 2>&1 | FileCheck %s -check-prefix=SAMPLEPGO
-// RUN: %clang_cc1 -O2 -fexperimental-new-pass-manager 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm 
-flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO
-// Checks if hot call is inlined by normal compile, but not inlined by
-// thinlto compile.
+// RUN: %clang_cc1 -mllvm -opt-bisect-limit=-1 -O2 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -o 
- 2>&1 | FileCheck %s -check-prefix=SAMPLEPGO
+// RUN: %clang_cc1 -mllvm -opt-bisect-limit=-1 -O2 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm 
-flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO

tejohnson wrote:
> -opt-bisect-limit seems like a roundabout way to get the pass invocations 
> printed. How about just -mllvm -debug-pass=Structure?
I had tried using `-mllvm -debug-pass=Structure` but could not get anything to 
print out. It only worked when I removed `-cc1 -nostdsysteminc` and 
`-emit-llvm` which is used when lit runs the tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109234

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

[PATCH] D109234: [PGO] Change ThinLTO test for targets with loop unrolling disabled

[Sherwin via Phabricator via cfe-commits]

sherwin-dc updated this revision to Diff 371315.
sherwin-dc added a comment.

- Consolidate test cases into one


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109234

Files:
  clang/test/CodeGen/pgo-sample-thinlto-summary.c


Index: clang/test/CodeGen/pgo-sample-thinlto-summary.c
===
--- clang/test/CodeGen/pgo-sample-thinlto-summary.c
+++ clang/test/CodeGen/pgo-sample-thinlto-summary.c
@@ -1,9 +1,7 @@
-// RUN: %clang_cc1 -O2 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -o 
- 2>&1 | FileCheck %s -check-prefix=SAMPLEPGO
-// RUN: %clang_cc1 -O2 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm 
-flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO
-// RUN: %clang_cc1 -O2 -fexperimental-new-pass-manager 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -o 
- 2>&1 | FileCheck %s -check-prefix=SAMPLEPGO
-// RUN: %clang_cc1 -O2 -fexperimental-new-pass-manager 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm 
-flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO
-// Checks if hot call is inlined by normal compile, but not inlined by
-// thinlto compile.
+// RUN: %clang_cc1 -mllvm -opt-bisect-limit=-1 -O2 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -o 
- 2>&1 | FileCheck %s -check-prefix=SAMPLEPGO
+// RUN: %clang_cc1 -mllvm -opt-bisect-limit=-1 -O2 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm 
-flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO
+// RUN: %clang_cc1 -mllvm -opt-bisect-limit=-1 -O2 
-fexperimental-new-pass-manager 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -o 
- 2>&1 | FileCheck %s -check-prefix=SAMPLEPGO
+// RUN: %clang_cc1 -mllvm -opt-bisect-limit=-1 -O2 
-fexperimental-new-pass-manager 
-fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm 
-flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO
 
 int baz(int);
 int g;
@@ -13,6 +11,16 @@
 g += baz(i);
 }
 
+// Checks that loop unroll and icp are invoked by normal compile, but not 
thinlto compile.
+// SAMPLEPGO-LABEL: running pass ({{[0-9]+}}) {{[a-zA-Z0-9]+}} on
+// THINLTO-LABEL: running pass ({{[0-9]+}}) {{[a-zA-Z0-9]+}} on
+// SAMPLEPGO: running pass ({{[0-9]+}}) PGOIndirectCallPromotion on [module]
+// SAMPLEPGO: running pass ({{[0-9]+}}) LoopUnrollPass on bar
+// THINLTO-NOT: running pass ({{[0-9]+}}) PGOIndirectCallPromotion on [module]
+// THINLTO-NOT: running pass ({{[0-9]+}}) LoopUnrollPass on bar
+
+// Checks if hot call is inlined by normal compile, but not inlined by
+// thinlto compile.
 // SAMPLEPGO-LABEL: define {{(dso_local )?}}void @bar
 // THINLTO-LABEL: define {{(dso_local )?}}void @bar
 // SAMPLEPGO-NOT: call{{.*}}foo
@@ -20,27 +28,4 @@
 void bar(int n) {
   for (int i = 0; i < n; i++)
 foo(i);
-}
-
-// Checks if loop unroll is invoked by normal compile, but not thinlto compile.
-// SAMPLEPGO-LABEL: define {{(dso_local )?}}void @unroll
-// THINLTO-LABEL: define {{(dso_local )?}}void @unroll
-// SAMPLEPGO: call{{.*}}baz
-// SAMPLEPGO: call{{.*}}baz
-// THINLTO: call{{.*}}baz
-// THINLTO-NOT: call{{.*}}baz
-void unroll() {
-  for (int i = 0; i < 2; i++)
-baz(i);
-}
-
-// Checks that icp is not invoked for ThinLTO, but invoked for normal 
samplepgo.
-// SAMPLEPGO-LABEL: define {{(dso_local )?}}void @icp
-// THINLTO-LABEL: define {{(dso_local )?}}void @icp
-// SAMPLEPGO: if.true.direct_targ
-// FIXME: the following condition needs to be reversed once
-//LTOPreLinkDefaultPipeline is customized.
-// THINLTO-NOT: if.true.direct_targ
-void icp(void (*p)()) {
-  p();
-}
+}
\ No newline at end of file


Index: clang/test/CodeGen/pgo-sample-thinlto-summary.c
===
--- clang/test/CodeGen/pgo-sample-thinlto-summary.c
+++ clang/test/CodeGen/pgo-sample-thinlto-summary.c
@@ -1,9 +1,7 @@
-// RUN: %clang_cc1 -O2 -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -o - 2>&1 | FileCheck %s -check-prefix=SAMPLEPGO
-// RUN: %clang_cc1 -O2 -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO
-// RUN: %clang_cc1 -O2 -fexperimental-new-pass-manager -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -o - 2>&1 | FileCheck %s -check-prefix=SAMPLEPGO
-// RUN: %clang_cc1 -O2 -fexperimental-new-pass-manager -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO
-// Checks if hot call is inlined by normal compile, but not inlined by
-// thinlto compile.
+// RUN: %clang_cc1 -mllvm -opt-bisect-limit=-1 -O2 -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof 

[PATCH] D108560: [clang-tidy] Add support for NOLINTBEGIN ... NOLINTEND comments to suppress clang-tidy warnings over multiple lines

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Is this syntax used by any other tools?




Comment at: 
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp:6
+
+// NOLINTEND
+class B1 { B1(int i); };

Do you think this should be diagnosed as a sign of user confusion with the 
markings?



Comment at: 
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp:86
+
+// NOLINTBEGIN
+class H1 { H1(int i); };

Should this be diagnosed as user confusion?

My concern in both of these cases isn't so much that someone writes this 
intentionally, but that one of the begin/end pair gets removed accidentally 
when refactoring. Helping the user to identify *where* the unmatched delimiters 
are seems like it could be user-friendly behavior.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108560

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

[PATCH] D109372: [RISCV][RFC] Add Clang support for RISC-V overlay system

[Edward Jones via Phabricator via cfe-commits]

edward-jones added a comment.

In D109372#2987411 , @jrtc27 wrote:

> In D109372#2987405 , @MaskRay wrote:
>
>> The name "overlay" is ambiguous. Even after I ruled out Gentoo Overlay and 
>> overlayfs, I am thinking whether this has anything to do with `OVERLAY` 
>> description in a linker script: 
>> https://sourceware.org/binutils/docs/ld/Overlay-Description.html#Overlay-Description
>>
>>> which are used to mark functions or global data as only accessible through 
>>> the overlay engine
>>
>> Can you give more descriptions for folks who don't follow the RISC-V side 
>> proposal but need to review your changes? :)
>
> Basically hardware-assisted code+rodata banking (I guess either by actually 
> banking ROMs or just paging stuff in and out) that's mostly transparent to 
> software. Functions at the boundary of components (don't know what the 
> granularity is) use a weird indirect calling convention where you instead 
> call into some magic runtime with a unique ID for the callee, it ensures 
> everything's loaded and then tail calls it for you.

Yes it's essentially this. The start of the proposal for this 'overlay' system 
for RISC-V is a FOSDEM talk 'Cacheable Overlay Manager RISC‐V' 
.
 That's also the source of the weird name for the `-fcomrv` option name.

Would something like `-foverlay-manager` make more sense? (maybe an `-m` option 
would actually be more appropriate given this is still very RISC-V specific?). 
I'm not sure how to disambiguate from the many overloaded meanings of 'overlay'.

Thank's for the feedback. I'll update this and come back with a tidier patch.




Comment at: clang/include/clang/Basic/Attr.td:1793-1795
+// This is not marked as a TargetSpecificAttr because that would trigger
+// an 'attribute ignored' warning, but we want to check it explicitly and
+// trigger an error.

aaron.ballman wrote:
> This is not typical attribute behavior -- if the target architecture doesn't 
> support the attribute, are the semantics such that an error is 
> appropriate/required? Put another way, why do we want to trigger an error for 
> this attribute while not triggering errors for other target-specific 
> attributes (like calling conventions)?
If the attribute is being used then the expectation is that it is being 
supported by an overlay engine, and if that isn't the case then it implies an 
error in the build setup. That said I need to check this because I'm not 
convinced it's necessary.



Comment at: clang/include/clang/Basic/Attr.td:1796
+// trigger an error.
+def RISCVOverlayCall : InheritableAttr {
+  let Spellings = [GCC<"overlaycall">];

jrtc27 wrote:
> If you want this to be portable to non-GNU compilers you should consider 
> using a keyword instead (which can still map to an attribute internally). 
> That also tends to get you better errors (there are places where type 
> attributes can get silently ignored currently).
I don't think much consideration has been given to other compilers, but would 
it be unreasonable for the interface to this feature to not necessarily be 
identical between GNU and non-GNU compilers?

That said, I'm happy to switch to a keyword, especially if as you mention there 
are cases where an attribute can silently go missing without error. I'm not 
sure on the distinction of when to use a keyword vs attribute though, given 
that keywords are used pretty sparingly in comparison.



Comment at: clang/include/clang/Basic/AttrDocs.td:2149
+  let Content = [{
+``__attribute__((overlaycall))`` indicates that a function resides in an
+overlay and therefore any calls to or from that function must be handled

jrtc27 wrote:
> Why not just a single attribute that DTRT based on the type?
Good point. I'll see if I can do that. The fact we used multiple attributes is 
mainly a consequence of how we put this together rather than any inherent 
technical need I think.



Comment at: clang/test/Sema/riscv-overlaycall-namespace.cpp:7
+public:
+  static int X() __attribute__((overlaycall)) { return 0; } // expected-error 
{{RISC-V 'overlaycall' attribute not supported on static functions}}
+};

jrtc27 wrote:
> This error message is misleading. The semantics also don't seem great to me.
From recollection the current overlay system only works with externally visible 
symbols and these semantics are a consequence of that.

That said, it's not documented in the code, and as you point out the error 
message is just wrong so I'll fix this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109372

___

[PATCH] D109411: [clang] Enable the special enable_if_t diagnostics for libc++'s _EnableIf as well.

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.

This shouldn't be necessary anymore since we won't be using `_EnableIf` in 
libc++ going forward.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109411

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

[PATCH] D109411: [clang] Enable the special enable_if_t diagnostics for libc++'s _EnableIf as well.

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.

Actually, scratch that, we could tweak this patch so it accepts `__enable_if_t` 
as well (that will be the new spelling for `enable_if_t` for pre-C++14 places 
going forward.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109411

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

[PATCH] D109060: [AIX][ZOS] Disable LIT tests on AIX and z/OS due to lack of Objective-C support

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan added inline comments.



Comment at: clang/test/Modules/ExtDebugInfo.cpp:208
 
-
-// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: 
!{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 27)
+// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: 
!{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 28)
 

jsji wrote:
> Why this change? If this is needed, this should be in another patch. Thanks.
The test failed in Debian and Windows because the unsupported line I added 
changed the expected line number: 27->28. 
https://reviews.llvm.org/D109060?id=371137

Without this change, this patch would cause a regression. But, I can put it in 
another patch if that's preferred.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109060

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

[PATCH] D109372: [RISCV][RFC] Add Clang support for RISC-V overlay system

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:1793-1795
+// This is not marked as a TargetSpecificAttr because that would trigger
+// an 'attribute ignored' warning, but we want to check it explicitly and
+// trigger an error.

edward-jones wrote:
> aaron.ballman wrote:
> > This is not typical attribute behavior -- if the target architecture 
> > doesn't support the attribute, are the semantics such that an error is 
> > appropriate/required? Put another way, why do we want to trigger an error 
> > for this attribute while not triggering errors for other target-specific 
> > attributes (like calling conventions)?
> If the attribute is being used then the expectation is that it is being 
> supported by an overlay engine, and if that isn't the case then it implies an 
> error in the build setup. That said I need to check this because I'm not 
> convinced it's necessary.
Thanks for looking into it! My preference is for the unknown attribute to be 
ignored (with diagnostic) on other targets unless there's a strong argument for 
why it's an error.



Comment at: clang/include/clang/Basic/Attr.td:1796
+// trigger an error.
+def RISCVOverlayCall : InheritableAttr {
+  let Spellings = [GCC<"overlaycall">];

edward-jones wrote:
> jrtc27 wrote:
> > If you want this to be portable to non-GNU compilers you should consider 
> > using a keyword instead (which can still map to an attribute internally). 
> > That also tends to get you better errors (there are places where type 
> > attributes can get silently ignored currently).
> I don't think much consideration has been given to other compilers, but would 
> it be unreasonable for the interface to this feature to not necessarily be 
> identical between GNU and non-GNU compilers?
> 
> That said, I'm happy to switch to a keyword, especially if as you mention 
> there are cases where an attribute can silently go missing without error. I'm 
> not sure on the distinction of when to use a keyword vs attribute though, 
> given that keywords are used pretty sparingly in comparison.
This isn't a type attribute, so I don't think there's a risk of the attribute 
getting lost.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109372

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

[PATCH] D109060: [AIX][ZOS] Disable LIT tests on AIX and z/OS due to lack of Objective-C support

[Jinsong Ji via Phabricator via cfe-commits]

jsji added inline comments.



Comment at: clang/test/Modules/ExtDebugInfo.cpp:208
 
-
-// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: 
!{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 27)
+// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: 
!{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 28)
 

Jake-Egan wrote:
> jsji wrote:
> > Why this change? If this is needed, this should be in another patch. Thanks.
> The test failed in Debian and Windows because the unsupported line I added 
> changed the expected line number: 27->28. 
> https://reviews.llvm.org/D109060?id=371137
> 
> Without this change, this patch would cause a regression. But, I can put it 
> in another patch if that's preferred.
In that case, I would recommend we update it to regex match instead of 
hardcoding line no, and yes, in another patch before this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109060

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

[PATCH] D109372: [RISCV][RFC] Add Clang support for RISC-V overlay system

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:1796
+// trigger an error.
+def RISCVOverlayCall : InheritableAttr {
+  let Spellings = [GCC<"overlaycall">];

aaron.ballman wrote:
> edward-jones wrote:
> > jrtc27 wrote:
> > > If you want this to be portable to non-GNU compilers you should consider 
> > > using a keyword instead (which can still map to an attribute internally). 
> > > That also tends to get you better errors (there are places where type 
> > > attributes can get silently ignored currently).
> > I don't think much consideration has been given to other compilers, but 
> > would it be unreasonable for the interface to this feature to not 
> > necessarily be identical between GNU and non-GNU compilers?
> > 
> > That said, I'm happy to switch to a keyword, especially if as you mention 
> > there are cases where an attribute can silently go missing without error. 
> > I'm not sure on the distinction of when to use a keyword vs attribute 
> > though, given that keywords are used pretty sparingly in comparison.
> This isn't a type attribute, so I don't think there's a risk of the attribute 
> getting lost.
This one isn't, but the data one is


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109372

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

[PATCH] D109372: [RISCV][RFC] Add Clang support for RISC-V overlay system

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:1796
+// trigger an error.
+def RISCVOverlayCall : InheritableAttr {
+  let Spellings = [GCC<"overlaycall">];

jrtc27 wrote:
> aaron.ballman wrote:
> > edward-jones wrote:
> > > jrtc27 wrote:
> > > > If you want this to be portable to non-GNU compilers you should 
> > > > consider using a keyword instead (which can still map to an attribute 
> > > > internally). That also tends to get you better errors (there are places 
> > > > where type attributes can get silently ignored currently).
> > > I don't think much consideration has been given to other compilers, but 
> > > would it be unreasonable for the interface to this feature to not 
> > > necessarily be identical between GNU and non-GNU compilers?
> > > 
> > > That said, I'm happy to switch to a keyword, especially if as you mention 
> > > there are cases where an attribute can silently go missing without error. 
> > > I'm not sure on the distinction of when to use a keyword vs attribute 
> > > though, given that keywords are used pretty sparingly in comparison.
> > This isn't a type attribute, so I don't think there's a risk of the 
> > attribute getting lost.
> This one isn't, but the data one is
Oh, derp, thank you for catching that, somehow I completely missed it! I was 
thrown off by there being a lot of problems with it, but all the problems made 
it look like a declaration attribute.

Type attributes come with their own fun set of questions, like: does the 
attribute impact the type for overloading? SFINAE? Name mangling?



Comment at: clang/include/clang/Basic/Attr.td:1805
+  let Spellings = [GCC<"overlaydata">];
+  let Subjects = SubjectList<[GlobalConst]>;
+  let Documentation = [RISCVOverlayDocs];

This subject list is incorrect -- the subject is a `VarDecl`, but that's not a 
type.



Comment at: clang/include/clang/Basic/AttrDocs.td:2153
+
+``__attribute__((overlaydata))`` is used to mark global constants and signifies
+that the global is in an overlay and can only be accessed using the overlay

This description is wrong if this is intended to be a type attribute. A global 
constant is not a type.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:8512-8517
+if (!S.getLangOpts().RISCVOverlayFunctions) {
+  AL.setInvalid();
+  S.Diag(AL.getLoc(), diag::err_overlaydata_unsupported);
+  break;
+}
+D->addAttr(::new (S.Context) RISCVOverlayDataAttr(S.Context, AL));

aaron.ballman wrote:
> Please write a `handle` function for this as with all the other attributes 
> (we have hopes to someday do more tablegen in this area, so sticking with the 
> same pattern in this `switch` is strongly preferred).
Oops, this is entirely wrong -- if this is a type attribute, it should be 
handled from `processTypeAttrs()` in `SemaType.cpp`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109372

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

[PATCH] D109157: [ARM] Mitigate the cve-2021-35465 security vulnurability.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added inline comments.



Comment at: llvm/test/CodeGen/ARM/cmse-cve-2021-35465-return.ll:6
+; RUN:   FileCheck %s --check-prefix=CHECK-8M-FP-CVE-2021-35465
+
+%indirect = type { double, double, double, double, double, double, double, 
double }

As you're creating machine instructions, I think it is better to run this and 
the other test with `-verify-machineinstrs.`


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

https://reviews.llvm.org/D109157

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

[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

@tianshilei1992 can we agree that the tests must point to a specific deviceRTL, 
and not dig one out of LIBRARY_PATH? That can be factored out of this patch to 
make the tests always use exactly the library that was just built, and also 
makes them easier to run outside of the test harness.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

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

[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

Discussed at weekly call. Going to go with the priority order:
1/ commandline argument
2/ look next to clang
3/ LIBRARY_PATH
4/ error

That means people who have installed clang+openmp together have something that 
works out of the box, and they can override the deviceRTL if they wish. It also 
means people who have installed matching clang/openmp in different locations 
and wired them together with LIBRARY_PATH will continue to work. I'll amend the 
above to do that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

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

[PATCH] D109437: [PowerPC] FP compare and test XL compat builtins.

[Quinn Pham via Phabricator via cfe-commits]

quinnp created this revision.
Herald added subscribers: shchenz, kbarton, hiraditya, nemanjai.
quinnp requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This patch is in a series of patches to provide builtins for
compatability with the XL compiler. This patch adds builtins for compare
exponent and test data class operations on floating point values.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109437

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-test.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-test.ll

Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-test.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-test.ll
@@ -0,0 +1,99 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-unknown \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-unknown \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+
+define i32 @test_builtin_ppc_compare_exp_eq(double %d) {
+; CHECK-LABEL: test_builtin_ppc_compare_exp_eq:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xscmpexpdp 0, 1, 1
+; CHECK-NEXT:li 3, 0
+; CHECK-NEXT:li 4, 1
+; CHECK-NEXT:iseleq 3, 4, 3
+; CHECK-NEXT:blr
+entry:
+  %0 = tail call i32 @llvm.ppc.compare.exp.eq(double %d, double %d)
+  ret i32 %0
+}
+
+declare i32 @llvm.ppc.compare.exp.eq(double, double)
+
+define i32 @test_builtin_ppc_compare_exp_lt(double %d) {
+; CHECK-LABEL: test_builtin_ppc_compare_exp_lt:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xscmpexpdp 0, 1, 1
+; CHECK-NEXT:li 3, 0
+; CHECK-NEXT:li 4, 1
+; CHECK-NEXT:isellt 3, 4, 3
+; CHECK-NEXT:blr
+entry:
+  %0 = tail call i32 @llvm.ppc.compare.exp.lt(double %d, double %d)
+  ret i32 %0
+}
+
+declare i32 @llvm.ppc.compare.exp.lt(double, double)
+
+define i32 @test_builtin_ppc_compare_exp_gt(double %d) {
+; CHECK-LABEL: test_builtin_ppc_compare_exp_gt:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xscmpexpdp 0, 1, 1
+; CHECK-NEXT:li 3, 0
+; CHECK-NEXT:li 4, 1
+; CHECK-NEXT:iselgt 3, 4, 3
+; CHECK-NEXT:blr
+entry:
+  %0 = tail call i32 @llvm.ppc.compare.exp.gt(double %d, double %d)
+  ret i32 %0
+}
+
+declare i32 @llvm.ppc.compare.exp.gt(double, double)
+
+define i32 @test_builtin_ppc_compare_exp_uo(double %d) {
+; CHECK-LABEL: test_builtin_ppc_compare_exp_uo:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xscmpexpdp 0, 1, 1
+; CHECK-NEXT:li 3, 0
+; CHECK-NEXT:li 4, 1
+; CHECK-NEXT:isel 3, 4, 3, 3
+; CHECK-NEXT:blr
+entry:
+  %0 = tail call i32 @llvm.ppc.compare.exp.uo(double %d, double %d)
+  ret i32 %0
+}
+
+declare i32 @llvm.ppc.compare.exp.uo(double, double)
+
+define i32 @test_builtin_ppc_test_data_class_d(double %d) {
+; CHECK-LABEL: test_builtin_ppc_test_data_class_d:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xststdcdp 0, 1, 0
+; CHECK-NEXT:li 3, 0
+; CHECK-NEXT:li 4, 1
+; CHECK-NEXT:iseleq 3, 4, 3
+; CHECK-NEXT:blr
+entry:
+  %test_data_class = tail call i32 @llvm.ppc.test.data.class.d(double %d, i32 0)
+  ret i32 %test_data_class
+}
+
+declare i32 @llvm.ppc.test.data.class.d(double, i32 immarg)
+
+define i32 @test_builtin_ppc_test_data_class_f(float %f) {
+; CHECK-LABEL: test_builtin_ppc_test_data_class_f:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xststdcsp 0, 1, 127
+; CHECK-NEXT:li 3, 0
+; CHECK-NEXT:li 4, 1
+; CHECK-NEXT:iseleq 3, 4, 3
+; CHECK-NEXT:blr
+entry:
+  %test_data_class = tail call i32 @llvm.ppc.test.data.class.f(float %f, i32 127)
+  ret i32 %test_data_class
+}
+
+declare i32 @llvm.ppc.test.data.class.f(float, i32 immarg)
Index: llvm/lib/Target/PowerPC/PPCISelLowering.cpp
===
--- llvm/lib/Target/PowerPC/PPCISelLowering.cpp
+++ llvm/lib/Target/PowerPC/PPCISelLowering.cpp
@@ -10382,6 +10382,50 @@
 }
 return DAG.getMergeValues(RetOps, dl);
   }
+  case Intrinsic::ppc_compare_exp_lt:
+  case Intrinsic::ppc_compare_exp_gt:
+  case Intrinsic::ppc_compare_exp_eq:
+  case Intrinsic::ppc_compare_exp_uo:
+  case Intrinsic::ppc_test_data_class_d:
+  case Intrinsic::ppc_test_data_class_f: {
+unsigned CmprOpc = PPC::XSCMPEXPDP;
+SDValue Op1

[PATCH] D109344: [AMDGPU][OpenMP] Use complex definitions from complex_cmath.h

[Jon Chesterfield via Phabricator via cfe-commits]

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

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109344

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

[PATCH] D109386: Fix use-after-free from GlobalCtors associated data

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

Yes, this looks like the kind of stuff VH is designed for. @wlei here's an 
example of how VH is used to handle deletion of BFI of basic blocks: 
https://reviews.llvm.org/D75341.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109386

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

[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

[Shilei Tian via Phabricator via cfe-commits]

tianshilei1992 added a comment.

In D109061#2989363 , @JonChesterfield 
wrote:

> @tianshilei1992 can we agree that the tests must point to a specific 
> deviceRTL, and not dig one out of LIBRARY_PATH? That can be factored out of 
> this patch to make the tests always use exactly the library that was just 
> built, and also makes them easier to run outside of the test harness.

For test, IMO we could do whatever we want. That’s why I accepted the patch 
regarding rpath.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

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

[clang] 608338c - [OpenMP][NFC] Added comment on OpenMP 5.0 task affinity pilot implementation

[via cfe-commits]

Author: AndreyChurbanov
Date: 2021-09-08T18:12:31+03:00
New Revision: 608338cca579900a85f60a501adf6fa378c5

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

LOG: [OpenMP][NFC] Added comment on OpenMP 5.0 task affinity pilot 
implementation

Added: 


Modified: 
clang/docs/OpenMPSupport.rst

Removed: 




diff  --git a/clang/docs/OpenMPSupport.rst b/clang/docs/OpenMPSupport.rst
index 65742a5a0416a..23de4b5f0c2d4 100644
--- a/clang/docs/OpenMPSupport.rst
+++ b/clang/docs/OpenMPSupport.rst
@@ -145,7 +145,7 @@ implementation.
 
+--+--+--+---+
 | task extension   | taskloop reduction
   | :good:`done` | 
  |
 
+--+--+--+---+
-| task extension   | task affinity 
   | :part:`not upstream` | 
  |
+| task extension   | task affinity 
   | :part:`not upstream` | 
https://github.com/jklinkenberg/openmp/tree/task-affinity |
 
+--+--+--+---+
 | task extension   | clause: depend on the taskwait construct  
   | :part:`worked on`| 
  |
 
+--+--+--+---+



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

[PATCH] D108567: Implement #pragma clang final extension

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:3968-3984
+Final Macros
+
+
+Clang supports the pragma ``#pragma clang final``, which can be used to
+mark macros as final, meaning they cannot be undef'd or re-defined. For 
example:
+
+.. code-block:: c

Design question: would it make sense to extend this slightly so that the macro 
does not have to be defined in order to be finalized? e.g., this could be used 
as a way for a library author to say "this identifier cannot be defined as a 
macro"?



Comment at: clang/docs/LanguageExtensions.rst:3979
+   #undef FINAL_MACRO  // warning: FINAL_MACRO is marked final and should not 
be undefined
+   #define FINAL_MACRO // warning: FINAL_MACRO is marked final and should not 
be redefined
+

What happens if the redefinition is to the same token sequence as the original 
definition? e.g.,
```
#define FINAL_MACRO 1+1
#pragma clang final(FINAL_MACRO)
#define FINAL_MACRO 1+1 // ok?
#define FINAL_MACRO (1+1) // Whoa...slow your roll there, champ!
```



Comment at: clang/include/clang/Basic/DiagnosticLexKinds.td:544
+  ExtWarn<"macro %0 has been marked as final and should not be "
+  "%select{un|re}1defined">,
+  InGroup;

Heh, I like your approach, but a goal of %select is to ease translation of our 
diagnostics to other languages (in theory, anyway).



Comment at: clang/include/clang/Basic/IdentifierTable.h:196
+  // If this is a final macro, make the deprecation and header unsafe bits
+  // stick around after the undefinition so they apply to any redefinitions
+  if (!IsFinal) {





Comment at: clang/include/clang/Lex/Preprocessor.h:828
 
-  /// Usage warning for macros marked by #pragma clang restrict_expansion.
-  llvm::DenseMap
-  RestrictExpansionMacroMsgs;
+  /// Warning information for macro annotations
+  llvm::DenseMap AnnotationInfos;





Comment at: clang/lib/Lex/Pragma.cpp:2083
+if (!II->hasMacroDefinition()) {
+  PP.Diag(Tok, diag::err_pp_visibility_non_macro) << II->getName();
+  return;

This should cause the macro name to be properly quoted in the diagnostic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108567

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

[PATCH] D109411: [clang] Enable the special enable_if_t diagnostics for libc++'s __enable_if_t as well.

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone updated this revision to Diff 371350.
Quuxplusone retitled this revision from "[clang] Enable the special enable_if_t 
diagnostics for libc++'s _EnableIf as well." to "[clang] Enable the special 
enable_if_t diagnostics for libc++'s __enable_if_t as well.".
Quuxplusone edited the summary of this revision.
Quuxplusone added a comment.

Okay, I think I've got it all sorted out in my head. This path forward seems 
reasonable to me:

> D109435  switches us from SCARY `_EnableIf` 
> to a normal `__enable_if_t` (at least in C++11 mode, and possibly everywhere 
> for consistency). Simultaneously, this Clang patch enables the good 
> diagnostics for `__enable_if_t`. We don't need to enable good diagnostics for 
> `_EnableIf` because the name `_EnableIf` has only ever been used for the 
> SCARY version where the good diagnostics don't trigger anyway.

Added a test case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109411

Files:
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaTemplate/diagnose-enable-if-t.cpp

Index: clang/test/SemaTemplate/diagnose-enable-if-t.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/diagnose-enable-if-t.cpp
@@ -0,0 +1,96 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++14 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++17 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 %s
+
+namespace std {
+  inline namespace __1 {
+template struct enable_if {};
+template struct enable_if { using type = T; };
+template using enable_if_t = typename enable_if::type;
+  }
+}
+
+namespace similar_to_user_code {
+  // expected-note@+2 {{candidate template ignored: requirement 'sizeof(char) != 1' was not satisfied [with T = char]}}
+  template>
+  void f(T, short);
+
+  // expected-note@+2 {{candidate template ignored: requirement 'sizeof(char) != 1' was not satisfied [with T = char]}}
+  template* = nullptr>
+  void f(T, int);
+
+  // expected-note@+2 {{candidate template ignored: requirement 'sizeof(char) != 1' was not satisfied [with T = char]}}
+  template
+  std::enable_if_t f(T, long);
+
+  void test() {
+f('x', 0); // expected-error{{no matching function}}
+  }
+}
+
+namespace similar_to_libcxx_version_14 {
+  template struct enable_if {};
+  template struct enable_if { using type = T; };
+  template using __enable_if_t = typename enable_if::type;
+
+  // expected-note@+2 {{candidate template ignored: requirement 'sizeof(char) != 1' was not satisfied [with T = char]}}
+  template>
+  void f(T, short);
+
+  // expected-note@+2 {{candidate template ignored: requirement 'sizeof(char) != 1' was not satisfied [with T = char]}}
+  template* = nullptr>
+  void f(T, int);
+
+  // expected-note@+2 {{candidate template ignored: requirement 'sizeof(char) != 1' was not satisfied [with T = char]}}
+  template
+  __enable_if_t f(T, long);
+
+  void test() {
+f('x', 0); // expected-error{{no matching function}}
+  }
+}
+
+namespace similar_to_libcxx_version_13 {
+  template struct _MetaBase {};
+  template<> struct _MetaBase { template using _EnableIfImpl = R; };
+  template using _EnableIf = typename _MetaBase::template _EnableIfImpl;
+
+  // expected-note@+2 {{no member named '_EnableIfImpl'}}
+  template>
+  void f(T, short);
+
+  // expected-note@+2 {{no member named '_EnableIfImpl'}}
+  template* = nullptr>
+  void f(T, int);
+
+  // expected-note@+2 {{no member named '_EnableIfImpl'}}
+  template
+  _EnableIf f(T, long);
+
+  void test() {
+f('x', 0); // expected-error{{no matching function}}
+  }
+}
+
+namespace not_all_names_are_magic {
+  template struct enable_if {};
+  template struct enable_if { using type = T; };
+  template using a_pony = typename enable_if::type;
+
+  // expected-note@-2 {{candidate template ignored: disabled by 'enable_if' [with T = char]}}
+  template>
+  void f(T, short);
+
+  // expected-note@-6 {{candidate template ignored: disabled by 'enable_if' [with T = char]}}
+  template* = nullptr>
+  void f(T, int);
+
+  // expected-note@-10 {{candidate template ignored: disabled by 'enable_if' [with T = char]}}
+  template
+  a_pony f(T, long);
+
+  void test() {
+f('x', 0); // expected-error{{no matching function}}
+  }
+}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -3511,8 +3511,10 @@
 }
 
 /// Determine whether this alias template is "enable_if_t".
+/// libc++ >=14 uses "__enable_if_t" in C++11 mode.
 static bool isEnableIfAliasTemplate(TypeAliasTemplateDecl *AliasTemplate) {
-  return AliasTemplate->getName().equals("enable_if_t");
+  return AliasTemplate->getName().equals("enable_if_t") ||
+ AliasTemplate->getName().equals("__enable_if_t");
 }

[PATCH] D108493: [HIP] Allow capture this pointer in device lambda

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl marked an inline comment as done.
yaxunl added inline comments.



Comment at: clang/lib/Sema/SemaCUDA.cpp:881-882
+  } else if (Capture.isThisCapture() && !LangOpts.HIP) {
+// Capture of this pointer is allowed for HIP since this pointer may be
+// pointing to managed memory which is accessible on both device and
+// host sides.

tra wrote:
> I assume there's no easy way to tell if it's a managed pointer or not.
> Capturing a non-managed pointer would still be bad.
> Should we make it a warning instead?
> 
> 
warning makes sense. will do.

Also this should apply to CUDA too. Although clang does not support 
`__managed__` keyword for CUDA, `this` pointer may be allocated in managed 
memory through host API's.


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

https://reviews.llvm.org/D108493

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

[PATCH] D108493: [HIP] Warn capture this pointer in device lambda

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 371363.
yaxunl marked an inline comment as done.
yaxunl retitled this revision from "[HIP] Allow capture this pointer in device 
lambda" to "[HIP] Warn capture this pointer in device lambda".
yaxunl edited the summary of this revision.

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

https://reviews.llvm.org/D108493

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaCUDA.cpp
  clang/test/SemaCUDA/lambda.cu


Index: clang/test/SemaCUDA/lambda.cu
===
--- clang/test/SemaCUDA/lambda.cu
+++ clang/test/SemaCUDA/lambda.cu
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify=com %s
-// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device -verify=com,dev %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device 
-verify=com,dev,warn %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device 
-verify=com,dev,warn \
+// RUN:   -triple amdgcn-amd-amdhsa -target-cpu gfx906 -x hip %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device -verify=com,dev \
+// RUN:   -Wno-gpu-maybe-wrong-side %s
 
 #include "Inputs/cuda.h"
 
@@ -7,7 +11,8 @@
 
 template
 __global__ void kernel(F f) { f(); }
-// dev-note@-1 7{{called by 'kernel<(lambda}}
+// dev-note@-1 3{{called by 'kernel<(lambda}}
+// warn-note@-2 5{{called by 'kernel<(lambda}}
 
 __host__ __device__ void hd(int x);
 
@@ -22,19 +27,23 @@
 kernel<<<1,1>>>([](){ hd(0); });
 
 kernel<<<1,1>>>([=](){ hd(b); });
-// dev-error@-1 {{capture host side class data member by this pointer in 
device or host device lambda function}}
+// warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
 
 kernel<<<1,1>>>([&](){ hd(b); });
-// dev-error@-1 {{capture host side class data member by this pointer in 
device or host device lambda function}}
+// warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
 
 kernel<<<1,1>>>([&] __device__ (){ hd(b); });
-// dev-error@-1 {{capture host side class data member by this pointer in 
device or host device lambda function}}
+// warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
 
 kernel<<<1,1>>>([&](){
   auto f = [&]{ hd(b); };
-  // dev-error@-1 {{capture host side class data member by this pointer in 
device or host device lambda function}}
+  // warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
   f();
 });
+
+auto lambda1 = [this] __device__ { hd(this->b); };
+// warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
+kernel<<<1,1>>>(lambda1);
   }
 };
 
Index: clang/lib/Sema/SemaCUDA.cpp
===
--- clang/lib/Sema/SemaCUDA.cpp
+++ clang/lib/Sema/SemaCUDA.cpp
@@ -878,8 +878,13 @@
   diag::err_capture_bad_target, Callee, *this)
 << Capture.getVariable();
   } else if (Capture.isThisCapture()) {
+// Capture of this pointer is allowed since this pointer may be pointing to
+// managed memory which is accessible on both device and host sides. It 
only
+// results in invalid memory access if this pointer points to memory not
+// accessible on device side.
 SemaDiagnosticBuilder(DiagKind, Capture.getLocation(),
-  diag::err_capture_bad_target_this_ptr, Callee, 
*this);
+  diag::warn_maybe_capture_bad_target_this_ptr, Callee,
+  *this);
   }
   return;
 }
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -8391,8 +8391,10 @@
   "function %1 in global initializer">;
 def err_capture_bad_target : Error<
   "capture host variable %0 by reference in device or host device lambda 
function">;
-def err_capture_bad_target_this_ptr : Error<
-  "capture host side class data member by this pointer in device or host 
device lambda function">;
+def warn_maybe_capture_bad_target_this_ptr : Warning<
+  "capture host side class data member by this pointer in device or host 
device lambda function "
+  "may result in invalid m

[PATCH] D108493: [HIP] Warn capture this pointer in device lambda

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Sema/SemaCUDA.cpp:881-882
+  } else if (Capture.isThisCapture() && !LangOpts.HIP) {
+// Capture of this pointer is allowed for HIP since this pointer may be
+// pointing to managed memory which is accessible on both device and
+// host sides.

yaxunl wrote:
> tra wrote:
> > I assume there's no easy way to tell if it's a managed pointer or not.
> > Capturing a non-managed pointer would still be bad.
> > Should we make it a warning instead?
> > 
> > 
> warning makes sense. will do.
> 
> Also this should apply to CUDA too. Although clang does not support 
> `__managed__` keyword for CUDA, `this` pointer may be allocated in managed 
> memory through host API's.
> Also this should apply to CUDA too. 

I'm not sure I understand what you mean.

Do you suggest that the warning should be issued for both HIP and CUDA? If so, 
the diag already applies to CUDA.

Or that we should allow capturing wrong-side `this` w/o diagnostics for both 
CUDA and HIP?

I'm fine with the former. But I do not think we should silently allow capturing 
wrong-side `this` for CUDA, because it will be an error most of the time.


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

https://reviews.llvm.org/D108493

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

[PATCH] D108493: [HIP] Warn capture this pointer in device lambda

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Sema/SemaCUDA.cpp:881-882
+  } else if (Capture.isThisCapture() && !LangOpts.HIP) {
+// Capture of this pointer is allowed for HIP since this pointer may be
+// pointing to managed memory which is accessible on both device and
+// host sides.

tra wrote:
> yaxunl wrote:
> > tra wrote:
> > > I assume there's no easy way to tell if it's a managed pointer or not.
> > > Capturing a non-managed pointer would still be bad.
> > > Should we make it a warning instead?
> > > 
> > > 
> > warning makes sense. will do.
> > 
> > Also this should apply to CUDA too. Although clang does not support 
> > `__managed__` keyword for CUDA, `this` pointer may be allocated in managed 
> > memory through host API's.
> > Also this should apply to CUDA too. 
> 
> I'm not sure I understand what you mean.
> 
> Do you suggest that the warning should be issued for both HIP and CUDA? If 
> so, the diag already applies to CUDA.
> 
> Or that we should allow capturing wrong-side `this` w/o diagnostics for both 
> CUDA and HIP?
> 
> I'm fine with the former. But I do not think we should silently allow 
> capturing wrong-side `this` for CUDA, because it will be an error most of the 
> time.
Ah. Never mind. I've replied before your latest patch update.
LGTM


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

https://reviews.llvm.org/D108493

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

[PATCH] D108881: [clang][driver] Honor the last -flto(=.*)? argument

[Steven Wu via Phabricator via cfe-commits]

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

I am not familiar with offloading side of LTO driver but the change looks 
functionally the same to me. Thanks for doing this! Remember to update the 
commit message with the correct info.


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

https://reviews.llvm.org/D108881

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

[PATCH] D109451: Summary: Introduce a new frontend flag `-fswift-async-fp={auto|always|never}` that controls how code generation sets the Swift extended async frame info bit. There are three possibili

[Arnold Schwaighofer via Phabricator via cfe-commits]

aschwaighofer created this revision.
aschwaighofer added reviewers: doug.gregor, t.p.northover.
Herald added subscribers: ormris, dexonsmith, dang.
aschwaighofer requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

- `auto`: the default, which determines how to set the bit based on

deployment target, either statically or dynamically via
`swift_async_extendedFramePointerFlags`.

- `always`: always set the bit statically, regardless of deployment

target.

- `never`: never set the bit, regardless of deployment target.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109451

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/swift-async-extended-fp.c

Index: clang/test/CodeGen/swift-async-extended-fp.c
===
--- /dev/null
+++ clang/test/CodeGen/swift-async-extended-fp.c
@@ -0,0 +1,40 @@
+// RUN: %clang_cc1 -mframe-pointer=all -triple x86_64-apple-darwin10 -target-cpu core2 -S -o - %s | FileCheck %s --check-prefix=AUTO-X86
+// RUN: %clang_cc1 -mframe-pointer=all -triple x86_64-apple-darwin12 -target-cpu core2 -S -o - %s | FileCheck %s --check-prefix=ALWAYS-X86
+// RUN: %clang_cc1 -fswift-async-fp=never -mframe-pointer=all -triple x86_64-apple-darwin10 -target-cpu core2 -S -o - %s | FileCheck %s --check-prefix=NEVER-X86
+// RUN: %clang_cc1 -fswift-async-fp=never -mframe-pointer=all -triple x86_64-apple-darwin12 -target-cpu core2 -S -o - %s | FileCheck %s --check-prefix=NEVER-X86
+// RUN: %clang_cc1 -fswift-async-fp=auto -mframe-pointer=all -triple x86_64-apple-darwin10 -target-cpu core2 -S -o - %s | FileCheck %s --check-prefix=AUTO-X86
+// RUN: %clang_cc1 -fswift-async-fp=auto -mframe-pointer=all -triple x86_64-apple-darwin12 -target-cpu core2 -S -o - %s | FileCheck %s --check-prefix=ALWAYS-X86
+// RUN: %clang_cc1 -fswift-async-fp=always -mframe-pointer=all -triple x86_64-apple-darwin10 -target-cpu core2 -S -o - %s | FileCheck %s --check-prefix=ALWAYS-X86
+// RUN: %clang_cc1 -fswift-async-fp=always -mframe-pointer=all -triple x86_64-apple-darwin12 -target-cpu core2 -S -o - %s | FileCheck %s --check-prefix=ALWAYS-X86
+
+// RUN: %clang_cc1 -mframe-pointer=all -triple arm64-apple-ios9 -target-cpu cyclone -S -o - %s | FileCheck %s --check-prefix=AUTO-ARM64
+// RUN: %clang_cc1 -mframe-pointer=all -triple arm64-apple-ios15 -target-cpu cyclone -S -o - %s | FileCheck %s --check-prefix=ALWAYS-ARM64
+// RUN: %clang_cc1 -fswift-async-fp=never -mframe-pointer=all -triple arm64-apple-ios9 -target-cpu cyclone -S -o - %s | FileCheck %s --check-prefix=NEVER-ARM64
+// RUN: %clang_cc1 -fswift-async-fp=never -mframe-pointer=all -triple arm64-apple-ios15 -target-cpu cyclone -S -o - %s | FileCheck %s --check-prefix=NEVER-ARM64
+
+// REQUIRES: aarch64-registered-target,x86-registered-target
+
+#define SWIFTASYNCCALL __attribute__((swiftasynccall))
+#define ASYNC_CONTEXT __attribute__((swift_async_context))
+
+SWIFTASYNCCALL void async_context_1(ASYNC_CONTEXT void *ctx) {}
+
+// AUTO-X86: _async_context_1:
+// AUTO-X86:	_swift_async_extendedFramePointerFlags
+
+// ALWAYS-X86: _async_context_1:
+// ALWAYS-X86: btsq	$60
+
+// NEVER-X86: _async_context_1:
+// NEVER-X86-NOT:	_swift_async_extendedFramePointerFlags
+// NEVER-X86-NOT: btsq	$60
+
+// AUTO-ARM64: _async_context_1
+// AUTO-ARM64: _swift_async_extendedFramePointerFlags
+
+// ALWAYS-ARM64: _async_context_1
+// ALWAYS-ARM64: orr x29, x29, #0x1000
+
+// NEVER-ARM64: _async_context_1:
+// NEVER-ARM64-NOT:	_swift_async_extendedFramePointerFlags
+// NEVER-ARM64-NOT: orr x29, x29, #0x1000
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5909,6 +5909,8 @@
   RenderSCPOptions(TC, Args, CmdArgs);
   RenderTrivialAutoVarInitOptions(D, TC, Args, CmdArgs);
 
+  Args.AddLastArg(CmdArgs, options::OPT_fswift_async_fp_EQ);
+
   // Translate -mstackrealign
   if (Args.hasFlag(options::OPT_mstackrealign, options::OPT_mno_stackrealign,
false))
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -582,6 +582,21 @@
   Options.XRayOmitFunctionIndex = CodeGenOpts.XRayOmitFunctionIndex;
   Options.LoopAlignment = CodeGenOpts.LoopAlignment;
 
+  switch (CodeGenOpts.getSwiftAsyncFramePointer()) {
+  case CodeGenOptions::SwiftAsyncFramePointerKind::Auto:
+Options.SwiftAsyncFramePointer =
+SwiftAsyncFramePointerMode::DeploymentBased;
+break;
+
+  case CodeGenOptions::SwiftAsyncFramePointerKind::Always:
+Options.SwiftAsyncFramePointer = SwiftAsyncFr

[PATCH] D109175: [openmp] Emit deferred diag only when device compilation presents

[Wei Wang via Phabricator via cfe-commits]

weiwang added a comment.

In D109175#2987048 , @jdoerfert wrote:

> In D109175#2986782 , @yaxunl wrote:
>
>> I agree with Johannes and Alexey that deferred diags are only needed when 
>> LangOpts.OMPTargetTriples.empty(). However, I am not sure whether it is only 
>> needed in device compilation.
>>
>> For other offloading languages like CUDA/HIP it is needed in both device and 
>> host compilation.
>
> Technically, we might even want to delay in host only mode for OpenMP, but 
> that is something we can revisit (e.g., by dynamically setting a flag based 
> on the directives we've seen).
> @yaxunl Should we for now check if there is any associated offload job?

Shall we go ahead and get this change in and think about more longer term 
solution later?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109175

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

[PATCH] D109057: [openmp] Accept directory for libomptarget-bc-path

[Michael Kruse via Phabricator via cfe-commits]

Meinersbur added inline comments.



Comment at: clang/test/Driver/openmp-offload-gpu.c:178
 // CHK-BCLIB-USER: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-test.bc
-
+// CHK-BCLIB-USER-DIR: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget{{.}}libomptarget-nvptx-sm_35.bc
 // CHK-BCLIB-NOT: {{error:|warning:}}

`-###` escapes backslashes in Windows paths UNIX-style (which actually is 
unnecessary/wrong, the cmd.exe escape character is `^`, but windows also [[ 
https://stackoverflow.com/q/33027024 | ignores consecutive slashes ]]), so the 
actual output is
```
"-mlink-builtin-bitcode" 
"[...]\\clang\\test\\Driver/Inputs/libomptarget\\libomptarget-nvptx-sm_35.bc"
```

The regex `{{.}}` does not capture the double backslash. `{{/|}}` would 
work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109057

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

[PATCH] D109057: [openmp] Accept directory for libomptarget-bc-path

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

Nice, thanks! I'll wait for the main CI to come back up before trying that


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109057

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

[clang] 26e492e - [HIP] Warn capture this pointer in device lambda

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2021-09-08T13:45:26-04:00
New Revision: 26e492e134c006c63b3d9f9f9eabdeba014b1d2c

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

LOG: [HIP] Warn capture this pointer in device lambda

HIP currently diagnose capture of this pointer in device lambda in
host member functions. If this pointer points to managed memory,
it can be used in both device and host functions. Under this
situation, capturing this pointer in device lambda functions
in host member functions is valid usage. Change the diagnostic
about capturing this pointer to warning.

Reviewed by: Artem Belevich

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaCUDA.cpp
clang/test/SemaCUDA/lambda.cu

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index bebaf8fc9f0bb..f8e89549f0503 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -8391,8 +8391,10 @@ def err_ref_bad_target_global_initializer : Error<
   "function %1 in global initializer">;
 def err_capture_bad_target : Error<
   "capture host variable %0 by reference in device or host device lambda 
function">;
-def err_capture_bad_target_this_ptr : Error<
-  "capture host side class data member by this pointer in device or host 
device lambda function">;
+def warn_maybe_capture_bad_target_this_ptr : Warning<
+  "capture host side class data member by this pointer in device or host 
device lambda function "
+  "may result in invalid memory access if this pointer is not accessible on 
device side">,
+  InGroup>;
 def warn_kern_is_method : Extension<
   "kernel function %0 is a member function; this may not be accepted by nvcc">,
   InGroup;

diff  --git a/clang/lib/Sema/SemaCUDA.cpp b/clang/lib/Sema/SemaCUDA.cpp
index 75364c10c154b..840b3daae63cf 100644
--- a/clang/lib/Sema/SemaCUDA.cpp
+++ b/clang/lib/Sema/SemaCUDA.cpp
@@ -878,8 +878,13 @@ void Sema::CUDACheckLambdaCapture(CXXMethodDecl *Callee,
   diag::err_capture_bad_target, Callee, *this)
 << Capture.getVariable();
   } else if (Capture.isThisCapture()) {
+// Capture of this pointer is allowed since this pointer may be pointing to
+// managed memory which is accessible on both device and host sides. It 
only
+// results in invalid memory access if this pointer points to memory not
+// accessible on device side.
 SemaDiagnosticBuilder(DiagKind, Capture.getLocation(),
-  diag::err_capture_bad_target_this_ptr, Callee, 
*this);
+  diag::warn_maybe_capture_bad_target_this_ptr, Callee,
+  *this);
   }
   return;
 }

diff  --git a/clang/test/SemaCUDA/lambda.cu b/clang/test/SemaCUDA/lambda.cu
index 6f305a683c009..524cdd429bf53 100644
--- a/clang/test/SemaCUDA/lambda.cu
+++ b/clang/test/SemaCUDA/lambda.cu
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify=com %s
-// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device -verify=com,dev %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device 
-verify=com,dev,warn %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device 
-verify=com,dev,warn \
+// RUN:   -triple amdgcn-amd-amdhsa -target-cpu gfx906 -x hip %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device -verify=com,dev \
+// RUN:   -Wno-gpu-maybe-wrong-side %s
 
 #include "Inputs/cuda.h"
 
@@ -7,7 +11,8 @@ auto global_lambda = [] () { return 123; };
 
 template
 __global__ void kernel(F f) { f(); }
-// dev-note@-1 7{{called by 'kernel<(lambda}}
+// dev-note@-1 3{{called by 'kernel<(lambda}}
+// warn-note@-2 5{{called by 'kernel<(lambda}}
 
 __host__ __device__ void hd(int x);
 
@@ -22,19 +27,23 @@ public:
 kernel<<<1,1>>>([](){ hd(0); });
 
 kernel<<<1,1>>>([=](){ hd(b); });
-// dev-error@-1 {{capture host side class data member by this pointer in 
device or host device lambda function}}
+// warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
 
 kernel<<<1,1>>>([&](){ hd(b); });
-// dev-error@-1 {{capture host side class data member by this pointer in 
device or host device lambda function}}
+// warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
 
 kernel<<<1,1>>>([&] __device__ (){ hd(b); });
-// dev-error@-1 {{capture host side class data member 

[PATCH] D108493: [HIP] Warn capture this pointer in device lambda

[Yaxun Liu 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 rG26e492e134c0: [HIP] Warn capture this pointer in device 
lambda (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108493

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaCUDA.cpp
  clang/test/SemaCUDA/lambda.cu


Index: clang/test/SemaCUDA/lambda.cu
===
--- clang/test/SemaCUDA/lambda.cu
+++ clang/test/SemaCUDA/lambda.cu
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify=com %s
-// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device -verify=com,dev %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device 
-verify=com,dev,warn %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device 
-verify=com,dev,warn \
+// RUN:   -triple amdgcn-amd-amdhsa -target-cpu gfx906 -x hip %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcuda-is-device -verify=com,dev \
+// RUN:   -Wno-gpu-maybe-wrong-side %s
 
 #include "Inputs/cuda.h"
 
@@ -7,7 +11,8 @@
 
 template
 __global__ void kernel(F f) { f(); }
-// dev-note@-1 7{{called by 'kernel<(lambda}}
+// dev-note@-1 3{{called by 'kernel<(lambda}}
+// warn-note@-2 5{{called by 'kernel<(lambda}}
 
 __host__ __device__ void hd(int x);
 
@@ -22,19 +27,23 @@
 kernel<<<1,1>>>([](){ hd(0); });
 
 kernel<<<1,1>>>([=](){ hd(b); });
-// dev-error@-1 {{capture host side class data member by this pointer in 
device or host device lambda function}}
+// warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
 
 kernel<<<1,1>>>([&](){ hd(b); });
-// dev-error@-1 {{capture host side class data member by this pointer in 
device or host device lambda function}}
+// warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
 
 kernel<<<1,1>>>([&] __device__ (){ hd(b); });
-// dev-error@-1 {{capture host side class data member by this pointer in 
device or host device lambda function}}
+// warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
 
 kernel<<<1,1>>>([&](){
   auto f = [&]{ hd(b); };
-  // dev-error@-1 {{capture host side class data member by this pointer in 
device or host device lambda function}}
+  // warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
   f();
 });
+
+auto lambda1 = [this] __device__ { hd(this->b); };
+// warn-warning@-1 {{capture host side class data member by this pointer 
in device or host device lambda function may result in invalid memory access if 
this pointer is not accessible on device side}}
+kernel<<<1,1>>>(lambda1);
   }
 };
 
Index: clang/lib/Sema/SemaCUDA.cpp
===
--- clang/lib/Sema/SemaCUDA.cpp
+++ clang/lib/Sema/SemaCUDA.cpp
@@ -878,8 +878,13 @@
   diag::err_capture_bad_target, Callee, *this)
 << Capture.getVariable();
   } else if (Capture.isThisCapture()) {
+// Capture of this pointer is allowed since this pointer may be pointing to
+// managed memory which is accessible on both device and host sides. It 
only
+// results in invalid memory access if this pointer points to memory not
+// accessible on device side.
 SemaDiagnosticBuilder(DiagKind, Capture.getLocation(),
-  diag::err_capture_bad_target_this_ptr, Callee, 
*this);
+  diag::warn_maybe_capture_bad_target_this_ptr, Callee,
+  *this);
   }
   return;
 }
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -8391,8 +8391,10 @@
   "function %1 in global initializer">;
 def err_capture_bad_target : Error<
   "capture host variable %0 by reference in device or host device lambda 
function">;
-def err_capture_bad_target_this_ptr : Error<
-  "capture host side class data member by this pointer in device or host 
device lambda function">;
+def warn_maybe_capture_bad_target_this_ptr : Warning<
+  "capture host side class data member by this pointer in device or host 
device lambda functi

[PATCH] D109175: [openmp] Emit deferred diag only when device compilation presents

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D109175#2989823 , @weiwang wrote:

> In D109175#2987048 , @jdoerfert 
> wrote:
>
>> In D109175#2986782 , @yaxunl wrote:
>>
>>> I agree with Johannes and Alexey that deferred diags are only needed when 
>>> LangOpts.OMPTargetTriples.empty(). However, I am not sure whether it is 
>>> only needed in device compilation.
>>>
>>> For other offloading languages like CUDA/HIP it is needed in both device 
>>> and host compilation.
>>
>> Technically, we might even want to delay in host only mode for OpenMP, but 
>> that is something we can revisit (e.g., by dynamically setting a flag based 
>> on the directives we've seen).
>> @yaxunl Should we for now check if there is any associated offload job?
>
> Shall we go ahead and get this change in and think about more longer term 
> solution later?

LGTM. This patch should be sufficient to limit deferred diags to OpenMP with 
offloading. Device compilation is covered by OpenMPIsDevice and host 
compilation is covered by !LangOpts.OMPTargetTriples.empty(). I will leave the 
decision to Johannes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109175

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

[PATCH] D108441: [clang] Fix JSON AST output when a filter is used

[William Woodruff via Phabricator via cfe-commits]

woodruffw added a comment.

Another gentle ping for review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108441

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

[clang] e567356 - [compiler-rt][Fuchsia] Support building + running compiler-rt tests on fuchsia's host toolchain

[Leonard Chan via cfe-commits]

Author: Leonard Chan
Date: 2021-09-08T11:32:11-07:00
New Revision: e5673564a06b7792c6aa9afe3d82f8b2203f975e

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

LOG: [compiler-rt][Fuchsia] Support building + running compiler-rt tests on 
fuchsia's host toolchain

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

Added: 


Modified: 
clang/cmake/caches/Fuchsia-stage2.cmake

Removed: 




diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index 09e8a0780c54c..5efa3028a0c65 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -60,7 +60,6 @@ if(APPLE)
   set(COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "")
 
   set(LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
-  set(LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "")
   set(LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
   set(LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "")
   set(LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "")
@@ -121,9 +120,9 @@ foreach(target 
aarch64-unknown-linux-gnu;armv7-unknown-linux-gnueabihf;i386-unkn
 set(RUNTIMES_${target}_CMAKE_MODULE_LINKER_FLAGS "-fuse-ld=lld" CACHE 
STRING "")
 set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld" CACHE STRING 
"")
 set(RUNTIMES_${target}_COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "")
+set(RUNTIMES_${target}_COMPILER_RT_CAN_EXECUTE_TESTS ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
-set(RUNTIMES_${target}_LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "")
@@ -136,6 +135,10 @@ foreach(target 
aarch64-unknown-linux-gnu;armv7-unknown-linux-gnueabihf;i386-unkn
 set(RUNTIMES_${target}_LLVM_ENABLE_ASSERTIONS OFF CACHE BOOL "")
 set(RUNTIMES_${target}_SANITIZER_CXX_ABI "libc++" CACHE STRING "")
 set(RUNTIMES_${target}_SANITIZER_CXX_ABI_INTREE ON CACHE BOOL "")
+set(RUNTIMES_${target}_COMPILER_RT_TEST_COMPILER_CFLAGS 
"--unwindlib=libunwind -static-libgcc" CACHE STRING "")
+set(RUNTIMES_${target}_SANITIZER_COMMON_TEST_TARGET_CFLAGS 
"--unwindlib=libunwind -static-libgcc" CACHE STRING "")
+set(RUNTIMES_${target}_TSAN_TEST_TARGET_CFLAGS "--unwindlib=libunwind" 
CACHE STRING "")
+set(RUNTIMES_${target}_LLVM_TOOLS_DIR "${CMAKE_BINARY_DIR}/bin" CACHE BOOL 
"")
 set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES 
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "")
 
 # Use .build-id link.



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

[PATCH] D109199: [compiler-rt][Fuchsia] Support building + running compiler-rt tests on fuchsia's host toolchain

[Leonard Chan 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 rGe5673564a06b: [compiler-rt][Fuchsia] Support building + 
running compiler-rt tests on… (authored by leonardchan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109199

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -60,7 +60,6 @@
   set(COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "")
 
   set(LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
-  set(LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "")
   set(LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
   set(LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "")
   set(LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "")
@@ -121,9 +120,9 @@
 set(RUNTIMES_${target}_CMAKE_MODULE_LINKER_FLAGS "-fuse-ld=lld" CACHE 
STRING "")
 set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld" CACHE STRING 
"")
 set(RUNTIMES_${target}_COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "")
+set(RUNTIMES_${target}_COMPILER_RT_CAN_EXECUTE_TESTS ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
-set(RUNTIMES_${target}_LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "")
@@ -136,6 +135,10 @@
 set(RUNTIMES_${target}_LLVM_ENABLE_ASSERTIONS OFF CACHE BOOL "")
 set(RUNTIMES_${target}_SANITIZER_CXX_ABI "libc++" CACHE STRING "")
 set(RUNTIMES_${target}_SANITIZER_CXX_ABI_INTREE ON CACHE BOOL "")
+set(RUNTIMES_${target}_COMPILER_RT_TEST_COMPILER_CFLAGS 
"--unwindlib=libunwind -static-libgcc" CACHE STRING "")
+set(RUNTIMES_${target}_SANITIZER_COMMON_TEST_TARGET_CFLAGS 
"--unwindlib=libunwind -static-libgcc" CACHE STRING "")
+set(RUNTIMES_${target}_TSAN_TEST_TARGET_CFLAGS "--unwindlib=libunwind" 
CACHE STRING "")
+set(RUNTIMES_${target}_LLVM_TOOLS_DIR "${CMAKE_BINARY_DIR}/bin" CACHE BOOL 
"")
 set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES 
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "")
 
 # Use .build-id link.


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -60,7 +60,6 @@
   set(COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "")
 
   set(LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
-  set(LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "")
   set(LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
   set(LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "")
   set(LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "")
@@ -121,9 +120,9 @@
 set(RUNTIMES_${target}_CMAKE_MODULE_LINKER_FLAGS "-fuse-ld=lld" CACHE STRING "")
 set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld" CACHE STRING "")
 set(RUNTIMES_${target}_COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "")
+set(RUNTIMES_${target}_COMPILER_RT_CAN_EXECUTE_TESTS ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
-set(RUNTIMES_${target}_LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "")
@@ -136,6 +135,10 @@
 set(RUNTIMES_${target}_LLVM_ENABLE_ASSERTIONS OFF CACHE BOOL "")
 set(RUNTIMES_${target}_SANITIZER_CXX_ABI "libc++" CACHE STRING "")
 set(RUNTIMES_${target}_SANITIZER_CXX_ABI_INTREE ON CACHE BOOL "")
+set(RUNTIMES_${target}_COMPILER_RT_TEST_COMPILER_CFLAGS "--unwindlib=libunwind -static-libgcc" CACHE STRING "")
+set(RUNTIMES_${target}_SANITIZER_COMMON_TEST_TARGET_CFLAGS "--unwindlib=libunwind -static-libgcc" CACHE STRING "")
+set(RUNTIMES_${target}_TSAN_TEST_TARGET_CFLAGS "--unwindlib=libunwind" CACHE STRING "")
+set(RUNTIMES_${target}_LLVM_TOOLS_DIR "${CMAKE_BINARY_DIR}/bin" CACHE BOOL "")
 set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "")
 
 # Use .build-id link.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D109408: [libcxxabi] NFC: fix incorrect indentation of braces

[Zhouyi Zhou via cfe-commits]

Hi，

On Wed, Sep 8, 2021 at 10:01 AM zhouyizhou via Phabricator
 wrote:
>
> zhouyizhou added a comment.
>
> In D109408#2988417 , @ldionne wrote:
>
> > FWIW, I dislike that we don't indent stuff at all inside namespaces -- 
> > often I find it useful to indent things inside short-lived namespaces. But 
> > let's go for simplicity and consistency.
> >
> > Did you look into clang-formatting other files in libc++abi? What would the 
> > diff look like?

I take a general view of .cpp(.h) files in libc++abi, they are
distributed in several directories. I do an experiment with
fuzz/cxa_demangle_fuzzer.cpp using clang-format, the result is as
follows:
--- cxa_demangle_fuzzer.cpp.orig2021-09-09 02:19:17.117872938 +0800
+++ cxa_demangle_fuzzer.cpp2021-09-09 02:19:34.845879852 +0800
@@ -1,15 +1,15 @@
-#include 
 #include 
-#include 
+#include 
 #include 
-extern "C" char *
-__cxa_demangle(const char *mangled_name, char *buf, size_t *n, int *status);
+#include 
+extern "C" char *__cxa_demangle(const char *mangled_name, char *buf, size_t *n,
+int *status);

 extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
-  char *str = new char[size+1];
+  char *str = new char[size + 1];
   memcpy(str, data, size);
   str[size] = 0;
   free(__cxa_demangle(str, 0, 0, 0));
-  delete [] str;
+  delete[] str;
   return 0;
 }

As a beginner of LLVM and C++, I guess clang-formatting is meaningful ;-)

I guess we can clang-format a set of files at a time, and step-by-step
clang-format all the .cpp(.h) files in libc++abi and fine-tune the
results as how Quuxplusone did it ,
what's your opinion? If it is OK, I am very honored and pleased to do
this work ;-)

Cheers
Zhouyi


>
> Thanks for reviewing,
> I will look into other files in libc++abi one by one, and report what I have 
> found ;-)
> Thanks again
> Zhouyi
>
>
>
> 
> Comment at: libcxxabi/src/cxa_exception_storage.cpp:102
>  }
>  }
> +} // namespace __cxxabiv1
> 
> Quuxplusone wrote:
> > LGTM, FWIW.
> >
> > It's surprising that clang-format adds `} // namespace foo` closing 
> > comments, but doesn't add `} // extern "C"` closing comments: this lonely 
> > brace is a bit confusing and I think it //would// benefit from an `// 
> > extern "C"` comment.
> Thanks for reviewing,
> clang-format do behave a little strange to me. The result of invoking 
> clang-format in git cloned directory is diffent from invoking clang-format in 
> other directory ( for example /tmp).
> By the way, I have not write access to LLVM, so I need someone to commit for 
> me.
>
> Thanks again ;-)
> Zhouyi
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D109408/new/
>
> https://reviews.llvm.org/D109408
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109408: [libcxxabi] NFC: fix incorrect indentation of braces

[zhouyizhou via Phabricator via cfe-commits]

zhouyizhou added a comment.

In D109408#2988417 , @ldionne wrote:

> FWIW, I dislike that we don't indent stuff at all inside namespaces -- often 
> I find it useful to indent things inside short-lived namespaces. But let's go 
> for simplicity and consistency.
>
> Did you look into clang-formatting other files in libc++abi? What would the 
> diff look like?

I take a general view of .cpp(.h) files in libc++abi, they are distributed in 
several directories. I do an experiment with
fuzz/cxa_demangle_fuzzer.cpp using clang-format, the result is as follows:

- cxa_demangle_fuzzer.cpp.orig2021-09-09 02:19:17.117872938 +0800

+++ cxa_demangle_fuzzer.cpp2021-09-09 02:19:34.845879852 +0800
@@ -1,15 +1,15 @@
-#include 
 #include 
-#include 
+#include 
 #include 
-extern "C" char *
-__cxa_demangle(const char *mangled_name, char *buf, size_t *n, int *status);
+#include 
+extern "C" char *__cxa_demangle(const char *mangled_name, char *buf, size_t *n,
+int *status);

extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {

- char *str = new char[size+1];

+  char *str = new char[size + 1];

  memcpy(str, data, size);
  str[size] = 0;
  free(__cxa_demangle(str, 0, 0, 0));

- delete [] str;

+  delete[] str;

  return 0;

}

As a beginner of LLVM and C++, I guess clang-formatting is meaningful ;-)

I guess we can clang-format a set of files at a time, and step-by-step 
clang-format all the .cpp(.h) files in libc++abi and fine-tune the results as 
how Quuxplusone did it ,
what's your opinion? If it is OK, I am very honored and pleased to do this work 
;-)

Zhouyi


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109408

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

[PATCH] D102996: [ObjC][ARC] Use the addresses of the ARC runtime functions instead of integer 0/1 for the operand of bundle "clang.arc.attachedcall"

[Akira Hatanaka via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG59cc39ae141f: [ObjC][ARC] Use the addresses of the ARC 
runtime functions instead of (authored by ahatanak).

Changed prior to commit:
  https://reviews.llvm.org/D102996?vs=347291&id=371412#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102996

Files:
  clang/lib/CodeGen/CGObjC.cpp
  clang/test/CodeGenObjC/arc-rv-attr.m
  clang/test/CodeGenObjCXX/arc-rv-attr.mm

Index: clang/test/CodeGenObjCXX/arc-rv-attr.mm
===
--- clang/test/CodeGenObjCXX/arc-rv-attr.mm
+++ clang/test/CodeGenObjCXX/arc-rv-attr.mm
@@ -3,7 +3,7 @@
 id foo(void);
 
 // CHECK-LABEL: define{{.*}} void @_Z14test_list_initv(
-// CHECK: %[[CALL1:.*]] = call i8* @_Z3foov() [ "clang.arc.attachedcall"(i64 0) ]
+// CHECK: %[[CALL1:.*]] = call i8* @_Z3foov() [ "clang.arc.attachedcall"(i8* (i8*)* @llvm.objc.retainAutoreleasedReturnValue) ]
 // CHECK: call i8* @llvm.objc.retain(i8* %[[CALL1]])
 
 void test_list_init() {
Index: clang/test/CodeGenObjC/arc-rv-attr.m
===
--- clang/test/CodeGenObjC/arc-rv-attr.m
+++ clang/test/CodeGenObjC/arc-rv-attr.m
@@ -10,7 +10,7 @@
 }
 // CHECK-LABEL: define{{.*}} void @test_assign()
 // CHECK: [[X:%.*]] = alloca i8*
-// CHECK: [[T0:%.*]] = call [[A:.*]]* @makeA() [ "clang.arc.attachedcall"(i64 1) ]
+// CHECK: [[T0:%.*]] = call [[A:.*]]* @makeA() [ "clang.arc.attachedcall"(i8* (i8*)* @llvm.objc.unsafeClaimAutoreleasedReturnValue) ]
 // CHECK-NEXT:call void (...) @llvm.objc.clang.arc.noop.use({{.*}} [[T0]])
 // CHECK-NEXT:[[T1:%.*]] = bitcast [[A]]* [[T0]] to i8*
 // CHECK-NEXT:store i8* [[T1]], i8** [[X]]
@@ -25,7 +25,7 @@
 // CHECK-LABEL: define{{.*}} void @test_assign_assign()
 // CHECK: [[X:%.*]] = alloca i8*
 // CHECK: [[Y:%.*]] = alloca i8*
-// CHECK: [[T0:%.*]] = call [[A]]* @makeA() [ "clang.arc.attachedcall"(i64 1) ]
+// CHECK: [[T0:%.*]] = call [[A]]* @makeA() [ "clang.arc.attachedcall"(i8* (i8*)* @llvm.objc.unsafeClaimAutoreleasedReturnValue) ]
 // CHECK-NEXT:call void (...) @llvm.objc.clang.arc.noop.use({{.*}} [[T0]])
 // CHECK-NEXT:[[T1:%.*]] = bitcast [[A]]* [[T0]] to i8*
 // CHECK-NEXT:store i8* [[T1]], i8** [[Y]]
@@ -44,7 +44,7 @@
 // CHECK-LABEL: define{{.*}} void @test_strong_assign_assign()
 // CHECK: [[X:%.*]] = alloca i8*
 // CHECK: [[Y:%.*]] = alloca i8*
-// CHECK: [[T0:%.*]] = call [[A]]* @makeA() [ "clang.arc.attachedcall"(i64 0) ]
+// CHECK: [[T0:%.*]] = call [[A]]* @makeA() [ "clang.arc.attachedcall"(i8* (i8*)* @llvm.objc.retainAutoreleasedReturnValue) ]
 // CHECK-NEXT:call void (...) @llvm.objc.clang.arc.noop.use({{.*}} [[T0]])
 // CHECK-NEXT:[[T1:%.*]] = bitcast [[A]]* [[T0]] to i8*
 // CHECK-NEXT:store i8* [[T1]], i8** [[Y]]
@@ -67,7 +67,7 @@
 // CHECK-LABEL: define{{.*}} void @test_assign_strong_assign()
 // CHECK: [[X:%.*]] = alloca i8*
 // CHECK: [[Y:%.*]] = alloca i8*
-// CHECK: [[T0:%.*]] = call [[A]]* @makeA() [ "clang.arc.attachedcall"(i64 0) ]
+// CHECK: [[T0:%.*]] = call [[A]]* @makeA() [ "clang.arc.attachedcall"(i8* (i8*)* @llvm.objc.retainAutoreleasedReturnValue) ]
 // CHECK-NEXT:call void (...) @llvm.objc.clang.arc.noop.use({{.*}} [[T0]])
 // CHECK-NEXT:[[T1:%.*]] = bitcast [[A]]* [[T0]] to i8*
 // CHECK-NEXT:[[OLD:%.*]] = load i8*, i8** [[Y]]
@@ -87,7 +87,7 @@
 }
 // CHECK-LABEL: define{{.*}} void @test_init()
 // CHECK: [[X:%.*]] = alloca i8*
-// CHECK: [[T0:%.*]] = call [[A]]* @makeA() [ "clang.arc.attachedcall"(i64 1) ]
+// CHECK: [[T0:%.*]] = call [[A]]* @makeA() [ "clang.arc.attachedcall"(i8* (i8*)* @llvm.objc.unsafeClaimAutoreleasedReturnValue) ]
 // CHECK-NEXT:call void (...) @llvm.objc.clang.arc.noop.use({{.*}} [[T0]])
 // CHECK-NEXT:[[T1:%.*]] = bitcast [[A]]* [[T0]] to i8*
 // CHECK-NEXT:store i8* [[T1]], i8** [[X]]
@@ -102,7 +102,7 @@
 // CHECK-LABEL: define{{.*}} void @test_init_assignment()
 // CHECK: [[X:%.*]] = alloca i8*
 // CHECK: [[Y:%.*]] = alloca i8*
-// CHECK: [[T0:%.*]] = call [[A]]* @makeA() [ "clang.arc.attachedcall"(i64 1) ]
+// CHECK: [[T0:%.*]] = call [[A]]* @makeA() [ "clang.arc.attachedcall"(i8* (i8*)* @llvm.objc.unsafeClaimAutoreleasedReturnValue) ]
 // CHECK-NEXT:call void (...) @llvm.objc.clang.arc.noop.use({{.*}} [[T0]])
 // CHECK-NEXT:[[T1:%.*]] = bitcast [[A]]* [[T0]] to i8*
 // CHECK-NEXT:store i8* [[T1]], i8** [[X]]
@@ -120,7 +120,7 @@
 // CHECK-LABEL: define{{.*}} void @test_strong_init_assignment()
 // CHECK: [[X:%.*]] = alloca i8*
 // CHECK: [[Y:%.*]] = alloca i8*
-// CHECK: [[T0:%.*]] = call [[A]]* @makeA() [ "clang.arc.attachedcall"(i64 0) ]
+// CHECK: [[T0:

[clang] 59cc39a - [ObjC][ARC] Use the addresses of the ARC runtime functions instead of

[Akira Hatanaka via cfe-commits]

Author: Akira Hatanaka
Date: 2021-09-08T11:56:22-07:00
New Revision: 59cc39ae141f92c01836064cd033c537f16dec5e

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

LOG: [ObjC][ARC] Use the addresses of the ARC runtime functions instead of
integer 0/1 for the operand of bundle "clang.arc.attachedcall"

This should make it easier to understand what the IR is doing and also
simplify some of the passes as they no longer have to translate the
integer values to the runtime functions.

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

Added: 


Modified: 
clang/lib/CodeGen/CGObjC.cpp
clang/test/CodeGenObjC/arc-rv-attr.m
clang/test/CodeGenObjCXX/arc-rv-attr.mm

Removed: 




diff  --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index 2dcbdd337ed7c..0aaec9af2f41e 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -2108,6 +2108,13 @@ static void setARCRuntimeFunctionLinkage(CodeGenModule 
&CGM,
   setARCRuntimeFunctionLinkage(CGM, RTF.getCallee());
 }
 
+static llvm::Function *getARCIntrinsic(llvm::Intrinsic::ID IntID,
+   CodeGenModule &CGM) {
+  llvm::Function *fn = CGM.getIntrinsic(IntID);
+  setARCRuntimeFunctionLinkage(CGM, fn);
+  return fn;
+}
+
 /// Perform an operation having the signature
 ///   i8* (i8*)
 /// where a null input causes a no-op and returns null.
@@ -2118,10 +2125,8 @@ static llvm::Value *emitARCValueOperation(
   if (isa(value))
 return value;
 
-  if (!fn) {
-fn = CGF.CGM.getIntrinsic(IntID);
-setARCRuntimeFunctionLinkage(CGF.CGM, fn);
-  }
+  if (!fn)
+fn = getARCIntrinsic(IntID, CGF.CGM);
 
   // Cast the argument to 'id'.
   llvm::Type *origType = returnType ? returnType : value->getType();
@@ -2140,10 +2145,8 @@ static llvm::Value *emitARCValueOperation(
 static llvm::Value *emitARCLoadOperation(CodeGenFunction &CGF, Address addr,
  llvm::Function *&fn,
  llvm::Intrinsic::ID IntID) {
-  if (!fn) {
-fn = CGF.CGM.getIntrinsic(IntID);
-setARCRuntimeFunctionLinkage(CGF.CGM, fn);
-  }
+  if (!fn)
+fn = getARCIntrinsic(IntID, CGF.CGM);
 
   // Cast the argument to 'id*'.
   llvm::Type *origType = addr.getElementType();
@@ -2168,10 +2171,8 @@ static llvm::Value 
*emitARCStoreOperation(CodeGenFunction &CGF, Address addr,
   bool ignored) {
   assert(addr.getElementType() == value->getType());
 
-  if (!fn) {
-fn = CGF.CGM.getIntrinsic(IntID);
-setARCRuntimeFunctionLinkage(CGF.CGM, fn);
-  }
+  if (!fn)
+fn = getARCIntrinsic(IntID, CGF.CGM);
 
   llvm::Type *origType = value->getType();
 
@@ -2193,10 +2194,8 @@ static void emitARCCopyOperation(CodeGenFunction &CGF, 
Address dst, Address src,
  llvm::Intrinsic::ID IntID) {
   assert(dst.getType() == src.getType());
 
-  if (!fn) {
-fn = CGF.CGM.getIntrinsic(IntID);
-setARCRuntimeFunctionLinkage(CGF.CGM, fn);
-  }
+  if (!fn)
+fn = getARCIntrinsic(IntID, CGF.CGM);
 
   llvm::Value *args[] = {
 CGF.Builder.CreateBitCast(dst.getPointer(), CGF.Int8PtrPtrTy),
@@ -2340,13 +2339,19 @@ static llvm::Value 
*emitOptimizedARCReturnCall(llvm::Value *value,
   // retainRV or claimRV calls in the IR. We currently do this only when the
   // optimization level isn't -O0 since global-isel, which is currently run at
   // -O0, doesn't know about the operand bundle.
+  ObjCEntrypoints &EPs = CGF.CGM.getObjCEntrypoints();
+  llvm::Function *&EP = IsRetainRV
+? EPs.objc_retainAutoreleasedReturnValue
+: EPs.objc_unsafeClaimAutoreleasedReturnValue;
+  llvm::Intrinsic::ID IID =
+  IsRetainRV ? llvm::Intrinsic::objc_retainAutoreleasedReturnValue
+ : llvm::Intrinsic::objc_unsafeClaimAutoreleasedReturnValue;
+  EP = getARCIntrinsic(IID, CGF.CGM);
 
   // FIXME: Do this when the target isn't aarch64.
   if (CGF.CGM.getCodeGenOpts().OptimizationLevel > 0 &&
   CGF.CGM.getTarget().getTriple().isAArch64()) {
-llvm::Value *bundleArgs[] = {llvm::ConstantInt::get(
-CGF.Int64Ty,
-llvm::objcarc::getAttachedCallOperandBundleEnum(IsRetainRV))};
+llvm::Value *bundleArgs[] = {EP};
 llvm::OperandBundleDef OB("clang.arc.attachedcall", bundleArgs);
 auto *oldCall = cast(value);
 llvm::CallBase *newCall = llvm::CallBase::addOperandBundle(
@@ -2362,13 +2367,6 @@ static llvm::Value 
*emitOptimizedARCReturnCall(llvm::Value *value,
   CGF.CGM.getTargetCodeGenInfo().markARCOptimizedReturnCallsAsNoTail();
   llvm::CallInst::TailCallKind tailKind =
   isNoTail ? llvm::CallInst::TCK_NoTail : llvm::CallInst::TCK_None;
-  ObjCEntrypoints &EPs = CGF.

[PATCH] D109387: [NFC][AIX] Check for typedef properly when getting preferred type align

[Steven Wan via Phabricator via cfe-commits]

stevewan added a comment.

In D109387#2987843 , @rjmccall wrote:

> Oh, no, I don't think this is NFC.  It seems very likely that there's some 
> case where the behavior is distinguishable.  Maybe a typedef of a record with 
> an alignment attribute?
>
>   __attribute__((aligned(2), packed)) struct float4 { float x, y, z, w; };
>   typedef struct float4 float4typedef;
>   
>   struct {
> float4typedef field; // presumably still eligible for alignment upgrade
>   };

Right, the behaviour difference is exactly what I'm trying to fix, silly me :). 
Though the diff isn't very obvious in the given example because ABIAlign equals 
to PreferredAlign in that particular case, the following test may provide a 
better exposure,

  struct __attribute__((aligned(2))) S { double x; };
  typedef struct S SS;




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109387

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

[PATCH] D109411: [clang] Enable the special enable_if_t diagnostics for libc++'s __enable_if_t as well.

[Louis Dionne via Phabricator via cfe-commits]

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

This seems reasonable to me.




Comment at: clang/lib/Sema/SemaTemplate.cpp:3514
 /// Determine whether this alias template is "enable_if_t".
+/// libc++ >=14 uses "__enable_if_t" in C++11 mode.
 static bool isEnableIfAliasTemplate(TypeAliasTemplateDecl *AliasTemplate) {

Nit: `libc++ >= 14`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109411

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

[PATCH] D109387: [AIX] Check for typedef properly when getting preferred type align

[Steven Wan via Phabricator via cfe-commits]

stevewan updated this revision to Diff 371418.
stevewan added a comment.

Add test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109387

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/Layout/aix-power-alignment-typedef-2.cpp


Index: clang/test/Layout/aix-power-alignment-typedef-2.cpp
===
--- clang/test/Layout/aix-power-alignment-typedef-2.cpp
+++ clang/test/Layout/aix-power-alignment-typedef-2.cpp
@@ -4,12 +4,26 @@
 // RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -S -emit-llvm -x c++ < %s | 
\
 // RUN:   FileCheck %s
 
-struct C {
+namespace test1 {
+struct S {
   double x;
 };
 
-typedef struct C __attribute__((__aligned__(2))) CC;
+typedef struct S __attribute__((__aligned__(2))) SS;
 
-CC cc;
+SS ss;
 
-// CHECK: @cc = global %struct.C zeroinitializer, align 2
+// CHECK: @{{.*}}test1{{.*}}ss{{.*}} = global %"struct.test1::S" 
zeroinitializer, align 2
+} // namespace test1
+
+namespace test2 {
+struct __attribute__((__aligned__(2))) S {
+  double x;
+};
+
+typedef struct S SS;
+
+SS ss;
+
+// CHECK: @{{.*}}test2{{.*}}ss{{.*}} = global %"struct.test2::S" 
zeroinitializer, align 8
+} // namespace test2
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -2497,8 +2497,10 @@
 const RecordDecl *RD = RT->getDecl();
 
 // When used as part of a typedef, or together with a 'packed' attribute,
-// the 'aligned' attribute can be used to decrease alignment.
-if ((TI.isAlignRequired() && T->getAs() != nullptr) ||
+// the 'aligned' attribute can be used to decrease alignment. Note that the
+// 'packed' case is already taken into consideration when computing the
+// alignment, we only need to handle the typedef case here.
+if (TI.AlignRequirement == AlignRequirementKind::RequiredByTypedef ||
 RD->isInvalidDecl())
   return ABIAlign;
 


Index: clang/test/Layout/aix-power-alignment-typedef-2.cpp
===
--- clang/test/Layout/aix-power-alignment-typedef-2.cpp
+++ clang/test/Layout/aix-power-alignment-typedef-2.cpp
@@ -4,12 +4,26 @@
 // RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -S -emit-llvm -x c++ < %s | \
 // RUN:   FileCheck %s
 
-struct C {
+namespace test1 {
+struct S {
   double x;
 };
 
-typedef struct C __attribute__((__aligned__(2))) CC;
+typedef struct S __attribute__((__aligned__(2))) SS;
 
-CC cc;
+SS ss;
 
-// CHECK: @cc = global %struct.C zeroinitializer, align 2
+// CHECK: @{{.*}}test1{{.*}}ss{{.*}} = global %"struct.test1::S" zeroinitializer, align 2
+} // namespace test1
+
+namespace test2 {
+struct __attribute__((__aligned__(2))) S {
+  double x;
+};
+
+typedef struct S SS;
+
+SS ss;
+
+// CHECK: @{{.*}}test2{{.*}}ss{{.*}} = global %"struct.test2::S" zeroinitializer, align 8
+} // namespace test2
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -2497,8 +2497,10 @@
 const RecordDecl *RD = RT->getDecl();
 
 // When used as part of a typedef, or together with a 'packed' attribute,
-// the 'aligned' attribute can be used to decrease alignment.
-if ((TI.isAlignRequired() && T->getAs() != nullptr) ||
+// the 'aligned' attribute can be used to decrease alignment. Note that the
+// 'packed' case is already taken into consideration when computing the
+// alignment, we only need to handle the typedef case here.
+if (TI.AlignRequirement == AlignRequirementKind::RequiredByTypedef ||
 RD->isInvalidDecl())
   return ABIAlign;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109451: Summary: Introduce a new frontend flag `-fswift-async-fp={auto|always|never}` that controls how code generation sets the Swift extended async frame info bit. There are three possibili

[Doug Gregor via Phabricator via cfe-commits]

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

Looks great, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109451

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

LLVM lab and buildbot master are back to normal

[Galina Kistanova via cfe-commits]

Hello everyone,

The LLVM lab and buildbot master are back to normal, up and running.
Died network hardware has been replaced. Please let me know if you still
see issues.

Sorry for the inconvenience and thanks for your patience.

Thanks

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

[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield updated this revision to Diff 371419.
JonChesterfield added a comment.

- Keep LIBRARY_PATH search, as fallback if local file is missing


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/Inputs/libomptarget/libomptarget-new-nvptx-test.bc
  clang/test/Driver/amdgpu-openmp-toolchain.c
  clang/test/Driver/openmp-offload-gpu.c
  openmp/libomptarget/test/lit.cfg

Index: openmp/libomptarget/test/lit.cfg
===
--- openmp/libomptarget/test/lit.cfg
+++ openmp/libomptarget/test/lit.cfg
@@ -89,9 +89,10 @@
 config.test_flags += " -Wl,-rpath," + config.omp_host_rtl_directory
 if config.cuda_libdir:
 config.test_flags += " -Wl,-rpath," + config.cuda_libdir
-append_dynamic_library_path('LIBRARY_PATH', config.library_dir, ":")
-append_dynamic_library_path('LIBRARY_PATH', \
-config.omp_host_rtl_directory, ":")
+if config.libomptarget_current_target.startswith('amdgcn'):
+config.test_flags += " --libomptarget-amdgcn-bc-path=" + config.library_dir
+if config.libomptarget_current_target.startswith('nvptx'):
+config.test_flags += " --libomptarget-nvptx-bc-path=" + config.library_dir
 
 # substitutions
 # - for targets that exist in the system create the actual command.
Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -149,27 +149,40 @@
 /// ###
 
 /// Check that the runtime bitcode library is part of the compile line. Create a bogus
-/// bitcode library and add it to the LIBRARY_PATH.
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
-// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHK-BCLIB %s
-/// Check with the new runtime enabled
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+/// bitcode library and specify it with libomptarget-nvptx-bc-path
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-nvptx-test.bc \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
 // RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime -save-temps -no-canonical-prefixes %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHK-BCLIB-NEW %s
-/// The user can override default detection using --libomptarget-nvptx-bc-path=.
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB %s
+
+/// Specify the directory containing the bitcode lib, check clang picks the right one
 // RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-nvptx-test.bc \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
 // RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHK-BCLIB-USER %s
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-DIR %s
 
-// CHK-BCLIB: clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-sm_35.bc
-// CHK-BCLIB-NEW: clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-new-nvptx-sm_35.bc
-// CHK-BCLIB-USER: clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-test.bc
+/// Check with the new runtime enabled
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-new-nvptx-test.bc \
+// RUN:   -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-NEW %s
 
+/// Check with new runtime and specifying the directory
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget -save-temps \
+// RUN:   -no-canonical-prefixes %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-NEW-DIR %s
+
+// CHK-BCLIB: clang{{.*}}-trip

[PATCH] D109460: [clang][Darwin] Try to guess the SDK root with xcrun when unspecified

[Louis Dionne via Phabricator via cfe-commits]

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

On Apple platforms, the base system does not contain headers (e.g. in 
/usr/include).
As a result, one needs to point Clang to those headers manually when running it,
which can be cumbersome. Instead, if the SDK root can't be inferred with the
usual logic (using the SDKROOT env var), try to guess it by running 'xcrun'.

This should provide a default that's sane most of the time when running clang
without impeding the ability for users to select the SDK of their choice with
the usual means.

http://llvm.org/PR45880


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109460

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/darwin-sdkroot.c

Index: clang/test/Driver/darwin-sdkroot.c
===
--- clang/test/Driver/darwin-sdkroot.c
+++ clang/test/Driver/darwin-sdkroot.c
@@ -1,4 +1,5 @@
-// Check that SDKROOT is used to define the default for -isysroot on Darwin.
+// Check that SDKROOT is used to define the default for -isysroot on Darwin,
+// or that we call `xcrun --show-sdk-path` if SDKROOT is not in the environment.
 //
 // RUN: rm -rf %t.tmpdir
 // RUN: mkdir -p %t.tmpdir
@@ -39,6 +40,16 @@
 //
 // This test do pass using GnuWin32 env.exe.
 
+// Check that we default to running `xcrun --show-sdk-path` if there is no
+// SDKROOT defined in the environment.
+//
+// RUN: env -i %clang -target x86_64-apple-darwin -c %s -### 2> %t.log
+// RUN: FileCheck --check-prefix=CHECK-XCRUN < %t.log %s
+//
+// CHECK-XCRUN: clang
+// CHECK-XCRUN: "-cc1"
+// CHECK-XCRUN: "-isysroot" "TODO"
+
 // Check if clang set the correct deployment target from -sysroot
 //
 // RUN: rm -rf %t/SDKs/iPhoneOS8.0.0.sdk
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -18,15 +18,22 @@
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/Options.h"
 #include "clang/Driver/SanitizerArgs.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/Optional.h"
+#include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/ProfileData/InstrProf.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/FileUtilities.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include "llvm/Support/TargetParser.h"
 #include "llvm/Support/Threading.h"
 #include "llvm/Support/VirtualFileSystem.h"
 #include  // ::getenv
+#include  // std::unique_ptr
 
 using namespace clang::driver;
 using namespace clang::driver::tools;
@@ -1885,21 +1892,54 @@
 void Darwin::AddDeploymentTarget(DerivedArgList &Args) const {
   const OptTable &Opts = getDriver().getOpts();
 
-  // Support allowing the SDKROOT environment variable used by xcrun and other
-  // Xcode tools to define the default sysroot, by making it the default for
-  // isysroot.
+  // On Apple platforms, C and C++ Standard Library headers are not provided
+  // with the base system. Instead, they are provided in various SDKs for the
+  // different Apple platforms. Clang needs to know where that SDK lives, and
+  // there are a couple ways this can be achieved:
+  //
+  // (1) If `-isysroot ` is passed explicitly, use that.
   if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
 // Warn if the path does not exist.
 if (!getVFS().exists(A->getValue()))
   getDriver().Diag(clang::diag::warn_missing_sysroot) << A->getValue();
-  } else {
-if (char *env = ::getenv("SDKROOT")) {
-  // We only use this value as the default if it is an absolute path,
-  // exists, and it is not the root path.
-  if (llvm::sys::path::is_absolute(env) && getVFS().exists(env) &&
-  StringRef(env) != "/") {
-Args.append(Args.MakeSeparateArg(
-nullptr, Opts.getOption(options::OPT_isysroot), env));
+  }
+
+  // (2) If the SDKROOT environment variable is defined and points to a valid
+  // path, use that. $SDKROOT is set by `xcrun` and other Xcode tools, so
+  // running `xcrun clang` will work by going through this path.
+  else if (char *env = ::getenv("SDKROOT")) {
+// We only use this value as the default if it is an absolute path,
+// exists, and it is not the root path.
+if (llvm::sys::path::is_absolute(env) && getVFS().exists(env) &&
+StringRef(env) != "/") {
+  Args.append(Args.MakeSeparateArg(
+  nullptr, Opts.getOption(options::OPT_isysroot), env));
+}
+  }
+
+  // (3) Otherwise, we try to guess the path of the default SDK by running
+  // `xcrun --show-sdk-path`. This won't always be correct, but if the
+  //  user wants to use the non-default SDK, they should spe

[PATCH] D91944: OpenMP 5.0 metadirective

[Chi Chun Chen via Phabricator via cfe-commits]

cchen added a comment.

@alokmishra.besu do you mind if I push the patch for solving those assertions 
with rebase? The patch does not change the logic in your program and I've made 
sure that the tests could pass in debug mode.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91944

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

[PATCH] D109460: [clang][Darwin] Try to guess the SDK root with xcrun when unspecified

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.
Herald added a subscriber: ormris.

@arphaman This is a WIP patch -- I'm trying to see whether this idea is good or 
just bad from the start.

To summarize, people have been complaining (e.g. here 
) that Clang on Darwin doesn't 
work out of the box, because we don't ship headers in `/usr/include`. This is 
an attempt to provide a sane default by running `xcrun --show-sdk-path` from 
within Clang when no SDK root can be found otherwise.

I was pretty sure this was a good idea until I implemented it and then noticed 
the tests failing. Previously, when no SDK can be found (which is the case in 
most Clang tests since we don't run with `xcrun`), we would use whatever 
deployment target Clang defaults to. After this patch, however, we'll often 
find a SDK even though none is specified, and that will have the effect of 
setting a different deployment target than the one we expect in those tests. Do 
you think that is just a sign that this whole idea of trying to infer the SDK 
using `xcrun` is broken from the start, or those tests should simply be fixed?

I guess another option would be that if the target is specified, we try to 
infer the SDK path using `xcrun --sdk  
--show-sdk-path`. That's starting to be complex, but it might solve some of 
these issues.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109460

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

[PATCH] D101400: [Driver] Add -print-multiarch-triple

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

This includes the version number, at least for FreeBSD, in its output, which 
doesn't make a huge deal of sense to me. This then breaks the build of Python 
because it generates a module with a name like 
`_sysconfigdata__freebsd14_x86_64-unknown-freebsd14.0.py`, and when it comes to 
import that as `_sysconfigdata__freebsd14_x86_64-unknown-freebsd14.0` which 
breaks because that gets parsed as something like "import 0 from 
_sysconfigdata__freebsd14_x86_64-unknown-freebsd14". Of course, the Python code 
is bad here, it shouldn't be failing like that, but given the use case for 
--print-multiarch it seems to me that the version number shouldn't be included? 
Does GCC take a stance on this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101400

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

[PATCH] D101400: [Driver] Add -print-multiarch-triple

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

Answering the last part myself: GCC only has MULTIARCH_DIRNAME definitions for 
various linux-gnu*, linux-musl, linux-uclibc, kfreebsd-gnu and -gnu (as an OS, 
for GNU/Hurd) targets, everything else prints a blank string here. So either we 
need to decide what the right behaviour is for other OSes, or we should 
similarly leave it as undefined for non-GNUish (including musl and uclibc) 
targets?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101400

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

[PATCH] D109387: [AIX] Check for typedef properly when getting preferred type align

[John McCall via Phabricator via cfe-commits]

rjmccall accepted this revision.
rjmccall added a comment.

Thanks, LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109387

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

[clang] 806ff3c - [AIX] Check for typedef properly when getting preferred type align

[Steven Wan via cfe-commits]

Author: Steven Wan
Date: 2021-09-08T16:21:52-04:00
New Revision: 806ff3c4a42c7393a0bbeab3dd1c0295f61ad457

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

LOG: [AIX] Check for typedef properly when getting preferred type align

The current check for typedef is naive and doesn't deal with any convoluted 
cases. This patch makes use of the new 'AlignRequirement' enum field from 
'TypeInfo' to determine whether or not this is an 'aligned' attribute on a 
typedef.

Reviewed By: rjmccall

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

Added: 


Modified: 
clang/lib/AST/ASTContext.cpp
clang/test/Layout/aix-power-alignment-typedef-2.cpp

Removed: 




diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index dc19dd6959049..74af9f869d084 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -2497,8 +2497,10 @@ unsigned ASTContext::getPreferredTypeAlign(const Type 
*T) const {
 const RecordDecl *RD = RT->getDecl();
 
 // When used as part of a typedef, or together with a 'packed' attribute,
-// the 'aligned' attribute can be used to decrease alignment.
-if ((TI.isAlignRequired() && T->getAs() != nullptr) ||
+// the 'aligned' attribute can be used to decrease alignment. Note that the
+// 'packed' case is already taken into consideration when computing the
+// alignment, we only need to handle the typedef case here.
+if (TI.AlignRequirement == AlignRequirementKind::RequiredByTypedef ||
 RD->isInvalidDecl())
   return ABIAlign;
 

diff  --git a/clang/test/Layout/aix-power-alignment-typedef-2.cpp 
b/clang/test/Layout/aix-power-alignment-typedef-2.cpp
index 8e7e3db47c602..b814be9c06cff 100644
--- a/clang/test/Layout/aix-power-alignment-typedef-2.cpp
+++ b/clang/test/Layout/aix-power-alignment-typedef-2.cpp
@@ -4,12 +4,26 @@
 // RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -S -emit-llvm -x c++ < %s | 
\
 // RUN:   FileCheck %s
 
-struct C {
+namespace test1 {
+struct S {
   double x;
 };
 
-typedef struct C __attribute__((__aligned__(2))) CC;
+typedef struct S __attribute__((__aligned__(2))) SS;
 
-CC cc;
+SS ss;
 
-// CHECK: @cc = global %struct.C zeroinitializer, align 2
+// CHECK: @{{.*}}test1{{.*}}ss{{.*}} = global %"struct.test1::S" 
zeroinitializer, align 2
+} // namespace test1
+
+namespace test2 {
+struct __attribute__((__aligned__(2))) S {
+  double x;
+};
+
+typedef struct S SS;
+
+SS ss;
+
+// CHECK: @{{.*}}test2{{.*}}ss{{.*}} = global %"struct.test2::S" 
zeroinitializer, align 8
+} // namespace test2



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

[PATCH] D109387: [AIX] Check for typedef properly when getting preferred type align

[Steven Wan 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 rG806ff3c4a42c: [AIX] Check for typedef properly when getting 
preferred type align (authored by stevewan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109387

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/Layout/aix-power-alignment-typedef-2.cpp


Index: clang/test/Layout/aix-power-alignment-typedef-2.cpp
===
--- clang/test/Layout/aix-power-alignment-typedef-2.cpp
+++ clang/test/Layout/aix-power-alignment-typedef-2.cpp
@@ -4,12 +4,26 @@
 // RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -S -emit-llvm -x c++ < %s | 
\
 // RUN:   FileCheck %s
 
-struct C {
+namespace test1 {
+struct S {
   double x;
 };
 
-typedef struct C __attribute__((__aligned__(2))) CC;
+typedef struct S __attribute__((__aligned__(2))) SS;
 
-CC cc;
+SS ss;
 
-// CHECK: @cc = global %struct.C zeroinitializer, align 2
+// CHECK: @{{.*}}test1{{.*}}ss{{.*}} = global %"struct.test1::S" 
zeroinitializer, align 2
+} // namespace test1
+
+namespace test2 {
+struct __attribute__((__aligned__(2))) S {
+  double x;
+};
+
+typedef struct S SS;
+
+SS ss;
+
+// CHECK: @{{.*}}test2{{.*}}ss{{.*}} = global %"struct.test2::S" 
zeroinitializer, align 8
+} // namespace test2
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -2497,8 +2497,10 @@
 const RecordDecl *RD = RT->getDecl();
 
 // When used as part of a typedef, or together with a 'packed' attribute,
-// the 'aligned' attribute can be used to decrease alignment.
-if ((TI.isAlignRequired() && T->getAs() != nullptr) ||
+// the 'aligned' attribute can be used to decrease alignment. Note that the
+// 'packed' case is already taken into consideration when computing the
+// alignment, we only need to handle the typedef case here.
+if (TI.AlignRequirement == AlignRequirementKind::RequiredByTypedef ||
 RD->isInvalidDecl())
   return ABIAlign;
 


Index: clang/test/Layout/aix-power-alignment-typedef-2.cpp
===
--- clang/test/Layout/aix-power-alignment-typedef-2.cpp
+++ clang/test/Layout/aix-power-alignment-typedef-2.cpp
@@ -4,12 +4,26 @@
 // RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -S -emit-llvm -x c++ < %s | \
 // RUN:   FileCheck %s
 
-struct C {
+namespace test1 {
+struct S {
   double x;
 };
 
-typedef struct C __attribute__((__aligned__(2))) CC;
+typedef struct S __attribute__((__aligned__(2))) SS;
 
-CC cc;
+SS ss;
 
-// CHECK: @cc = global %struct.C zeroinitializer, align 2
+// CHECK: @{{.*}}test1{{.*}}ss{{.*}} = global %"struct.test1::S" zeroinitializer, align 2
+} // namespace test1
+
+namespace test2 {
+struct __attribute__((__aligned__(2))) S {
+  double x;
+};
+
+typedef struct S SS;
+
+SS ss;
+
+// CHECK: @{{.*}}test2{{.*}}ss{{.*}} = global %"struct.test2::S" zeroinitializer, align 8
+} // namespace test2
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -2497,8 +2497,10 @@
 const RecordDecl *RD = RT->getDecl();
 
 // When used as part of a typedef, or together with a 'packed' attribute,
-// the 'aligned' attribute can be used to decrease alignment.
-if ((TI.isAlignRequired() && T->getAs() != nullptr) ||
+// the 'aligned' attribute can be used to decrease alignment. Note that the
+// 'packed' case is already taken into consideration when computing the
+// alignment, we only need to handle the typedef case here.
+if (TI.AlignRequirement == AlignRequirementKind::RequiredByTypedef ||
 RD->isInvalidDecl())
   return ABIAlign;
 
___
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

[Keith Smiley via Phabricator via cfe-commits]

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

This uses darwin's default libtool since llvm-ar isn't normally
available.


Repository:
  rG LLVM Github Monorepo

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 &TC)
+  : MachOTool("darwin::StaticLibTool", "static-lib-linker", TC) {}
+
+  bool hasIntegratedCPP() const override { return false; }
+  bool isLinkJob() const override { return true; }
+
+  void ConstructJob(Compilation &C, const JobAction &JA,
+const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::opt::ArgList &TCArgs,
+const char *LinkingOutput) const override;
+};
+
 class LLVM_LIBRARY_VISIBILITY Lipo : public MachOTool {
 public:
   Lipo(const ToolChain &TC) : 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,53 @@
   C.addCommand(std::move(Cmd));
 }
 
+void darwin::StaticLibTool::ConstructJob(
+Compilation &C, const JobAction &JA, const InputInfo &Output,
+const InputInfoList &Inputs, const ArgList &Args,
+const char *LinkingOutput) const {
+  const Driver &D = 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);
+
+  // ar tool command "llvm-ar   ".
+  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 &II : 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,
+ ResponseFileSupport::AtFileUTF8(),
+

[clang] 41c7367 - [openmp] Re-enable test from D109057, now with windows path aware regex

[Jon Chesterfield via cfe-commits]

Author: Jon Chesterfield
Date: 2021-09-08T21:57:38+01:00
New Revision: 41c73671d0b851c601ceb85c7e38afa21819bde7

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

LOG: [openmp] Re-enable test from D109057, now with windows path aware regex

Added: 


Modified: 
clang/test/Driver/openmp-offload-gpu.c

Removed: 




diff  --git a/clang/test/Driver/openmp-offload-gpu.c 
b/clang/test/Driver/openmp-offload-gpu.c
index d4e1757162771..1c7316851d153 100644
--- a/clang/test/Driver/openmp-offload-gpu.c
+++ b/clang/test/Driver/openmp-offload-gpu.c
@@ -165,11 +165,17 @@
 // RUN:   -Xopenmp-target -march=sm_35 
--cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
 // RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 
2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-BCLIB-USER %s
+/// The user can also pass the path to the directory containing the bitcode lib
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget \
+// RUN:   -Xopenmp-target -march=sm_35 
--cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
+// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 
2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-USER-DIR %s
 
 // CHK-BCLIB: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-sm_35.bc
 // CHK-BCLIB-NEW: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-new-nvptx-sm_35.bc
 // CHK-BCLIB-USER: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-test.bc
-
+// CHK-BCLIB-USER-DIR: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget{{.}}libomptarget-nvptx-sm_35.bc
 // CHK-BCLIB-NOT: {{error:|warning:}}
 
 /// ###



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

[clang] e62f4f1 - [openmp] 41c73671d0, this time with staged patch applied

[Jon Chesterfield via cfe-commits]

Author: Jon Chesterfield
Date: 2021-09-08T22:07:47+01:00
New Revision: e62f4f172e34b9283ce04c871512165c78ef5f39

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

LOG: [openmp] 41c73671d0, this time with staged patch applied

Added: 


Modified: 
clang/test/Driver/openmp-offload-gpu.c

Removed: 




diff  --git a/clang/test/Driver/openmp-offload-gpu.c 
b/clang/test/Driver/openmp-offload-gpu.c
index 1c7316851d15..d3e8274012ae 100644
--- a/clang/test/Driver/openmp-offload-gpu.c
+++ b/clang/test/Driver/openmp-offload-gpu.c
@@ -175,7 +175,7 @@
 // CHK-BCLIB: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-sm_35.bc
 // CHK-BCLIB-NEW: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-new-nvptx-sm_35.bc
 // CHK-BCLIB-USER: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-test.bc
-// CHK-BCLIB-USER-DIR: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget{{.}}libomptarget-nvptx-sm_35.bc
+// CHK-BCLIB-USER-DIR: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget{{/|}}libomptarget-nvptx-sm_35.bc
 // CHK-BCLIB-NOT: {{error:|warning:}}
 
 /// ###



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

[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield updated this revision to Diff 371450.
JonChesterfield added a comment.

- Use regex for windows path compat


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/Inputs/libomptarget/libomptarget-new-nvptx-test.bc
  clang/test/Driver/amdgpu-openmp-toolchain.c
  clang/test/Driver/openmp-offload-gpu.c
  openmp/libomptarget/test/lit.cfg

Index: openmp/libomptarget/test/lit.cfg
===
--- openmp/libomptarget/test/lit.cfg
+++ openmp/libomptarget/test/lit.cfg
@@ -89,9 +89,10 @@
 config.test_flags += " -Wl,-rpath," + config.omp_host_rtl_directory
 if config.cuda_libdir:
 config.test_flags += " -Wl,-rpath," + config.cuda_libdir
-append_dynamic_library_path('LIBRARY_PATH', config.library_dir, ":")
-append_dynamic_library_path('LIBRARY_PATH', \
-config.omp_host_rtl_directory, ":")
+if config.libomptarget_current_target.startswith('amdgcn'):
+config.test_flags += " --libomptarget-amdgcn-bc-path=" + config.library_dir
+if config.libomptarget_current_target.startswith('nvptx'):
+config.test_flags += " --libomptarget-nvptx-bc-path=" + config.library_dir
 
 # substitutions
 # - for targets that exist in the system create the actual command.
Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -149,27 +149,40 @@
 /// ###
 
 /// Check that the runtime bitcode library is part of the compile line. Create a bogus
-/// bitcode library and add it to the LIBRARY_PATH.
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
-// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHK-BCLIB %s
-/// Check with the new runtime enabled
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+/// bitcode library and specify it with libomptarget-nvptx-bc-path
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-nvptx-test.bc \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
 // RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime -save-temps -no-canonical-prefixes %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHK-BCLIB-NEW %s
-/// The user can override default detection using --libomptarget-nvptx-bc-path=.
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB %s
+
+/// Specify the directory containing the bitcode lib, check clang picks the right one
 // RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-nvptx-test.bc \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
 // RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHK-BCLIB-USER %s
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-DIR %s
 
-// CHK-BCLIB: clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-sm_35.bc
-// CHK-BCLIB-NEW: clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-new-nvptx-sm_35.bc
-// CHK-BCLIB-USER: clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-test.bc
+/// Check with the new runtime enabled
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-new-nvptx-test.bc \
+// RUN:   -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-NEW %s
 
+/// Check with new runtime and specifying the directory
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget -save-temps \
+// RUN:   -no-canonical-prefixes %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-NEW-DIR %s
+
+// CHK-BCLIB: clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{

[PATCH] D109467: [analyzer] check for std::__addressof for inner pointer checker

[Ali Shuja Siddiqui via Phabricator via cfe-commits]

alishuja created this revision.
alishuja added reviewers: NoQ, steakhal, xazax.hun, ASDenysPetrov.
Herald added subscribers: manas, martong, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware.
alishuja requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is an extension to diff D99260 . This 
adds an additional exception for std::__addressof in InnerPointerChecker.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109467

Files:
  clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp


Index: clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
@@ -34,9 +34,9 @@
 class InnerPointerChecker
 : public Checker {

-  CallDescription AppendFn, AssignFn, AddressofFn, ClearFn, CStrFn, DataFn,
-  DataMemberFn, EraseFn, InsertFn, PopBackFn, PushBackFn, ReplaceFn,
-  ReserveFn, ResizeFn, ShrinkToFitFn, SwapFn;
+  CallDescription AppendFn, AssignFn, AddressofFn, AddressofFn_, ClearFn,
+  CStrFn, DataFn, DataMemberFn, EraseFn, InsertFn, PopBackFn, PushBackFn,
+  ReplaceFn, ReserveFn, ResizeFn, ShrinkToFitFn, SwapFn;

 public:
   class InnerPointerBRVisitor : public BugReporterVisitor {
@@ -73,7 +73,7 @@
   InnerPointerChecker()
   : AppendFn({"std", "basic_string", "append"}),
 AssignFn({"std", "basic_string", "assign"}),
-AddressofFn({"std", "addressof"}),
+AddressofFn({"std", "addressof"}), AddressofFn_({"std", 
"__addressof"}),
 ClearFn({"std", "basic_string", "clear"}),
 CStrFn({"std", "basic_string", "c_str"}), DataFn({"std", "data"}, 1),
 DataMemberFn({"std", "basic_string", "data"}),
@@ -184,7 +184,7 @@

   // std::addressof function accepts a non-const reference as an argument,
   // but doesn't modify it.
-  if (Call.isCalled(AddressofFn))
+  if (Call.isCalled(AddressofFn) || Call.isCalled(AddressofFn_))
 continue;

   markPtrSymbolsReleased(Call, State, ArgRegion, C);


Index: clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
@@ -34,9 +34,9 @@
 class InnerPointerChecker
 : public Checker {

-  CallDescription AppendFn, AssignFn, AddressofFn, ClearFn, CStrFn, DataFn,
-  DataMemberFn, EraseFn, InsertFn, PopBackFn, PushBackFn, ReplaceFn,
-  ReserveFn, ResizeFn, ShrinkToFitFn, SwapFn;
+  CallDescription AppendFn, AssignFn, AddressofFn, AddressofFn_, ClearFn,
+  CStrFn, DataFn, DataMemberFn, EraseFn, InsertFn, PopBackFn, PushBackFn,
+  ReplaceFn, ReserveFn, ResizeFn, ShrinkToFitFn, SwapFn;

 public:
   class InnerPointerBRVisitor : public BugReporterVisitor {
@@ -73,7 +73,7 @@
   InnerPointerChecker()
   : AppendFn({"std", "basic_string", "append"}),
 AssignFn({"std", "basic_string", "assign"}),
-AddressofFn({"std", "addressof"}),
+AddressofFn({"std", "addressof"}), AddressofFn_({"std", "__addressof"}),
 ClearFn({"std", "basic_string", "clear"}),
 CStrFn({"std", "basic_string", "c_str"}), DataFn({"std", "data"}, 1),
 DataMemberFn({"std", "basic_string", "data"}),
@@ -184,7 +184,7 @@

   // std::addressof function accepts a non-const reference as an argument,
   // but doesn't modify it.
-  if (Call.isCalled(AddressofFn))
+  if (Call.isCalled(AddressofFn) || Call.isCalled(AddressofFn_))
 continue;

   markPtrSymbolsReleased(Call, State, ArgRegion, C);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109386: Fix use-after-free from GlobalCtors associated data

[Lei Wang via Phabricator via cfe-commits]

wlei updated this revision to Diff 371455.
wlei added a comment.

change to use ValueHandle for associated data


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109386

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h


Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -294,7 +294,7 @@
   AssociatedData(AssociatedData) {}
 int Priority;
 llvm::Constant *Initializer;
-llvm::Constant *AssociatedData;
+llvm::WeakTrackingVH AssociatedData;
   };
 
   typedef std::vector CtorList;
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1463,7 +1463,8 @@
 ctor.addInt(Int32Ty, I.Priority);
 ctor.add(llvm::ConstantExpr::getBitCast(I.Initializer, CtorPFTy));
 if (I.AssociatedData)
-  ctor.add(llvm::ConstantExpr::getBitCast(I.AssociatedData, VoidPtrTy));
+  ctor.add(llvm::ConstantExpr::getBitCast(
+  cast(I.AssociatedData), VoidPtrTy));
 else
   ctor.addNullPointer(VoidPtrTy);
 ctor.finishAndAddTo(ctors);


Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -294,7 +294,7 @@
   AssociatedData(AssociatedData) {}
 int Priority;
 llvm::Constant *Initializer;
-llvm::Constant *AssociatedData;
+llvm::WeakTrackingVH AssociatedData;
   };
 
   typedef std::vector CtorList;
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1463,7 +1463,8 @@
 ctor.addInt(Int32Ty, I.Priority);
 ctor.add(llvm::ConstantExpr::getBitCast(I.Initializer, CtorPFTy));
 if (I.AssociatedData)
-  ctor.add(llvm::ConstantExpr::getBitCast(I.AssociatedData, VoidPtrTy));
+  ctor.add(llvm::ConstantExpr::getBitCast(
+  cast(I.AssociatedData), VoidPtrTy));
 else
   ctor.addNullPointer(VoidPtrTy);
 ctor.finishAndAddTo(ctors);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109386: Fix use-after-free from GlobalCtors associated data

[Lei Wang via Phabricator via cfe-commits]

wlei added a comment.

@rnk @rjmccall Thanks for the suggestion! @wenlei Thanks for the helpful 
example!

Changed to use ValueHandle(WeakTrackingVH) for this, please see if this looks 
good to you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109386

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

[PATCH] D109411: [clang] Enable the special enable_if_t diagnostics for libc++'s __enable_if_t as well.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Looks like most of the testing for the enable_if custom dialog was added in 
`clang/test/SemaTemplate/overload-candidates.cpp` in 
rG6f8d2c6c9c3451effdf075a7034bbe77045bfeba 
. 
(improved in rG00fa10b43f25d98e88cc81b653dfe8d49327722d 
 - though 
no substantially novel test coverage added, just updating the improved 
diagnostic text) - maybe pull that test coverage over into this new dedicated 
test file? But no big deal.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109411

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

[PATCH] D105756: [clang] C++98 implicit moves are back with a vengeance

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

In D105756#2988022 , @NoQ wrote:

> I don't think this is intended. @mizvekov, do you think you can add more hard 
> checks to make sure it's constrained to C++? (Or maybe there's another, more 
> precise solution?)

Hello! Thanks for reporting this.

The double implicit lvalue-to-rvalue cast is an unfortunate consequence of some 
technical debt around the different ways we handle the implicit return type on 
blocks.
But I don't think it's incorrect as in it actually producing program with 
different semantics.
Does it actually affect you in your use cases besides the AST? Is this 
important to you for external semantic analysis reasons or something?

Removing the xvalue cast on non CplusPlus is simple, the bigger issue here is 
why we are doing this, specially as it will affect what test cases we create 
for this change.
If this is an issue, is it serious enough to consider getting the fix into 
13.0.0 at this stage?

The nrvo is a separate thing, and again I thin it's harmless, or at least a 
little beneficial. With it, you are avoiding an extra copy when returning these 
values, and it comes straight from the frontend, independent of any 
optimization passes later.
Why is this undesirable?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105756

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

[PATCH] D109386: Change to use ValueHandle for associated data of GlobalCtors

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

This seems incorrect: a weak VH won't have the same semantics, it will just 
drop the comdat associativity when the underlying global changes type. BTW, can 
this be tested, or is this only possible when clang is being used as a library, 
perhaps as in swift?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109386

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

[PATCH] D109470: Add "profiling" to the list of absl libraries.

[Nilay Vaish via Phabricator via cfe-commits]

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109470

Files:
  clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h


Index: clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
===
--- clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
+++ clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
@@ -47,15 +47,11 @@
   if (PrefixPosition == StringRef::npos)
 return false;
   Path = Path.drop_front(PrefixPosition + AbslPrefix.size());
-  static const char *AbseilLibraries[] = {"algorithm", "base",
-  "container", "debugging",
-  "flags", "hash",
-  "iterator",  "memory",
-  "meta",  "numeric",
-  "random","status",
-  "strings",   "synchronization",
-  "time",  "types",
-  "utility"};
+  static const char *AbseilLibraries[] = {
+  "algorithm", "base", "container", "debugging", "flags",
+  "hash",  "iterator", "memory","meta",  "numeric",
+  "profiling", "random",   "status","strings",   "synchronization",
+  "time",  "types","utility"};
   return llvm::any_of(AbseilLibraries, [&](const char *Library) {
 return Path.startswith(Library);
   });


Index: clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
===
--- clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
+++ clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
@@ -47,15 +47,11 @@
   if (PrefixPosition == StringRef::npos)
 return false;
   Path = Path.drop_front(PrefixPosition + AbslPrefix.size());
-  static const char *AbseilLibraries[] = {"algorithm", "base",
-  "container", "debugging",
-  "flags", "hash",
-  "iterator",  "memory",
-  "meta",  "numeric",
-  "random","status",
-  "strings",   "synchronization",
-  "time",  "types",
-  "utility"};
+  static const char *AbseilLibraries[] = {
+  "algorithm", "base", "container", "debugging", "flags",
+  "hash",  "iterator", "memory","meta",  "numeric",
+  "profiling", "random",   "status","strings",   "synchronization",
+  "time",  "types","utility"};
   return llvm::any_of(AbseilLibraries, [&](const char *Library) {
 return Path.startswith(Library);
   });
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108753: [analyzer] MallocChecker: Add notes from NoOwnershipChangeVisitor only when a function "intents", but doesn't change ownership, enable by default

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

In D108753#2988632 , @NoQ wrote:

> This looks good!
>
> I guess one way to make this //even more// conservative would be to match the 
> variable inside the delete-expression to the one we expect to get deallocated.

Yeah, I thought about that, but one counter argument to that is that once an 
intent to do some deallocation is already there, its possible that the wrong 
variable was deleted, or the deallocation wasn't thorough enough.

Thanks for the reviews!


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

https://reviews.llvm.org/D108753

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

[clang] d2d2e5e - [clang][Driver] Update/cleanup LTO logic to ensure that the last lto argument is honored

[Usman Nadeem via cfe-commits]

Author: Usman Nadeem
Date: 2021-09-08T15:40:32-07:00
New Revision: d2d2e5ea480feb09dc0edeac2eb14310de74b372

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

LOG: [clang][Driver] Update/cleanup LTO logic to ensure that the last lto 
argument is honored

- Make flto an alias of flto=full.
- Make foffload-lto an alias of foffload-lto=full.
- Make flto_EQ_jobserver, flto_EQ_auto aliases of flto=full,
  since they are being treated as full lto right now.
- Clean up the code for parseLTOMode and setLTOMode.
- Replace uses of OPT_flto with OPT_flto_EQ since they alias now.

Change-Id: Iea5338c20cb800b43529b20745e92600e2cfd2b1

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/Driver/amdgpu-toolchain.c
clang/test/Driver/lto.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 0b374fa4db410..8ab3a5156e075 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2017,16 +2017,18 @@ def fapple_link_rtlib : Flag<["-"], 
"fapple-link-rtlib">, Group,
   HelpText<"Force linking the clang builtins runtime library">;
 def flto_EQ : Joined<["-"], "flto=">, Flags<[CoreOption, CC1Option]>, 
Group,
   HelpText<"Set LTO mode to either 'full' or 'thin'">, Values<"thin,full">;
-def flto_EQ_jobserver : Flag<["-"], "flto=jobserver">, Group;
-def flto_EQ_auto : Flag<["-"], "flto=auto">, Group;
+def flto_EQ_jobserver : Flag<["-"], "flto=jobserver">, Group,
+  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' mode">;
+def flto_EQ_auto : Flag<["-"], "flto=auto">, Group,
+  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' mode">;
 def flto : Flag<["-"], "flto">, Flags<[CoreOption, CC1Option]>, Group,
-  HelpText<"Enable LTO in 'full' mode">;
+  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' mode">;
 def fno_lto : Flag<["-"], "fno-lto">, Flags<[CoreOption, CC1Option]>, 
Group,
   HelpText<"Disable LTO mode (default)">;
 def foffload_lto_EQ : Joined<["-"], "foffload-lto=">, Flags<[CoreOption]>, 
Group,
   HelpText<"Set LTO mode to either 'full' or 'thin' for offload compilation">, 
Values<"thin,full">;
 def foffload_lto : Flag<["-"], "foffload-lto">, Flags<[CoreOption]>, 
Group,
-  HelpText<"Enable LTO in 'full' mode for offload compilation">;
+  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' 
mode for offload compilation">;
 def fno_offload_lto : Flag<["-"], "fno-offload-lto">, Flags<[CoreOption]>, 
Group,
   HelpText<"Disable LTO mode (default) for offload compilation">;
 def flto_jobs_EQ : Joined<["-"], "flto-jobs=">,

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index a92b6e8c0908b..7dea484267dcd 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -585,53 +585,34 @@ static llvm::Triple computeTargetTriple(const Driver &D,
 // Parse the LTO options and record the type of LTO compilation
 // based on which -f(no-)?lto(=.*)? or -f(no-)?offload-lto(=.*)?
 // option occurs last.
-static llvm::Optional
-parseLTOMode(Driver &D, const llvm::opt::ArgList &Args, OptSpecifier OptPos,
- OptSpecifier OptNeg, OptSpecifier OptEq, bool IsOffload) {
-  driver::LTOKind LTOMode = LTOK_None;
-  // Non-offload LTO allows -flto=auto and -flto=jobserver. Offload LTO does
-  // not support those options.
-  if (!Args.hasFlag(OptPos, OptEq, OptNeg, false) &&
-  (IsOffload ||
-   (!Args.hasFlag(options::OPT_flto_EQ_auto, options::OPT_fno_lto, false) 
&&
-!Args.hasFlag(options::OPT_flto_EQ_jobserver, options::OPT_fno_lto,
-  false
-return None;
-
-  StringRef LTOName("full");
+static driver::LTOKind parseLTOMode(Driver &D, const llvm::opt::ArgList &Args,
+OptSpecifier OptEq, OptSpecifier OptNeg) {
+  if (!Args.hasFlag(OptEq, OptNeg, false))
+return LTOK_None;
 
   const Arg *A = Args.getLastArg(OptEq);
-  if (A)
-LTOName = A->getValue();
+  StringRef LTOName = A->getValue();
 
-  LTOMode = llvm::StringSwitch(LTOName)
-.Case("full", LTOK_Full)
-.Case("thin", LTOK_Thin)
-.Default(LTOK_Unknown);
+  driver::LTOKind LTOMode = llvm::StringSwitch(LTOName)
+.Case("full", LTOK_Full)
+.Case("thin", LTOK_Thin)
+.Default(LTOK_Unknown);
 
   if (LTOMode == LTOK_Unknown) {
-assert(A);
 D.Diag(diag::err_drv_unsupported_option_argument)
 << A->getOption().getName() << A->getValue();
-return None;
+return LTOK_None;
   }
   return LTOMode;
 }

[clang] 54612a0 - Revert "[clang][Driver] Update/cleanup LTO logic to ensure that the last lto argument is honored"

[Usman Nadeem via cfe-commits]

Author: Usman Nadeem
Date: 2021-09-08T15:49:35-07:00
New Revision: 54612a037aff42150e4c605e90a530fe1cc34c64

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

LOG: Revert "[clang][Driver] Update/cleanup LTO logic to ensure that the last 
lto argument is honored"

This reverts commit d2d2e5ea480feb09dc0edeac2eb14310de74b372.

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/Driver/amdgpu-toolchain.c
clang/test/Driver/lto.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 8ab3a5156e075..0b374fa4db410 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2017,18 +2017,16 @@ def fapple_link_rtlib : Flag<["-"], 
"fapple-link-rtlib">, Group,
   HelpText<"Force linking the clang builtins runtime library">;
 def flto_EQ : Joined<["-"], "flto=">, Flags<[CoreOption, CC1Option]>, 
Group,
   HelpText<"Set LTO mode to either 'full' or 'thin'">, Values<"thin,full">;
-def flto_EQ_jobserver : Flag<["-"], "flto=jobserver">, Group,
-  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' mode">;
-def flto_EQ_auto : Flag<["-"], "flto=auto">, Group,
-  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' mode">;
+def flto_EQ_jobserver : Flag<["-"], "flto=jobserver">, Group;
+def flto_EQ_auto : Flag<["-"], "flto=auto">, Group;
 def flto : Flag<["-"], "flto">, Flags<[CoreOption, CC1Option]>, Group,
-  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' mode">;
+  HelpText<"Enable LTO in 'full' mode">;
 def fno_lto : Flag<["-"], "fno-lto">, Flags<[CoreOption, CC1Option]>, 
Group,
   HelpText<"Disable LTO mode (default)">;
 def foffload_lto_EQ : Joined<["-"], "foffload-lto=">, Flags<[CoreOption]>, 
Group,
   HelpText<"Set LTO mode to either 'full' or 'thin' for offload compilation">, 
Values<"thin,full">;
 def foffload_lto : Flag<["-"], "foffload-lto">, Flags<[CoreOption]>, 
Group,
-  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' 
mode for offload compilation">;
+  HelpText<"Enable LTO in 'full' mode for offload compilation">;
 def fno_offload_lto : Flag<["-"], "fno-offload-lto">, Flags<[CoreOption]>, 
Group,
   HelpText<"Disable LTO mode (default) for offload compilation">;
 def flto_jobs_EQ : Joined<["-"], "flto-jobs=">,

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 7dea484267dcd..a92b6e8c0908b 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -585,34 +585,53 @@ static llvm::Triple computeTargetTriple(const Driver &D,
 // Parse the LTO options and record the type of LTO compilation
 // based on which -f(no-)?lto(=.*)? or -f(no-)?offload-lto(=.*)?
 // option occurs last.
-static driver::LTOKind parseLTOMode(Driver &D, const llvm::opt::ArgList &Args,
-OptSpecifier OptEq, OptSpecifier OptNeg) {
-  if (!Args.hasFlag(OptEq, OptNeg, false))
-return LTOK_None;
+static llvm::Optional
+parseLTOMode(Driver &D, const llvm::opt::ArgList &Args, OptSpecifier OptPos,
+ OptSpecifier OptNeg, OptSpecifier OptEq, bool IsOffload) {
+  driver::LTOKind LTOMode = LTOK_None;
+  // Non-offload LTO allows -flto=auto and -flto=jobserver. Offload LTO does
+  // not support those options.
+  if (!Args.hasFlag(OptPos, OptEq, OptNeg, false) &&
+  (IsOffload ||
+   (!Args.hasFlag(options::OPT_flto_EQ_auto, options::OPT_fno_lto, false) 
&&
+!Args.hasFlag(options::OPT_flto_EQ_jobserver, options::OPT_fno_lto,
+  false
+return None;
+
+  StringRef LTOName("full");
 
   const Arg *A = Args.getLastArg(OptEq);
-  StringRef LTOName = A->getValue();
+  if (A)
+LTOName = A->getValue();
 
-  driver::LTOKind LTOMode = llvm::StringSwitch(LTOName)
-.Case("full", LTOK_Full)
-.Case("thin", LTOK_Thin)
-.Default(LTOK_Unknown);
+  LTOMode = llvm::StringSwitch(LTOName)
+.Case("full", LTOK_Full)
+.Case("thin", LTOK_Thin)
+.Default(LTOK_Unknown);
 
   if (LTOMode == LTOK_Unknown) {
+assert(A);
 D.Diag(diag::err_drv_unsupported_option_argument)
 << A->getOption().getName() << A->getValue();
-return LTOK_None;
+return None;
   }
   return LTOMode;
 }
 
 // Parse the LTO options.
 void Driver::setLTOMode(const llvm::opt::ArgList &Args) {
-  LTOMode =
-  parseLTOMode(*this, Args, options::OPT_flto_EQ, options::OPT_fno_lto);
-
-  OffloadLTOMode = parseLTOMode(*this, Args, options::OPT_foffload_lto_EQ,
-options::OPT_

[clang] 78f7ad5 - [clang][Fuchsia] Remove COMPILER_RT_CAN_EXECUTE_TESTS

[Leonard Chan via cfe-commits]

Author: Leonard Chan
Date: 2021-09-08T15:52:02-07:00
New Revision: 78f7ad5a83c3b7f37b5331486c289eba1040d56a

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

LOG: [clang][Fuchsia] Remove COMPILER_RT_CAN_EXECUTE_TESTS

I forgot that we run `check-runtimes-x86_64-unknown-linux-gnu`, which
will run all compiler-rt tests also even though we are currently not in
a state where we can run them all yet. Remove this for now to fix our CI
builders.

Added: 


Modified: 
clang/cmake/caches/Fuchsia-stage2.cmake

Removed: 




diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index 5efa3028a0c65..1fbbaf74b0ec8 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -120,7 +120,6 @@ foreach(target 
aarch64-unknown-linux-gnu;armv7-unknown-linux-gnueabihf;i386-unkn
 set(RUNTIMES_${target}_CMAKE_MODULE_LINKER_FLAGS "-fuse-ld=lld" CACHE 
STRING "")
 set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld" CACHE STRING 
"")
 set(RUNTIMES_${target}_COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "")
-set(RUNTIMES_${target}_COMPILER_RT_CAN_EXECUTE_TESTS ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "")



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

[clang] 0a9d740 - [clang][Driver] Update/cleanup LTO logic to ensure that the last lto argument is honored

[Usman Nadeem via cfe-commits]

Author: Usman Nadeem
Date: 2021-09-08T15:53:49-07:00
New Revision: 0a9d740c232e1e4b71fcbbaf844211d70b06d873

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

LOG: [clang][Driver] Update/cleanup LTO logic to ensure that the last lto 
argument is honored

- Make flto an alias of flto=full.
- Make foffload-lto an alias of foffload-lto=full.
- Make flto_EQ_jobserver, flto_EQ_auto aliases of flto=full,
  since they are being treated as full lto right now.
- Clean up the code for parseLTOMode and setLTOMode.
- Replace uses of OPT_flto with OPT_flto_EQ since they alias now.

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

Change-Id: I5d867db83a680434fba5c8d85c9a83135d3b81ee

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/Driver/amdgpu-toolchain.c
clang/test/Driver/lto.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 0b374fa4db410..8ab3a5156e075 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2017,16 +2017,18 @@ def fapple_link_rtlib : Flag<["-"], 
"fapple-link-rtlib">, Group,
   HelpText<"Force linking the clang builtins runtime library">;
 def flto_EQ : Joined<["-"], "flto=">, Flags<[CoreOption, CC1Option]>, 
Group,
   HelpText<"Set LTO mode to either 'full' or 'thin'">, Values<"thin,full">;
-def flto_EQ_jobserver : Flag<["-"], "flto=jobserver">, Group;
-def flto_EQ_auto : Flag<["-"], "flto=auto">, Group;
+def flto_EQ_jobserver : Flag<["-"], "flto=jobserver">, Group,
+  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' mode">;
+def flto_EQ_auto : Flag<["-"], "flto=auto">, Group,
+  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' mode">;
 def flto : Flag<["-"], "flto">, Flags<[CoreOption, CC1Option]>, Group,
-  HelpText<"Enable LTO in 'full' mode">;
+  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' mode">;
 def fno_lto : Flag<["-"], "fno-lto">, Flags<[CoreOption, CC1Option]>, 
Group,
   HelpText<"Disable LTO mode (default)">;
 def foffload_lto_EQ : Joined<["-"], "foffload-lto=">, Flags<[CoreOption]>, 
Group,
   HelpText<"Set LTO mode to either 'full' or 'thin' for offload compilation">, 
Values<"thin,full">;
 def foffload_lto : Flag<["-"], "foffload-lto">, Flags<[CoreOption]>, 
Group,
-  HelpText<"Enable LTO in 'full' mode for offload compilation">;
+  Alias, AliasArgs<["full"]>, HelpText<"Enable LTO in 'full' 
mode for offload compilation">;
 def fno_offload_lto : Flag<["-"], "fno-offload-lto">, Flags<[CoreOption]>, 
Group,
   HelpText<"Disable LTO mode (default) for offload compilation">;
 def flto_jobs_EQ : Joined<["-"], "flto-jobs=">,

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index a92b6e8c0908b..7dea484267dcd 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -585,53 +585,34 @@ static llvm::Triple computeTargetTriple(const Driver &D,
 // Parse the LTO options and record the type of LTO compilation
 // based on which -f(no-)?lto(=.*)? or -f(no-)?offload-lto(=.*)?
 // option occurs last.
-static llvm::Optional
-parseLTOMode(Driver &D, const llvm::opt::ArgList &Args, OptSpecifier OptPos,
- OptSpecifier OptNeg, OptSpecifier OptEq, bool IsOffload) {
-  driver::LTOKind LTOMode = LTOK_None;
-  // Non-offload LTO allows -flto=auto and -flto=jobserver. Offload LTO does
-  // not support those options.
-  if (!Args.hasFlag(OptPos, OptEq, OptNeg, false) &&
-  (IsOffload ||
-   (!Args.hasFlag(options::OPT_flto_EQ_auto, options::OPT_fno_lto, false) 
&&
-!Args.hasFlag(options::OPT_flto_EQ_jobserver, options::OPT_fno_lto,
-  false
-return None;
-
-  StringRef LTOName("full");
+static driver::LTOKind parseLTOMode(Driver &D, const llvm::opt::ArgList &Args,
+OptSpecifier OptEq, OptSpecifier OptNeg) {
+  if (!Args.hasFlag(OptEq, OptNeg, false))
+return LTOK_None;
 
   const Arg *A = Args.getLastArg(OptEq);
-  if (A)
-LTOName = A->getValue();
+  StringRef LTOName = A->getValue();
 
-  LTOMode = llvm::StringSwitch(LTOName)
-.Case("full", LTOK_Full)
-.Case("thin", LTOK_Thin)
-.Default(LTOK_Unknown);
+  driver::LTOKind LTOMode = llvm::StringSwitch(LTOName)
+.Case("full", LTOK_Full)
+.Case("thin", LTOK_Thin)
+.Default(LTOK_Unknown);
 
   if (LTOMode == LTOK_Unknown) {
-assert(A);
 D.Diag(diag::err_drv_unsupported_option_argument)
 << A->getOption().getName() << A->getValue();
-return

[PATCH] D108881: [clang][driver] Honor the last -flto(=.*)? argument

[Usman Nadeem 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 rG0a9d740c232e: [clang][Driver] Update/cleanup LTO logic to 
ensure that the last lto argument… (authored by mnadeem).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108881

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/amdgpu-toolchain.c
  clang/test/Driver/lto.c

Index: clang/test/Driver/lto.c
===
--- clang/test/Driver/lto.c
+++ clang/test/Driver/lto.c
@@ -85,3 +85,23 @@
 // FLTO-AUTO: -flto=full
 // FLTO-JOBSERVER: -flto=full
 //
+
+// Pass the last -flto argument.
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -flto 2>&1 | \
+// RUN: FileCheck --check-prefix=FLTO-FULL %s
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -flto=full \
+// RUN: 2>&1 | FileCheck --check-prefix=FLTO-FULL %s
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=full -flto=thin  \
+// RUN: 2>&1 | FileCheck --check-prefix=FLTO-THIN %s
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto -flto=thin 2>&1 | \
+// RUN: FileCheck --check-prefix=FLTO-THIN %s
+//
+// FLTO-FULL-NOT: -flto=thin
+// FLTO-FULL: -flto=full
+// FLTO-FULL-NOT: -flto=thin
+//
+// FLTO-THIN-NOT: -flto=full
+// FLTO-THIN-NOT: "-flto"
+// FLTO-THIN: -flto=thin
+// FLTO-THIN-NOT: "-flto"
+// FLTO-THIN-NOT: -flto=full
\ No newline at end of file
Index: clang/test/Driver/amdgpu-toolchain.c
===
--- clang/test/Driver/amdgpu-toolchain.c
+++ clang/test/Driver/amdgpu-toolchain.c
@@ -12,5 +12,5 @@
 
 // RUN: %clang -### -target amdgcn-amd-amdhsa -mcpu=gfx906 -nogpulib \
 // RUN:   -flto %s 2>&1 | FileCheck -check-prefix=LTO %s
-// LTO: clang{{.*}} "-flto"
+// LTO: clang{{.*}} "-flto=full"
 // LTO: ld.lld{{.*}}
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1419,7 +1419,7 @@
   }
 
   if (Opts.PrepareForLTO && !Opts.PrepareForThinLTO)
-GenerateArg(Args, OPT_flto, SA);
+GenerateArg(Args, OPT_flto_EQ, "full", SA);
 
   if (Opts.PrepareForThinLTO)
 GenerateArg(Args, OPT_flto_EQ, "thin", SA);
@@ -1706,9 +1706,10 @@
 }
   }
 
-  Opts.PrepareForLTO = Args.hasArg(OPT_flto, OPT_flto_EQ);
+  Opts.PrepareForLTO = false;
   Opts.PrepareForThinLTO = false;
   if (Arg *A = Args.getLastArg(OPT_flto_EQ)) {
+Opts.PrepareForLTO = true;
 StringRef S = A->getValue();
 if (S == "thin")
   Opts.PrepareForThinLTO = true;
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4474,28 +4474,18 @@
   CmdArgs.push_back("-emit-llvm-uselists");
 
 if (IsUsingLTO) {
-  if (!IsDeviceOffloadAction) {
-if (Args.hasArg(options::OPT_flto))
-  CmdArgs.push_back("-flto");
-else {
-  if (D.getLTOMode() == LTOK_Thin)
-CmdArgs.push_back("-flto=thin");
-  else
-CmdArgs.push_back("-flto=full");
-}
-CmdArgs.push_back("-flto-unit");
-  } else if (Triple.isAMDGPU()) {
-// Only AMDGPU supports device-side LTO
-assert(LTOMode == LTOK_Full || LTOMode == LTOK_Thin);
-CmdArgs.push_back(Args.MakeArgString(
-Twine("-flto=") + (LTOMode == LTOK_Thin ? "thin" : "full")));
-CmdArgs.push_back("-flto-unit");
-  } else {
+  // Only AMDGPU supports device-side LTO.
+  if (IsDeviceOffloadAction && !Triple.isAMDGPU()) {
 D.Diag(diag::err_drv_unsupported_opt_for_target)
 << Args.getLastArg(options::OPT_foffload_lto,
options::OPT_foffload_lto_EQ)
->getAsString(Args)
 << Triple.getTriple();
+  } else {
+assert(LTOMode == LTOK_Full || LTOMode == LTOK_Thin);
+CmdArgs.push_back(Args.MakeArgString(
+Twine("-flto=") + (LTOMode == LTOK_Thin ? "thin" : "full")));
+CmdArgs.push_back("-flto-unit");
   }
 }
   }
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -585,53 +585,34 @@
 // Parse the LTO options and record the type of LTO compilation
 // based on which -f(no-)?lto(=.*)? or -f(no-)?offload-lto(=.*)?
 // option occurs last.
-static llvm::Optional
-parseLTOMode(Driver &D, const llvm::opt::ArgList &Args, OptSpecifier OptPos,
- OptSpecifier OptNeg, OptSpecifier OptE

[PATCH] D109260: [RISCV] Add SiFive cores E and S series

[Alexander Pivovarov via Phabricator via cfe-commits]

apivovarov added a comment.

Craig, I fixed all of the issue on Fri. Could you look at the patch again? 
Thank you


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109260

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

[PATCH] D108243: Revert "Avoid needlessly copying a block to the heap when a block literal"

[Walter Lee via Phabricator via cfe-commits]

waltl updated this revision to Diff 371467.
waltl added a comment.
Herald added a subscriber: dang.

As suggested, I put the optimization behind an off-by-default flag.


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-avoid-heapify.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_reta

[PATCH] D109386: Change to use ValueHandle for associated data of GlobalCtors

[Lei Wang via Phabricator via cfe-commits]

wlei added a comment.

In D109386#2990504 , @rnk wrote:

> This seems incorrect: a weak VH won't have the same semantics, it will just 
> drop the comdat associativity when the underlying global changes type.

@rnk Thanks. Here I tried to use `WeakTrackingVH` working together with 
`replaceAllUsesWith` which is already there (in CodeGenModule.cpp:3904), my 
debugging dump showed like:

  GlobalCtors = [..,OldPtr];
  OldPtr->replaceAllUsesWith(NewPtr);
  GlobalCtors = [..,NewPtr];

I think this is what we desire. Do you think this can cause other issues or 
anything I missed?

> BTW, can this be tested, or is this only possible when clang is being used as 
> a library, perhaps as in swift?

Not swift, it seems this use-after-free needs a large program to repro, I tried 
to simplify it but failed to expose it by small program.




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:3904
   llvm::ConstantExpr::getBitCast(GV, Entry->getType());
   Entry->replaceAllUsesWith(NewPtrForOldDecl);
 }

Here is the `replaceAllUsesWith` .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109386

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

[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

[Shilei Tian via Phabricator via cfe-commits]

tianshilei1992 added inline comments.



Comment at: clang/test/Driver/openmp-offload-gpu.c:153
-/// bitcode library and add it to the LIBRARY_PATH.
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp 
-fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   -Xopenmp-target -march=sm_35 
--cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \

Seems like we don't have a test for the fallback version now?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

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

[PATCH] D109386: Change to use ValueHandle for associated data of GlobalCtors

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

It shouldn't need a large program to duplicate, but the test will need to 
exercise some unusual, arguably invalid conditions.

We need to add an entry with associated data to `GlobalCtors` or `GlobalDtors` 
and then replace the associated data.  We only actually use associated data in 
either of these lists when we have a C++ global variable with a dynamic 
initializer that needs a COMDAT key.  So first of all, the target needs to use 
COMDAT.  Also, the variable needs to satisfy the conditions for using a COMDAT 
key, which is apparently just being externally visible (which is surprising to 
me — I would expect this to only be useful on entities with vague linkage?).  
If all of that is true, then the COMDAT key we use for these entities is just 
the address of the variable.

Okay, so the test needs to trigger a replacement of the llvm::GlobalVariable 
that we emitted a constructor for.  The main reason we replace global variables 
is that we emitted a use of it with one IR type and then, when we got around to 
emitting its definition, we realized it needed to have a different IR type.  
(This is really just a bad representation in LLVM: external variable 
declarations don't actually need a value type, and it just causes problems.)  
This can happen in several different situations, like if the type of the 
variable was initially incomplete, or in some cases involving unions.  But none 
of that should apply here, because we actually compute a constant initializer 
for the global before we register a dynamic constructor function for it, so I 
can't see why we'd need to replace it.

My guess is that somehow your program is causing a second variable to be 
emitted with the same name, maybe using asm labels, or maybe due to some 
oversight in the mangling rules.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109386

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

[PATCH] D109386: Change to use ValueHandle for associated data of GlobalCtors

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In D109386#2990606 , @wlei wrote:

> Not swift, it seems this use-after-free needs a large program to repro, I 
> tried to simplify it but failed to expose it by small program.

If you use an ASan build to detect the use-after-free, you may be able to 
CReduce it down automatically.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109386

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

[PATCH] D109386: Change to use ValueHandle for associated data of GlobalCtors

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In D109386#2990606 , @wlei wrote:

> I think this is what we desire. Do you think this can cause other issues or 
> anything I missed?

I forgot to mention, yes, sounds good, I see, it is only weak when the value is 
erased without being replaced.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109386

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

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

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

In D36850#2968536 , @modimo wrote:

> In D36850#2964293 , @tejohnson wrote:
>
>> Good point on indirect calls. Rather than add a bit to the summary, can the 
>> flags just be set conservatively in any function containing an indirect call 
>> when we build the summaries initially? I think that would get the same 
>> effect.
>
> That could have an issue where A calls {indirect, B} and A gets propagated 
> upon from B without knowledge that the indirect call exists. Right now I've 
> got a FunFlags `hasUnknownCall` which marks these as non-propagatable.

Ah, because there isn't a conservative setting of the flag...which raises a 
larger issue (but maybe I am completely missing something) - how do we 
distinguish between the NoUnwind summary flag not being set because we don't 
know yet (in which case we want the propagation from callees), vs because it 
cannot be NoUnwind (because there is a throw in the function)? Do we need to 
have a second flag indicating that a function contains a mayThrow instruction 
(other than calls, which are being handled by the propagation)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D36850

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

[PATCH] D109467: [analyzer] check for std::__addressof for inner pointer checker

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Thanks! Can you add a regression test for this, like D99260 
 does in `test/Analysis/inner-pointer.cpp`? We 
typically want all commits to have associated test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109467

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

[PATCH] D105092: [RISCV] (1/2) Add the tail policy argument to builtins/intrinsics.

[Hsiangkai Wang via Phabricator via cfe-commits]

HsiangKai updated this revision to Diff 371499.
HsiangKai added a comment.

Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105092

Files:
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
  llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp
  llvm/lib/Target/RISCV/RISCVISelDAGToDAG.h
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
  llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
  llvm/lib/Target/RISCV/RISCVInstrInfoVVLPatterns.td
  llvm/test/CodeGen/RISCV/rvv/common-shuffle-patterns.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-buildvec.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-shuffles.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-shuffles.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-masked-gather.ll
  llvm/test/CodeGen/RISCV/rvv/interleave-crash.ll
  llvm/test/CodeGen/RISCV/rvv/mgather-sdnode.ll
  llvm/test/CodeGen/RISCV/rvv/tail-agnostic-impdef-copy.mir
  llvm/test/CodeGen/RISCV/rvv/vaadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vaadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vaaddu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vaaddu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vadd-policy.ll
  llvm/test/CodeGen/RISCV/rvv/vadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vand-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vand-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vasub-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vasub-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vasubu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vasubu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vdiv-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vdiv-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vdivu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vdivu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-f-x-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-f-x-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-f-xu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-f-xu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-rtz-x-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-rtz-x-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-rtz-xu-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-rtz-xu-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-x-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-x-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-xu-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-xu-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfdiv-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfdiv-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfmax-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfmax-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfmin-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfmin-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfmul-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfmul-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-x-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-x-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-xu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-xu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rod-f-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rod-f-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rtz-x-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rtz-x-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rtz-xu-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rtz-xu-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-x-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-x-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-xu-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-xu-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfrdiv-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfrdiv-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfrec7-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfrec7-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfrsqrt7-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfrsqrt7-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfrsub-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfrsub-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnj-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnj-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnjn-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnjn-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnjx-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnjx-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfslide1down-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfslide1down-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfslide1up-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfslide1up-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfsqrt-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfsqrt-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfsub-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfsub-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfwadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfwadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfwadd.w-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfwadd.w-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfwcvt-f-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfwcvt-f-f-rv64.ll
  llvm/test/CodeGen/RISC

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

[Di Mo via Phabricator via cfe-commits]

modimo added a comment.

In D36850#2990771 , @tejohnson wrote:

> In D36850#2968536 , @modimo wrote:
>
>> In D36850#2964293 , @tejohnson 
>> wrote:
>>
>>> Good point on indirect calls. Rather than add a bit to the summary, can the 
>>> flags just be set conservatively in any function containing an indirect 
>>> call when we build the summaries initially? I think that would get the same 
>>> effect.
>>
>> That could have an issue where A calls {indirect, B} and A gets propagated 
>> upon from B without knowledge that the indirect call exists. Right now I've 
>> got a FunFlags `hasUnknownCall` which marks these as non-propagatable.
>
> Ah, because there isn't a conservative setting of the flag...which raises a 
> larger issue (but maybe I am completely missing something) - how do we 
> distinguish between the NoUnwind summary flag not being set because we don't 
> know yet (in which case we want the propagation from callees), vs because it 
> cannot be NoUnwind (because there is a throw in the function)? Do we need to 
> have a second flag indicating that a function contains a mayThrow instruction 
> (other than calls, which are being handled by the propagation)?

Only call instructions can throw (what ultimately performs the throw operation 
is an opaque call to __cxa_throw()) which simplifies the problem. If all calls 
are known, we only need to examine the callees for accurate propagation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D36850

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

[clang] 12dcbf9 - [AMDGPU][OpenMP] Use complex definitions from complex_cmath.h

[Pushpinder Singh via cfe-commits]

Author: Pushpinder Singh
Date: 2021-09-09T10:55:17+05:30
New Revision: 12dcbf913c49db839b3669db0dcacd5de25facde

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

LOG: [AMDGPU][OpenMP] Use complex definitions from complex_cmath.h

Following nvptx approach, this patch uses complex function
definitions from complex_cmath.h. With this patch, ovo passes
23/34 complex mathematical test cases.

Reviewed By: JonChesterfield

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

Added: 
clang/test/Headers/amdgcn-openmp-device-math-complex.cpp

Modified: 
clang/lib/Headers/openmp_wrappers/complex

Removed: 




diff  --git a/clang/lib/Headers/openmp_wrappers/complex 
b/clang/lib/Headers/openmp_wrappers/complex
index d6e740df42fb3..1ceecc1af8aec 100644
--- a/clang/lib/Headers/openmp_wrappers/complex
+++ b/clang/lib/Headers/openmp_wrappers/complex
@@ -45,7 +45,7 @@
 #ifndef _LIBCPP_STD_VER
 
 #pragma omp begin declare variant match(   
\
-device = {arch(nvptx, nvptx64)},   
\
+device = {arch(amdgcn, nvptx, nvptx64)},   
\
 implementation = {extension(match_any, allow_templates)})
 
 #include 

diff  --git a/clang/test/Headers/amdgcn-openmp-device-math-complex.cpp 
b/clang/test/Headers/amdgcn-openmp-device-math-complex.cpp
new file mode 100644
index 0..d1a2cf31fabae
--- /dev/null
+++ b/clang/test/Headers/amdgcn-openmp-device-math-complex.cpp
@@ -0,0 +1,85 @@
+// RUN: %clang_cc1 -verify -internal-isystem %S/Inputs/include -fopenmp -x c++ 
-triple x86_64-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc 
%s -o %t-x86-host.bc
+// RUN: %clang_cc1 -verify -internal-isystem 
%S/../../lib/Headers/openmp_wrappers -include __clang_openmp_device_functions.h 
-internal-isystem %S/Inputs/include -fopenmp -x c++ -triple amdgcn-amd-amdhsa 
-fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-x86-host.bc -aux-triple x86_64-unknown-unknown -o 
- | FileCheck %s
+// expected-no-diagnostics
+
+#include 
+#include 
+
+// CHECK: define weak {{.*}} @__muldc3
+// CHECK-DAG: call i32 @__ocml_isnan_f64(
+// CHECK-DAG: call i32 @__ocml_isinf_f64(
+
+// CHECK: define weak {{.*}} @__mulsc3
+// CHECK-DAG: call i32 @__ocml_isnan_f32(
+// CHECK-DAG: call i32 @__ocml_isinf_f32(
+// CHECK-DAG: call float @__ocml_copysign_f32(
+
+// CHECK: define weak {{.*}} @__divdc3
+// CHECK-DAG: call i32 @__ocml_isnan_f64(
+// CHECK-DAG: call i32 @__ocml_isinf_f64(
+// CHECK-DAG: call i32 @__ocml_isfinite_f64(
+// CHECK-DAG: call double @__ocml_copysign_f64(
+// CHECK-DAG: call double @__ocml_scalbn_f64(
+// CHECK-DAG: call double @__ocml_fabs_f64(
+// CHECK-DAG: call double @__ocml_logb_f64(
+
+// CHECK: define weak {{.*}} @__divsc3
+// CHECK-DAG: call i32 @__ocml_isnan_f32(
+// CHECK-DAG: call i32 @__ocml_isinf_f32(
+// CHECK-DAG: call i32 @__ocml_isfinite_f32(
+// CHECK-DAG: call float @__ocml_copysign_f32(
+// CHECK-DAG: call float @__ocml_scalbn_f32(
+// CHECK-DAG: call float @__ocml_fabs_f32(
+// CHECK-DAG: call float @__ocml_logb_f32(
+
+// We actually check that there are no declarations of non-OpenMP functions.
+// That is, as long as we don't call an unkown function with a name that
+// doesn't start with '__' we are good :)
+
+// CHECK-NOT: declare.*@[^_]
+
+void test_scmplx(std::complex a) {
+#pragma omp target
+  {
+(void)(a * (a / a));
+  }
+}
+
+void test_dcmplx(std::complex a) {
+#pragma omp target
+  {
+(void)(a * (a / a));
+  }
+}
+
+template 
+std::complex test_template_math_calls(std::complex a) {
+  decltype(a) r = a;
+#pragma omp target
+  {
+r = std::sin(r);
+r = std::cos(r);
+r = std::exp(r);
+r = std::atan(r);
+r = std::acos(r);
+  }
+  return r;
+}
+
+std::complex test_scall(std::complex a) {
+  decltype(a) r;
+#pragma omp target
+  {
+r = std::sin(a);
+  }
+  return test_template_math_calls(r);
+}
+
+std::complex test_dcall(std::complex a) {
+  decltype(a) r;
+#pragma omp target
+  {
+r = std::exp(a);
+  }
+  return test_template_math_calls(r);
+}



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

[PATCH] D109344: [AMDGPU][OpenMP] Use complex definitions from complex_cmath.h

[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 rG12dcbf913c49: [AMDGPU][OpenMP] Use complex definitions from 
complex_cmath.h (authored by Pushpinder Singh 
).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109344

Files:
  clang/lib/Headers/openmp_wrappers/complex
  clang/test/Headers/amdgcn-openmp-device-math-complex.cpp

Index: clang/test/Headers/amdgcn-openmp-device-math-complex.cpp
===
--- /dev/null
+++ clang/test/Headers/amdgcn-openmp-device-math-complex.cpp
@@ -0,0 +1,85 @@
+// RUN: %clang_cc1 -verify -internal-isystem %S/Inputs/include -fopenmp -x c++ -triple x86_64-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -verify -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_device_functions.h -internal-isystem %S/Inputs/include -fopenmp -x c++ -triple amdgcn-amd-amdhsa -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -aux-triple x86_64-unknown-unknown -o - | FileCheck %s
+// expected-no-diagnostics
+
+#include 
+#include 
+
+// CHECK: define weak {{.*}} @__muldc3
+// CHECK-DAG: call i32 @__ocml_isnan_f64(
+// CHECK-DAG: call i32 @__ocml_isinf_f64(
+
+// CHECK: define weak {{.*}} @__mulsc3
+// CHECK-DAG: call i32 @__ocml_isnan_f32(
+// CHECK-DAG: call i32 @__ocml_isinf_f32(
+// CHECK-DAG: call float @__ocml_copysign_f32(
+
+// CHECK: define weak {{.*}} @__divdc3
+// CHECK-DAG: call i32 @__ocml_isnan_f64(
+// CHECK-DAG: call i32 @__ocml_isinf_f64(
+// CHECK-DAG: call i32 @__ocml_isfinite_f64(
+// CHECK-DAG: call double @__ocml_copysign_f64(
+// CHECK-DAG: call double @__ocml_scalbn_f64(
+// CHECK-DAG: call double @__ocml_fabs_f64(
+// CHECK-DAG: call double @__ocml_logb_f64(
+
+// CHECK: define weak {{.*}} @__divsc3
+// CHECK-DAG: call i32 @__ocml_isnan_f32(
+// CHECK-DAG: call i32 @__ocml_isinf_f32(
+// CHECK-DAG: call i32 @__ocml_isfinite_f32(
+// CHECK-DAG: call float @__ocml_copysign_f32(
+// CHECK-DAG: call float @__ocml_scalbn_f32(
+// CHECK-DAG: call float @__ocml_fabs_f32(
+// CHECK-DAG: call float @__ocml_logb_f32(
+
+// We actually check that there are no declarations of non-OpenMP functions.
+// That is, as long as we don't call an unkown function with a name that
+// doesn't start with '__' we are good :)
+
+// CHECK-NOT: declare.*@[^_]
+
+void test_scmplx(std::complex a) {
+#pragma omp target
+  {
+(void)(a * (a / a));
+  }
+}
+
+void test_dcmplx(std::complex a) {
+#pragma omp target
+  {
+(void)(a * (a / a));
+  }
+}
+
+template 
+std::complex test_template_math_calls(std::complex a) {
+  decltype(a) r = a;
+#pragma omp target
+  {
+r = std::sin(r);
+r = std::cos(r);
+r = std::exp(r);
+r = std::atan(r);
+r = std::acos(r);
+  }
+  return r;
+}
+
+std::complex test_scall(std::complex a) {
+  decltype(a) r;
+#pragma omp target
+  {
+r = std::sin(a);
+  }
+  return test_template_math_calls(r);
+}
+
+std::complex test_dcall(std::complex a) {
+  decltype(a) r;
+#pragma omp target
+  {
+r = std::exp(a);
+  }
+  return test_template_math_calls(r);
+}
Index: clang/lib/Headers/openmp_wrappers/complex
===
--- clang/lib/Headers/openmp_wrappers/complex
+++ clang/lib/Headers/openmp_wrappers/complex
@@ -45,7 +45,7 @@
 #ifndef _LIBCPP_STD_VER
 
 #pragma omp begin declare variant match(   \
-device = {arch(nvptx, nvptx64)},   \
+device = {arch(amdgcn, nvptx, nvptx64)},   \
 implementation = {extension(match_any, allow_templates)})
 
 #include 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109260: [RISCV] Add SiFive cores E and S series

[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/D109260/new/

https://reviews.llvm.org/D109260

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

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

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

In D36850#2990847 , @modimo wrote:

> In D36850#2990771 , @tejohnson wrote:
>
>> In D36850#2968536 , @modimo wrote:
>>
>>> In D36850#2964293 , @tejohnson 
>>> wrote:
>>>
 Good point on indirect calls. Rather than add a bit to the summary, can 
 the flags just be set conservatively in any function containing an 
 indirect call when we build the summaries initially? I think that would 
 get the same effect.
>>>
>>> That could have an issue where A calls {indirect, B} and A gets propagated 
>>> upon from B without knowledge that the indirect call exists. Right now I've 
>>> got a FunFlags `hasUnknownCall` which marks these as non-propagatable.
>>
>> Ah, because there isn't a conservative setting of the flag...which raises a 
>> larger issue (but maybe I am completely missing something) - how do we 
>> distinguish between the NoUnwind summary flag not being set because we don't 
>> know yet (in which case we want the propagation from callees), vs because it 
>> cannot be NoUnwind (because there is a throw in the function)? Do we need to 
>> have a second flag indicating that a function contains a mayThrow 
>> instruction (other than calls, which are being handled by the propagation)?
>
> Only call instructions can throw (what ultimately performs the throw 
> operation is an opaque call to __cxa_throw()) which simplifies the problem. 
> If all calls are known, we only need to examine the callees for accurate 
> propagation.

What about the other instruction checks done in Instruction::mayThrow i.e. 
http://llvm-cs.pcc.me.uk/lib/IR/Instruction.cpp#592?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D36850

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

[PATCH] D105168: [RISCV] Unify the arch string parsing logic to RISCVISAInfo.

[Kito Cheng via Phabricator via cfe-commits]

kito-cheng updated this revision to Diff 371509.
kito-cheng marked 2 inline comments as done.
kito-cheng added a comment.

Changes:

- Address Jim's comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105168

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Basic/Targets/RISCV.h
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-abi.c
  clang/test/Driver/riscv-arch.c
  clang/test/Driver/riscv-features.c
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Support/CMakeLists.txt
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/attribute-with-insts.s
  llvm/test/MC/RISCV/invalid-attribute.s

Index: llvm/test/MC/RISCV/invalid-attribute.s
===
--- llvm/test/MC/RISCV/invalid-attribute.s
+++ llvm/test/MC/RISCV/invalid-attribute.s
@@ -7,10 +7,10 @@
 # RUN: not llvm-mc %s -triple=riscv64 -filetype=asm 2>&1 | FileCheck %s
 
 .attribute arch, "foo"
-# CHECK: [[@LINE-1]]:18: error: bad arch string foo
+# CHECK: [[@LINE-1]]:18: error: invalid arch name 'foo', string must begin with rv32{i,e,g} or rv64{i,g}
 
 .attribute arch, "rv32i2p0_y2p0"
-# CHECK: [[@LINE-1]]:18: error: bad arch string y2p0
+# CHECK: [[@LINE-1]]:18: error: invalid arch name 'rv32i2p0_y2p0', invalid standard user-level extension 'y'
 
 .attribute stack_align, "16"
 # CHECK: [[@LINE-1]]:25: error: expected numeric constant
Index: llvm/test/MC/RISCV/attribute-with-insts.s
===
--- llvm/test/MC/RISCV/attribute-with-insts.s
+++ llvm/test/MC/RISCV/attribute-with-insts.s
@@ -10,7 +10,7 @@
 # RUN:   | llvm-objdump --triple=riscv64 -d -M no-aliases - \
 # RUN:   | FileCheck -check-prefix=CHECK-INST %s
 
-.attribute arch, "rv64i2p0_m2p0_a2p0_d2p0_c2p0"
+.attribute arch, "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0"
 
 # CHECK-INST: lr.w t0, (t1)
 lr.w t0, (t1)
Index: llvm/test/MC/RISCV/attribute-arch.s
===
--- llvm/test/MC/RISCV/attribute-arch.s
+++ llvm/test/MC/RISCV/attribute-arch.s
@@ -9,9 +9,6 @@
 .attribute arch, "rv32i2"
 # CHECK: attribute  5, "rv32i2p0"
 
-.attribute arch, "rv32i2p"
-# CHECK: attribute  5, "rv32i2p0"
-
 .attribute arch, "rv32i2p0"
 # CHECK: attribute  5, "rv32i2p0"
 
@@ -33,14 +30,14 @@
 .attribute arch, "rv32ima2p0_fdc"
 # CHECK: attribute  5, "rv32i2p0_m2p0_a2p0_f2p0_d2p0_c2p0"
 
-.attribute arch, "rv32ima2p_fdc"
+.attribute arch, "rv32ima2p0_fdc"
 # CHECK: attribute  5, "rv32i2p0_m2p0_a2p0_f2p0_d2p0_c2p0"
 
 .attribute arch, "rv32ib"
 # CHECK: attribute  5, "rv32i2p0_b0p93_zba0p93_zbb0p93_zbc0p93_zbe0p93_zbf0p93_zbm0p93_zbp0p93_zbr0p93_zbs0p93_zbt0p93"
 
 .attribute arch, "rv32iv"
-# CHECK: attribute  5, "rv32i2p0_v0p10"
+# CHECK: attribute  5, "rv32i2p0_v0p10_zvlsseg0p10"
 
 .attribute arch, "rv32izba"
 # CHECK: attribute  5, "rv32i2p0_zba0p93"
Index: llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
===
--- llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
+++ llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
@@ -11,9 +11,11 @@
 //===--===//
 
 #include "RISCVTargetStreamer.h"
+#include "RISCVBaseInfo.h"
 #include "RISCVMCTargetDesc.h"
 #include "llvm/Support/FormattedStream.h"
 #include "llvm/Support/RISCVAttributes.h"
+#include "llvm/Support/RISCVISAInfo.h"
 
 using namespace llvm;
 
@@ -43,57 +45,19 @@
   else
 emitAttribute(RISCVAttrs::STACK_ALIGN, RISCVAttrs::ALIGN_16);
 
-  std::string Arch = "rv32";
-  if (STI.hasFeature(RISCV::Feature64Bit))
-Arch = "rv64";
-  if (STI.hasFeature(RISCV::FeatureRV32E))
-Arch += "e1p9";
-  else
-Arch += "i2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtM))
-Arch += "_m2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtA))
-Arch += "_a2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtF))
-Arch += "_f2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtD))
-Arch += "_d2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtC))
-Arch += "_c2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtB))
-Arch += "_b0p93";
-  if (STI.hasFeature(RISCV::FeatureStdExtV))
-Arch += "_v0p10";
-  if (STI.hasFeature(RISCV::FeatureExtZfh))
-Arch += "_zfh0p1";
-  if (STI.hasFeature(RISCV::FeatureExtZba))
-Arch += "_zba0p93";
-  if (STI.hasFeature(RISCV::FeatureExtZbb))
-Arch += "_zbb0p93";
-  if (STI.hasFeature(RISCV::FeatureExtZbc))
-Arch += "_zbc0p93";
-  if (STI.hasFeature(

[PATCH] D109485: [clang-scan-deps] Add an API for clang dependency scanner to perform module lookup by name alone

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak created this revision.
ahatanak added a reviewer: jansvoboda11.
ahatanak added a project: clang.
ahatanak requested review of this revision.

This removes the need to create a fake source file that imports a module.

rdar://64538073


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109485

Files:
  clang/include/clang/Frontend/FrontendActions.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  clang/test/ClangScanDeps/Inputs/modules_cdb_by_mod_name.json
  clang/test/ClangScanDeps/Inputs/modules_cdb_clangcl_by_mod_name.json
  clang/test/ClangScanDeps/modules-full-by-mod-name.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -194,6 +194,11 @@
 "until reaching the end directive."),
 llvm::cl::init(true), llvm::cl::cat(DependencyScannerCategory));
 
+llvm::cl::opt ModuleName(
+"module-name", llvm::cl::Optional,
+llvm::cl::desc("the module of which the dependencies are to be computed"),
+llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::opt Verbose("v", llvm::cl::Optional,
 llvm::cl::desc("Use verbose output."),
 llvm::cl::init(false),
@@ -544,13 +549,20 @@
 }
 // Run the tool on it.
 if (Format == ScanningOutputFormat::Make) {
-  auto MaybeFile = WorkerTools[I]->getDependencyFile(*Input, CWD);
+  auto MaybeFile = WorkerTools[I]->getDependencyFile(
+  *Input, CWD,
+  ModuleName.empty()
+  ? None
+  : llvm::Optional(ModuleName.c_str()));
   if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
  Errs))
 HadErrors = true;
 } else {
   auto MaybeFullDeps = WorkerTools[I]->getFullDependencies(
-  *Input, CWD, AlreadySeenModules);
+  *Input, CWD, AlreadySeenModules,
+  ModuleName.empty()
+  ? None
+  : llvm::Optional(ModuleName.c_str()));
   if (handleFullDependencyToolResult(Filename, MaybeFullDeps, FD,
  LocalIndex, DependencyOS, Errs))
 HadErrors = true;
Index: clang/test/ClangScanDeps/modules-full-by-mod-name.cpp
===
--- /dev/null
+++ clang/test/ClangScanDeps/modules-full-by-mod-name.cpp
@@ -0,0 +1,79 @@
+// RUN: rm -rf %t.dir
+// RUN: rm -rf %t.cdb
+// RUN: mkdir -p %t.dir
+// RUN: cp %s %t.dir/modules_cdb_input.cpp
+// RUN: cp %s %t.dir/modules_cdb_input2.cpp
+// RUN: mkdir %t.dir/Inputs
+// RUN: cp %S/Inputs/header.h %t.dir/Inputs/header.h
+// RUN: cp %S/Inputs/header2.h %t.dir/Inputs/header2.h
+// RUN: cp %S/Inputs/module.modulemap %t.dir/Inputs/module.modulemap
+// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/modules_cdb_by_mod_name.json > %t.cdb
+// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/modules_cdb_clangcl_by_mod_name.json > %t_clangcl.cdb
+//
+// RUN: echo %t.dir > %t.result
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 4 -format experimental-full \
+// RUN:   -mode preprocess-minimized-sources -module-name=header1 >> %t.result
+// RUN: cat %t.result | sed 's:\?:/:g' | FileCheck --check-prefixes=CHECK %s
+//
+// RUN: echo %t.dir > %t_clangcl.result
+// RUN: clang-scan-deps -compilation-database %t_clangcl.cdb -j 4 -format experimental-full \
+// RUN:   -mode preprocess-minimized-sources -module-name=header1 >> %t_clangcl.result
+// RUN: cat %t_clangcl.result | sed 's:\?:/:g' | FileCheck --check-prefixes=CHECK %s
+
+// CHECK: [[PREFIX:.*]]
+// CHECK-NEXT: {
+// CHECK-NEXT:   "modules": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "clang-module-deps": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "context-hash": "[[HASH_H2_DINCLUDE:[A-Z0-9]+]]",
+// CHECK-NEXT:   "module-name": "header2"
+// CHECK-NEXT: }
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "clang-modulemap-file": "[[PREFIX]]/Inputs/module.modulemap",
+// CHECK-NEXT:   "command-line": [
+// CHECK-NEXT: "-cc1"
+// CHECK:  "-emit-module"
+// CHECK:  "-fmodule-name=header1"
+// CHECK:  "-fno-implicit-modules"
+// CHECK:],
+// CHECK-NEXT:   "context-hash": "[[HASH_H1_DINCLUDE:[A-Z0-9]+]]",
+// CHECK-NEXT:   "file-deps": [
+// CHECK-NEXT: "[[PREFIX]]/Inputs/header.h",
+// CHECK-NEXT: "[[PREFIX]]/Inputs/module.modulemap"
+// CHECK-NEXT:   ],

[PATCH] D109127: Fix python 2-vs-3 issues in add_new_check.py and rename_check.py

[Kirill Bobyrev via Phabricator via cfe-commits]

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

Nice, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109127

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

[clang] 4bc8dbe - [RISCV] Add SiFive cores E and S series

[Alexander Pivovarov via cfe-commits]

Author: Alexander Pivovarov
Date: 2021-09-08T23:59:04-07:00
New Revision: 4bc8dbe0cae32f15008c1e98e7dd7d128e9dcbb6

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

LOG: [RISCV] Add SiFive cores E and S series

Add SiFive cores E20, E21, E24, E34, S21, S54 and S76

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/test/Driver/riscv-cpus.c
clang/test/Misc/target-invalid-cpu-note.c
llvm/include/llvm/Support/RISCVTargetParser.def
llvm/lib/Target/RISCV/RISCV.td

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 6caf24ca4ef77..56f91b4e5877f 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -73,7 +73,14 @@ Modified Compiler Flags
 
 - Support has been added for the following processors (``-mcpu`` identifiers 
in parentheses):
 
+  - RISC-V SiFive E20 (``sifive-e20``).
+  - RISC-V SiFive E21 (``sifive-e21``).
+  - RISC-V SiFive E24 (``sifive-e24``).
+  - RISC-V SiFive E34 (``sifive-e34``).
+  - RISC-V SiFive S21 (``sifive-s21``).
   - RISC-V SiFive S51 (``sifive-s51``).
+  - RISC-V SiFive S54 (``sifive-s54``).
+  - RISC-V SiFive S76 (``sifive-s76``).
 
 Removed Compiler Flags
 -

diff  --git a/clang/test/Driver/riscv-cpus.c b/clang/test/Driver/riscv-cpus.c
index 4c26bf8751c27..444b0aef623a1 100644
--- a/clang/test/Driver/riscv-cpus.c
+++ b/clang/test/Driver/riscv-cpus.c
@@ -45,6 +45,39 @@
 // RUN: %clang -target riscv64 -### -c %s 2>&1 -mtune=sifive-7-series | 
FileCheck -check-prefix=MTUNE-SIFIVE7-SERIES-64 %s
 // MTUNE-SIFIVE7-SERIES-64: "-tune-cpu" "sifive-7-rv64"
 
+// mcpu with default march
+// RUN: %clang -target riscv64 -### -c %s 2>&1 -mcpu=sifive-e20 | FileCheck 
-check-prefix=MCPU-SIFIVE-E20 %s
+// MCPU-SIFIVE-E20: "-nostdsysteminc" "-target-cpu" "sifive-e20"
+// MCPU-SIFIVE-E20: "-target-feature" "+m" "-target-feature" "+c"
+// MCPU-SIFIVE-E20: "-target-abi" "ilp32"
+
+// mcpu with default march
+// RUN: %clang -target riscv64 -### -c %s 2>&1 -mcpu=sifive-e21 | FileCheck 
-check-prefix=MCPU-SIFIVE-E21 %s
+// MCPU-SIFIVE-E21: "-nostdsysteminc" "-target-cpu" "sifive-e21"
+// MCPU-SIFIVE-E21: "-target-feature" "+m" "-target-feature" "+a" 
"-target-feature" "+c"
+// MCPU-SIFIVE-E21: "-target-abi" "ilp32"
+
+// mcpu with default march
+// RUN: %clang -target riscv64 -### -c %s 2>&1 -mcpu=sifive-e24 | FileCheck 
-check-prefix=MCPU-SIFIVE-E24 %s
+// MCPU-SIFIVE-E24: "-nostdsysteminc" "-target-cpu" "sifive-e24"
+// MCPU-SIFIVE-E24: "-target-feature" "+m" "-target-feature" "+a" 
"-target-feature" "+f"
+// MCPU-SIFIVE-E24: "-target-feature" "+c"
+// MCPU-SIFIVE-E24: "-target-abi" "ilp32"
+
+// mcpu with default march
+// RUN: %clang -target riscv64 -### -c %s 2>&1 -mcpu=sifive-e34 | FileCheck 
-check-prefix=MCPU-SIFIVE-E34 %s
+// MCPU-SIFIVE-E34: "-nostdsysteminc" "-target-cpu" "sifive-e34"
+// MCPU-SIFIVE-E34: "-target-feature" "+m" "-target-feature" "+a" 
"-target-feature" "+f"
+// MCPU-SIFIVE-E34: "-target-feature" "+c"
+// MCPU-SIFIVE-E34: "-target-abi" "ilp32"
+
+// mcpu with mabi option
+// RUN: %clang -target riscv64 -### -c %s 2>&1 -mcpu=sifive-s21 -mabi=lp64 | 
FileCheck -check-prefix=MCPU-ABI-SIFIVE-S21 %s
+// MCPU-ABI-SIFIVE-S21: "-nostdsysteminc" "-target-cpu" "sifive-s21"
+// MCPU-ABI-SIFIVE-S21: "-target-feature" "+m" "-target-feature" "+a"
+// MCPU-ABI-SIFIVE-S21: "-target-feature" "+c" "-target-feature" "+64bit"
+// MCPU-ABI-SIFIVE-S21: "-target-abi" "lp64"
+
 // mcpu with mabi option
 // RUN: %clang -target riscv64 -### -c %s 2>&1 -mcpu=sifive-s51 -mabi=lp64 | 
FileCheck -check-prefix=MCPU-ABI-SIFIVE-S51 %s
 // MCPU-ABI-SIFIVE-S51: "-nostdsysteminc" "-target-cpu" "sifive-s51"
@@ -52,6 +85,20 @@
 // MCPU-ABI-SIFIVE-S51: "-target-feature" "+c" "-target-feature" "+64bit"
 // MCPU-ABI-SIFIVE-S51: "-target-abi" "lp64"
 
+// mcpu with default march
+// RUN: %clang -target riscv64 -### -c %s 2>&1 -mcpu=sifive-s54 | FileCheck 
-check-prefix=MCPU-SIFIVE-S54 %s
+// MCPU-SIFIVE-S54: "-nostdsysteminc" "-target-cpu" "sifive-s54"
+// MCPU-SIFIVE-S54: "-target-feature" "+m" "-target-feature" "+a" 
"-target-feature" "+f" "-target-feature" "+d"
+// MCPU-SIFIVE-S54: "-target-feature" "+c" "-target-feature" "+64bit"
+// MCPU-SIFIVE-S54: "-target-abi" "lp64d"
+
+// mcpu with mabi option
+// RUN: %clang -target riscv64 -### -c %s 2>&1 -mcpu=sifive-s76 | FileCheck 
-check-prefix=MCPU-SIFIVE-S76 %s
+// MCPU-SIFIVE-S76: "-nostdsysteminc" "-target-cpu" "sifive-s76"
+// MCPU-SIFIVE-S76: "-target-feature" "+m" "-target-feature" "+a" 
"-target-feature" "+f" "-target-feature" "+d"
+// MCPU-SIFIVE-S76: "-target-feature" "+c" "-target-feature" "+64bit"
+// MCPU-SIFIVE-S76: "-target-abi" "lp64d"
+
 // mcpu with default march
 //