[clang] ed1d290 - [Driver][NFC] Remove identifier with the comment (#68351)

[via cfe-commits]

Author: Brad Smith
Date: 2023-10-17T23:27:07-04:00
New Revision: ed1d29028492b28b4790690b275b3a095f56fa47

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

LOG: [Driver][NFC] Remove identifier with the comment (#68351)

MaskRay suggested removal of the identifer in a review for another
ToolChain so doing the same for the rest.

Added: 


Modified: 
clang/lib/Driver/ToolChains/AIX.h
clang/lib/Driver/ToolChains/DragonFly.h
clang/lib/Driver/ToolChains/FreeBSD.h
clang/lib/Driver/ToolChains/MinGW.h
clang/lib/Driver/ToolChains/NetBSD.h
clang/lib/Driver/ToolChains/OpenBSD.h
clang/lib/Driver/ToolChains/Solaris.h
clang/lib/Driver/ToolChains/ZOS.h

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/AIX.h 
b/clang/lib/Driver/ToolChains/AIX.h
index cc74e5ea85efcac..04f9b2240999cc2 100644
--- a/clang/lib/Driver/ToolChains/AIX.h
+++ b/clang/lib/Driver/ToolChains/AIX.h
@@ -16,7 +16,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// aix -- Directly call system default assembler and linker.
+/// Directly call system default assembler and linker.
 namespace aix {
 
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {

diff  --git a/clang/lib/Driver/ToolChains/DragonFly.h 
b/clang/lib/Driver/ToolChains/DragonFly.h
index 42ce960c5bdbd95..4dceb09a17364df 100644
--- a/clang/lib/Driver/ToolChains/DragonFly.h
+++ b/clang/lib/Driver/ToolChains/DragonFly.h
@@ -16,7 +16,8 @@
 namespace clang {
 namespace driver {
 namespace tools {
-/// dragonfly -- Directly call GNU Binutils assembler and linker
+
+/// Directly call GNU Binutils assembler and linker
 namespace dragonfly {
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
 public:

diff  --git a/clang/lib/Driver/ToolChains/FreeBSD.h 
b/clang/lib/Driver/ToolChains/FreeBSD.h
index cec67d84a2cea8d..740274b314ba1f8 100644
--- a/clang/lib/Driver/ToolChains/FreeBSD.h
+++ b/clang/lib/Driver/ToolChains/FreeBSD.h
@@ -17,7 +17,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// freebsd -- Directly call GNU Binutils assembler and linker
+/// Directly call GNU Binutils assembler and linker
 namespace freebsd {
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
 public:

diff  --git a/clang/lib/Driver/ToolChains/MinGW.h 
b/clang/lib/Driver/ToolChains/MinGW.h
index 6d5feeacdadda4b..a71013912d0a3e9 100644
--- a/clang/lib/Driver/ToolChains/MinGW.h
+++ b/clang/lib/Driver/ToolChains/MinGW.h
@@ -20,7 +20,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// MinGW -- Directly call GNU Binutils assembler and linker
+/// Directly call GNU Binutils assembler and linker
 namespace MinGW {
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
 public:

diff  --git a/clang/lib/Driver/ToolChains/NetBSD.h 
b/clang/lib/Driver/ToolChains/NetBSD.h
index 0f9b6dceb6fcf4f..044c4239c3f48a2 100644
--- a/clang/lib/Driver/ToolChains/NetBSD.h
+++ b/clang/lib/Driver/ToolChains/NetBSD.h
@@ -17,7 +17,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// netbsd -- Directly call GNU Binutils assembler and linker
+/// Directly call GNU Binutils assembler and linker
 namespace netbsd {
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
 public:

diff  --git a/clang/lib/Driver/ToolChains/OpenBSD.h 
b/clang/lib/Driver/ToolChains/OpenBSD.h
index b7d3d1b5b6dc311..486dbf1407c2412 100644
--- a/clang/lib/Driver/ToolChains/OpenBSD.h
+++ b/clang/lib/Driver/ToolChains/OpenBSD.h
@@ -18,7 +18,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// openbsd -- Directly call GNU Binutils assembler and linker
+/// Directly call GNU Binutils assembler and linker
 namespace openbsd {
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
 public:

diff  --git a/clang/lib/Driver/ToolChains/Solaris.h 
b/clang/lib/Driver/ToolChains/Solaris.h
index 04b68c5053caa6c..b8f2497d7c8eb1b 100644
--- a/clang/lib/Driver/ToolChains/Solaris.h
+++ b/clang/lib/Driver/ToolChains/Solaris.h
@@ -17,7 +17,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// solaris -- Directly call Solaris assembler and linker
+/// Directly call Solaris assembler and linker
 namespace solaris {
 class LLVM_LIBRARY_VISIBILITY Assembler : public gnutools::Assembler {
 public:

diff  --git a/clang/lib/Driver/ToolChains/ZOS.h 
b/clang/lib/Driver/ToolChains/ZOS.h
index 548b432ade76704..4b9b332c0f3fbda 100644
--- a/clang/lib/Driver/ToolChains/ZOS.h
+++ b/clang/lib/Driver/ToolChains/ZOS.h
@@ -16,7 +16,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// zos -- Directly call system default assembler and linker.
+/// Directly call system default assembler and linker.
 namespace zos {
 
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {

[clang] [Driver][NFC] Remove identifier with the comment (PR #68351)

[Brad Smith via cfe-commits]

https://github.com/brad0 closed https://github.com/llvm/llvm-project/pull/68351
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver][NFC] Remove identifier with the comment (PR #68351)

[Brad Smith via cfe-commits]

https://github.com/brad0 edited https://github.com/llvm/llvm-project/pull/68351
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver] Remove identifier with the comment (PR #68351)

[Brad Smith via cfe-commits]

https://github.com/brad0 updated https://github.com/llvm/llvm-project/pull/68351

>From 4cf784b8e73515c3120793ac0ec1cf59ef6da767 Mon Sep 17 00:00:00 2001
From: Brad Smith 
Date: Thu, 5 Oct 2023 16:23:58 -0400
Subject: [PATCH] [Driver][NFC] Remove identifier with the comment

MaskRay suggested removal of the identifer in a review for another
ToolChain so doing the same for the rest.
---
 clang/lib/Driver/ToolChains/AIX.h   | 2 +-
 clang/lib/Driver/ToolChains/DragonFly.h | 3 ++-
 clang/lib/Driver/ToolChains/FreeBSD.h   | 2 +-
 clang/lib/Driver/ToolChains/MinGW.h | 2 +-
 clang/lib/Driver/ToolChains/NetBSD.h| 2 +-
 clang/lib/Driver/ToolChains/OpenBSD.h   | 2 +-
 clang/lib/Driver/ToolChains/Solaris.h   | 2 +-
 clang/lib/Driver/ToolChains/ZOS.h   | 2 +-
 8 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/AIX.h 
b/clang/lib/Driver/ToolChains/AIX.h
index cc74e5ea85efcac..04f9b2240999cc2 100644
--- a/clang/lib/Driver/ToolChains/AIX.h
+++ b/clang/lib/Driver/ToolChains/AIX.h
@@ -16,7 +16,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// aix -- Directly call system default assembler and linker.
+/// Directly call system default assembler and linker.
 namespace aix {
 
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
diff --git a/clang/lib/Driver/ToolChains/DragonFly.h 
b/clang/lib/Driver/ToolChains/DragonFly.h
index 42ce960c5bdbd95..4dceb09a17364df 100644
--- a/clang/lib/Driver/ToolChains/DragonFly.h
+++ b/clang/lib/Driver/ToolChains/DragonFly.h
@@ -16,7 +16,8 @@
 namespace clang {
 namespace driver {
 namespace tools {
-/// dragonfly -- Directly call GNU Binutils assembler and linker
+
+/// Directly call GNU Binutils assembler and linker
 namespace dragonfly {
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
 public:
diff --git a/clang/lib/Driver/ToolChains/FreeBSD.h 
b/clang/lib/Driver/ToolChains/FreeBSD.h
index cec67d84a2cea8d..740274b314ba1f8 100644
--- a/clang/lib/Driver/ToolChains/FreeBSD.h
+++ b/clang/lib/Driver/ToolChains/FreeBSD.h
@@ -17,7 +17,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// freebsd -- Directly call GNU Binutils assembler and linker
+/// Directly call GNU Binutils assembler and linker
 namespace freebsd {
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
 public:
diff --git a/clang/lib/Driver/ToolChains/MinGW.h 
b/clang/lib/Driver/ToolChains/MinGW.h
index 6d5feeacdadda4b..a71013912d0a3e9 100644
--- a/clang/lib/Driver/ToolChains/MinGW.h
+++ b/clang/lib/Driver/ToolChains/MinGW.h
@@ -20,7 +20,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// MinGW -- Directly call GNU Binutils assembler and linker
+/// Directly call GNU Binutils assembler and linker
 namespace MinGW {
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
 public:
diff --git a/clang/lib/Driver/ToolChains/NetBSD.h 
b/clang/lib/Driver/ToolChains/NetBSD.h
index 0f9b6dceb6fcf4f..044c4239c3f48a2 100644
--- a/clang/lib/Driver/ToolChains/NetBSD.h
+++ b/clang/lib/Driver/ToolChains/NetBSD.h
@@ -17,7 +17,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// netbsd -- Directly call GNU Binutils assembler and linker
+/// Directly call GNU Binutils assembler and linker
 namespace netbsd {
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
 public:
diff --git a/clang/lib/Driver/ToolChains/OpenBSD.h 
b/clang/lib/Driver/ToolChains/OpenBSD.h
index b7d3d1b5b6dc311..486dbf1407c2412 100644
--- a/clang/lib/Driver/ToolChains/OpenBSD.h
+++ b/clang/lib/Driver/ToolChains/OpenBSD.h
@@ -18,7 +18,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// openbsd -- Directly call GNU Binutils assembler and linker
+/// Directly call GNU Binutils assembler and linker
 namespace openbsd {
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
 public:
diff --git a/clang/lib/Driver/ToolChains/Solaris.h 
b/clang/lib/Driver/ToolChains/Solaris.h
index 04b68c5053caa6c..b8f2497d7c8eb1b 100644
--- a/clang/lib/Driver/ToolChains/Solaris.h
+++ b/clang/lib/Driver/ToolChains/Solaris.h
@@ -17,7 +17,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// solaris -- Directly call Solaris assembler and linker
+/// Directly call Solaris assembler and linker
 namespace solaris {
 class LLVM_LIBRARY_VISIBILITY Assembler : public gnutools::Assembler {
 public:
diff --git a/clang/lib/Driver/ToolChains/ZOS.h 
b/clang/lib/Driver/ToolChains/ZOS.h
index 548b432ade76704..4b9b332c0f3fbda 100644
--- a/clang/lib/Driver/ToolChains/ZOS.h
+++ b/clang/lib/Driver/ToolChains/ZOS.h
@@ -16,7 +16,7 @@ namespace clang {
 namespace driver {
 namespace tools {
 
-/// zos -- Directly call system default assembler and linker.
+/// Directly call system default assembler and linker.
 namespace zos {
 
 class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {

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

[clang] [X86][RFC] Support AVX10 options (PR #67278)

[Evgenii Kudriashov via cfe-commits]

@@ -130,17 +131,35 @@ bool X86TargetInfo::initFeatureMap(
   continue;
 }
 
-if (!HasAVX512F && Feature.substr(0, 7) == "+avx512")
+if (Feature.substr(0, 7) == "+avx10.") {
+  HasAVX10 = true;
   HasAVX512F = true;
-if (HasAVX512F && Feature == "-avx512f")
+  if (Feature.substr(Feature.size() - 3, 3) == "512") {
+HasEVEX512 = true;
+  } else if (Feature.substr(7, 2) == "1-") {
+HasEVEX512 = false;
+  }
+} else if (!HasAVX512F && Feature.substr(0, 7) == "+avx512") {
+  HasAVX512F = true;
+} else if (HasAVX512F && Feature == "-avx512f") {
+  HasAVX512F = false;
+} else if (HasAVX10 && Feature == "-avx10.1-256") {
+  HasAVX10 = false;
   HasAVX512F = false;
-if (HasEVEX512 && Feature == "-evex512")
+} else if (!HasEVEX512 && Feature == "+evex512") {
+  HasEVEX512 = true;
+} else if (HasEVEX512 && Feature == "-avx10.1-512") {

e-kud wrote:

`+avx10.1-512,-avx10.1-512` effectively means `+avx10.1-256`?

Generally, when I see such flag dangling, I'm used to thinking there is likely 
to be a bug. Do we have some reasoning that it is correct? Or maybe it's just 
my internal bias.

https://github.com/llvm/llvm-project/pull/67278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [X86][RFC] Support AVX10 options (PR #67278)

[Evgenii Kudriashov via cfe-commits]

@@ -130,17 +131,35 @@ bool X86TargetInfo::initFeatureMap(
   continue;
 }
 
-if (!HasAVX512F && Feature.substr(0, 7) == "+avx512")
+if (Feature.substr(0, 7) == "+avx10.") {
+  HasAVX10 = true;
   HasAVX512F = true;
-if (HasAVX512F && Feature == "-avx512f")
+  if (Feature.substr(Feature.size() - 3, 3) == "512") {
+HasEVEX512 = true;
+  } else if (Feature.substr(7, 2) == "1-") {

e-kud wrote:

I'm not sure whether the comment here is needed or not, but I've had the first 
question: why don't we reset `HasEVEX512` for `avx10.2-256`. And only after 
realization that `avx10.2-256` implies `avx10.1-256`, it makes sense.

https://github.com/llvm/llvm-project/pull/67278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [X86][RFC] Support AVX10 options (PR #67278)

[Evgenii Kudriashov via cfe-commits]

@@ -130,17 +131,35 @@ bool X86TargetInfo::initFeatureMap(
   continue;
 }
 
-if (!HasAVX512F && Feature.substr(0, 7) == "+avx512")
+if (Feature.substr(0, 7) == "+avx10.") {
+  HasAVX10 = true;
   HasAVX512F = true;
-if (HasAVX512F && Feature == "-avx512f")
+  if (Feature.substr(Feature.size() - 3, 3) == "512") {
+HasEVEX512 = true;
+  } else if (Feature.substr(7, 2) == "1-") {

e-kud wrote:

I'm not sure whether the comment here is needed or not, but I've had the first 
question: why don't we reset `HasEVEX512` for `avx10.2-256`. And only after 
realization that `avx10.2-256` implies `avx10.1-256`, it makes sense.

https://github.com/llvm/llvm-project/pull/67278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver][DragonFly] Fixes for linker path and command-line option handling (PR #69095)

[Brad Smith via cfe-commits]

https://github.com/brad0 edited https://github.com/llvm/llvm-project/pull/69095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver][DragonFly] Fixes for linker path and command-line option handling (PR #69095)

[Brad Smith via cfe-commits]

https://github.com/brad0 updated https://github.com/llvm/llvm-project/pull/69095

>From 7009758fba9b7053f6ea76033de7221f25722ed6 Mon Sep 17 00:00:00 2001
From: Brad Smith 
Date: Sun, 15 Oct 2023 04:00:56 -0400
Subject: [PATCH] [Driver][DragonFly] Fixes for linker path and command-line
 option handling

- Add in some other linker command line options that the other BSD's handle
- Make use of AddFilePathLibArgs()
- Handle OpenMP
---
 clang/lib/Driver/ToolChains/DragonFly.cpp | 16 ++--
 clang/test/Driver/dragonfly.c | 10 --
 clang/test/Driver/fopenmp.c   | 19 ++-
 3 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/DragonFly.cpp 
b/clang/lib/Driver/ToolChains/DragonFly.cpp
index a58983aba5a12f2..3778c7773b6b90b 100644
--- a/clang/lib/Driver/ToolChains/DragonFly.cpp
+++ b/clang/lib/Driver/ToolChains/DragonFly.cpp
@@ -56,7 +56,8 @@ void dragonfly::Linker::ConstructJob(Compilation , const 
JobAction ,
  const InputInfoList ,
  const ArgList ,
  const char *LinkingOutput) const {
-  const Driver  = getToolChain().getDriver();
+  const auto  = static_cast(getToolChain());
+  const Driver  = ToolChain.getDriver();
   ArgStringList CmdArgs;
 
   if (!D.SysRoot.empty())
@@ -115,21 +116,24 @@ void dragonfly::Linker::ConstructJob(Compilation , 
const JobAction ,
   Args.MakeArgString(getToolChain().GetFilePath("crtbegin.o")));
   }
 
-  Args.addAllArgs(CmdArgs, {options::OPT_L, options::OPT_T_Group});
+  Args.addAllArgs(CmdArgs, {options::OPT_L, options::OPT_T_Group,
+options::OPT_s, options::OPT_t, options::OPT_r});
+  ToolChain.AddFilePathLibArgs(Args, CmdArgs);
 
   AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs, JA);
 
   if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs,
options::OPT_r)) {
-SmallString<128> Dir(D.SysRoot);
-llvm::sys::path::append(Dir, "/usr/lib/gcc80");
-CmdArgs.push_back(Args.MakeArgString("-L" + Dir));
-
 if (!Args.hasArg(options::OPT_static)) {
   CmdArgs.push_back("-rpath");
   CmdArgs.push_back("/usr/lib/gcc80");
 }
 
+// Use the static OpenMP runtime with -static-openmp
+bool StaticOpenMP = Args.hasArg(options::OPT_static_openmp) &&
+!Args.hasArg(options::OPT_static);
+addOpenMPRuntime(CmdArgs, ToolChain, Args, StaticOpenMP);
+
 if (D.CCCIsCXX()) {
   if (getToolChain().ShouldLinkCXXStdlib(Args))
 getToolChain().AddCXXStdlibLibArgs(Args, CmdArgs);
diff --git a/clang/test/Driver/dragonfly.c b/clang/test/Driver/dragonfly.c
index 8ba13c41d632c20..11d730f55bd9d69 100644
--- a/clang/test/Driver/dragonfly.c
+++ b/clang/test/Driver/dragonfly.c
@@ -2,7 +2,7 @@
 // RUN: FileCheck -input-file %t.log %s
 
 // CHECK: "-cc1" "-triple" "x86_64-pc-dragonfly"
-// CHECK: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" 
"/usr/libexec/ld-elf.so.{{.*}}" "--hash-style=gnu" "--enable-new-dtags" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" "{{.*}}.o" 
"-L{{.*}}gcc{{.*}}" "-rpath" "{{.*}}gcc{{.*}}" "-lc" "-lgcc" "{{.*}}crtend.o" 
"{{.*}}crtn.o"
+// CHECK: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" 
"/usr/libexec/ld-elf.so.{{.*}}" "--hash-style=gnu" "--enable-new-dtags" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" "-L{{.*}}/../lib" 
"-L/usr/lib" "-L/usr/lib/gcc80" "{{.*}}.o" "-rpath" "{{.*}}gcc80{{.*}}" "-lc" 
"-lgcc" "{{.*}}crtend.o" "{{.*}}crtn.o"
 
 // Check x86_64-unknown-dragonfly, X86_64
 // RUN: %clang -### %s 2>&1 --target=x86_64-unknown-dragonfly \
@@ -15,7 +15,8 @@
 // CHECK-LD-X86_64-SAME: 
"[[SYSROOT]]{{/|}}usr{{/|}}lib{{/|}}crt1.o"
 // CHECK-LD-X86_64-SAME: 
"[[SYSROOT]]{{/|}}usr{{/|}}lib{{/|}}crti.o"
 // CHECK-LD-X86_64-SAME: 
"[[SYSROOT]]{{/|}}usr{{/|}}lib{{/|}}gcc80{{/|}}crtbegin.o"
-// CHECK-LD-X86_64-SAME: 
"-L[[SYSROOT]]{{/|}}usr{{/|}}lib{{/|}}gcc80" "-rpath" 
"/usr/lib/gcc80" "-lc" "-lgcc" "--as-needed" "-lgcc_pic" "--no-as-needed"
+// CHECK-LD-X86_64-SAME: "-L[[SYSROOT]]{{/|}}usr{{/|}}lib" 
"-L[[SYSROOT]]{{/|}}usr{{/|}}lib{{/|}}gcc80"
+// CHECK-LD-X86_64-SAME: "-rpath" "/usr/lib/gcc80" "-lc" "-lgcc" "--as-needed" 
"-lgcc_pic" "--no-as-needed"
 // CHECK-LD-X86_64-SAME: 
"[[SYSROOT]]{{/|}}usr{{/|}}lib{{/|}}gcc80{{/|}}crtend.o"
 // CHECK-LD-X86_64-SAME: 
"[[SYSROOT]]{{/|}}usr{{/|}}lib{{/|}}crtn.o"
 
@@ -26,3 +27,8 @@
 // RELOCATABLE-NOT: "-dynamic-linker"
 // RELOCATABLE-NOT: "-l
 // RELOCATABLE-NOT: {{.*}}crt{{[^./]+}}.o
+
+// Check that the new linker flags are passed to DragonFly
+// RUN: %clang --target=x86_64-unknown-dragonfly -s -t -### %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-FLAGS %s
+// CHECK-LD-FLAGS: ld{{.*}}" "{{.*}}" "-s" "-t"
diff --git a/clang/test/Driver/fopenmp.c 

[clang] [CUDA][HIP] Fix host/device context in concept (PR #67721)

[Yaxun Liu via cfe-commits]

@@ -176,3 +176,34 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
  - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
 
+C++20 Concepts with HIP and CUDA
+
+
+In Clang, when working with HIP or CUDA, it's important to note that all 
constraints in C++20 concepts are assumed to be for the host side only. This 
behavior is consistent across both programming models, and developers should be 
aware of this assumption when writing code that utilizes C++20 concepts.
+
+Example:
+.. code-block:: c++
+
+   template 
+   concept MyConcept = requires(T& obj) {
+ my_function(obj);  // Assumed to be a host-side requirement

yxsamliu wrote:

For a typical use case of concept in CUDA programs, please see 
https://godbolt.org/z/o7Wa68n9c

This is taken from issue https://github.com/llvm/llvm-project/issues/67507.

In this example, users want to express two constraints on geometric_shape:

1. it can be passed to a function draw

2. it can be passed to a function area and the result is convertible to double

For the first constraint, users only need it on the host side. For the second 
constraint, users need it on both the host side and the device side. This gives 
us some insight into users' needs for constraints: they are usually different 
for host and device sides, since users may want to do different things on host 
and device sides. Therefore, assuming a constraint in a concept should be 
satisfied on both the device and host sides will result in some unnecessary 
extra constraints on either side.

Is it OK to evaluate the constraints by the context where the template is 
instantiated? For example, when we instantiate the kernel `template 
 __global__ void compute_areas`, can we evaluate the 
constraints in the device context to get what we need? It is not good. Because 
then the constraint about function draw needs to be satisfied on the device 
side. That is not what we need. The point is, that the constraints defined in a 
concept need to have individual required context. We want to be able to express 
that this constraint should be satisfied in the device context, and that 
constraint should be satisfied in the host context. That is why I propose to 
allow `__device__` and `__host__` attributes to be added to the call 
expressions in concepts to indicate the required context for an individual 
constraint.

Now that we have discussed the users' needs regarding device/host contexts of 
constraints. Let's look at how nvcc currently evaluates satisfaction of 
constraints.

Based on https://godbolt.org/z/o7Wa68n9c , the instantiation of 
`work` is successful. We can infer that `triangle` satisfies the two 
constraints. They can only be evaluated in the host context since functions 
`draw` and `area` are all host functions. Even though the instantiation of 
`work` is done in a device context, the evaluation of the constraints 
is still done in the host context.

The current patch matches nvcc's behaviour.

https://github.com/llvm/llvm-project/pull/67721
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HIP] Document func ptr and virtual func (PR #68126)

[via cfe-commits]

https://github.com/b-sumner commented:

Looks good to me.

https://github.com/llvm/llvm-project/pull/68126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HIP] Document func ptr and virtual func (PR #68126)

[Yaxun Liu via cfe-commits]

@@ -176,3 +176,95 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
  - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
 
+Compilation Modes
+=
+
+Each HIP source file contains intertwined device and host code. Depending on 
the chosen compilation mode by the compiler options ``-fno-gpu-rdc`` and 
``-fgpu-rdc``, these portions of code are compiled differently.
+
+Device Code Compilation
+---
+
+**``-fno-gpu-rdc`` Mode (default)**:
+
+- Compiles to a self-contained, fully linked offloading device binary for each 
offloading device architecture.
+- Device code within a Translation Unit (TU) cannot call functions located in 
another TU.
+
+**``-fgpu-rdc`` Mode**:
+
+- Compiles to a bitcode for each GPU architecture.
+- For each offloading device architecture, the bitcode from different TUs are 
linked together to create a single offloading device binary.
+- Device code in one TU can call functions located in another TU.
+
+Host Code Compilation
+-
+
+**Both Modes**:
+
+- Compiles to a relocatable object for each TU.
+- These relocatable objects are then linked together.
+- Host code within a TU can call host functions and launch kernels from 
another TU.
+
+Function Pointers Support
+=
+
+Function pointers' support varies with the usage mode in Clang with HIP. The 
following table provides an overview of the support status across different 
use-cases and modes.
+
+.. list-table:: Function Pointers Support Overview
+   :widths: 25 25 25
+   :header-rows: 1
+
+   * - Use Case
+ - ``-fno-gpu-rdc`` Mode (default)
+ - ``-fgpu-rdc`` Mode
+   * - Defined and used in the same TU
+ - Supported
+ - Supported
+   * - Defined in one TU and used in another TU
+ - Not Supported
+ - Supported
+
+In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of 
kernels based only on functions present within the same TU. This mode does not 
support the use of function pointers defined in a different TU due to the 
possibility of incorrect resource usage calculations, leading to undefined 
behavior.
+
+On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of 
function pointers across different TUs, as resource usage calculations can 
accommodate functions from disparate TUs.
+
+Virtual Function Support
+
+
+In Clang with HIP, support for calling virtual functions of an object in 
device or host code is contingent on where the object is constructed.
+
+- **Constructed in Device Code**: Virtual functions of an object can be called 
in device code on a specific offloading device if the object is constructed in 
device code on an offloading device with the same architecture.
+- **Constructed in Host Code**: Virtual functions of an object can be called 
in host code if the object is constructed in host code.
+
+In other scenarios, calling virtual functions is not allowed.
+
+Explanation
+---
+
+An object constructed on the device side contains a pointer to the virtual 
function table on the device side, which is not accessible in host code, and 
vice versa. Thus, trying to invoke virtual functions from a context different 
from where the object was constructed will be disallowed because the 
appropriate virtual table cannot be accessed. The virtual function tables for 
offloading devices with different architecures are different, therefore trying 
to invoke virtual functions from an offloading device with a different 
architecture than where the object is constructed is also disallowed.
+
+A possible way to alleviate the current limitation of virtual function support 
in HIP is through the use of a "composite vtable". This involves creating a 
vtable that combines those from the host and all offloading device 
architectures, storing it in memory accessible by both. A dedicated 
registration function is introduced to populate this composite vtable. This 
function is invoked during global initialization to ensure the vtable is ready 
before any virtual function calls are made. For every virtual function call, 
irrespective of context, the system refers to this composite vtable to 
determine the correct function execution.

yxsamliu wrote:

removed the paragraph

https://github.com/llvm/llvm-project/pull/68126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HIP] Document func ptr and virtual func (PR #68126)

[Yaxun Liu via cfe-commits]

https://github.com/yxsamliu updated 
https://github.com/llvm/llvm-project/pull/68126

>From 52fa4eac701a411699ac0ffa8386b1b23ba9977e Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu" 
Date: Tue, 3 Oct 2023 12:21:10 -0400
Subject: [PATCH 1/2] [HIP] Document func ptr and virtual func

Document clang support for function pointers and virtual functions with HIP
---
 clang/docs/HIPSupport.rst | 62 +++
 1 file changed, 62 insertions(+)

diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 8b4649733a9c777..63c16c0051153a0 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -176,3 +176,65 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
  - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
 
+Function Pointers Support in Clang with HIP
+===
+
+Function pointers' support varies with the usage mode in Clang with HIP. The 
following table provides an overview of the support status across different 
use-cases and modes.
+
+.. list-table:: Function Pointers Support Overview
+   :widths: 25 25 25
+   :header-rows: 1
+
+   * - Use Case
+ - ``-fno-gpu-rdc`` Mode (default)
+ - ``-fgpu-rdc`` Mode
+   * - Defined and used in the same TU
+ - Supported
+ - Supported
+   * - Defined in one TU and used in another TU
+ - Not Supported
+ - Supported
+
+In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of 
kernels based only on functions present within the same Translation Unit (TU). 
This mode does not support the use of function pointers defined in a different 
TU due to the possibility of incorrect resource usage calculations, leading to 
undefined behavior.
+
+On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of 
function pointers across different TUs, as resource usage calculations can 
accommodate functions from disparate TUs.
+
+Virtual Function Support in Clang with HIP
+==
+
+In Clang with HIP, support for calling virtual functions of an object in 
device or host code is contingent on where the object is constructed.
+
+- **Constructed in Device Code**: Virtual functions of an object can be called 
in device code if the object is constructed in device code.
+- **Constructed in Host Code**: Virtual functions of an object can be called 
in host code if the object is constructed in host code.
+
+In other scenarios, calling virtual functions is not allowed.
+
+Explanation
+---
+
+An object constructed on the device side contains a pointer to the virtual 
function table on the device side, which is not accessible in host code, and 
vice versa. Thus, trying to invoke virtual functions from a context different 
from where the object was constructed will be disallowed because the 
appropriate virtual table cannot be accessed.
+
+Example Usage
+-
+
+.. code-block:: c++
+
+   class Base {
+   public:
+  __device__ virtual void virtualFunction() {
+ // Base virtual function implementation
+  }
+   };
+
+   class Derived : public Base {
+   public:
+  __device__ void virtualFunction() override {
+ // Derived virtual function implementation
+  }
+   };
+
+   __global__ void kernel() {
+  Derived obj;
+  Base* basePtr = 
+  basePtr->virtualFunction(); // Allowed since obj is constructed in 
device code
+   }

>From 60c7fd700a22f22b5d89c3a9086a1962e1827c41 Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu" 
Date: Sat, 7 Oct 2023 10:37:54 -0400
Subject: [PATCH 2/2] [HIP] Document func ptr and virtual func

Document clang support for function pointers and virtual functions with HIP
---
 clang/docs/HIPSupport.rst | 42 ---
 1 file changed, 35 insertions(+), 7 deletions(-)

diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 63c16c0051153a0..84cee45e83ba3c8 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -176,8 +176,36 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
  - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
 
-Function Pointers Support in Clang with HIP
-===
+Compilation Modes
+=
+
+Each HIP source file contains intertwined device and host code. Depending on 
the chosen compilation mode by the compiler options ``-fno-gpu-rdc`` and 
``-fgpu-rdc``, these portions of code are compiled differently.
+
+Device Code Compilation
+---
+
+**``-fno-gpu-rdc`` Mode (default)**:
+
+- Compiles to a self-contained, fully linked offloading device binary for each 
offloading device architecture.
+- Device code within a Translation Unit (TU) cannot call functions located in 
another TU.
+
+**``-fgpu-rdc`` Mode**:
+
+- Compiles to a bitcode for each GPU architecture.
+- For each offloading device architecture, the bitcode from different 

[clang] Correctly link and optimize device libraries with -mlink-builtin-bitcode (PR #69371)

[Yaxun Liu via cfe-commits]

yxsamliu wrote:


> 
>  You could potentially link in all the symbols and internalize them

That probably won't work. After they are internalized, they have internal 
linkage and cannot be used to resolve newly added call of the same function.

The purpose of internalization is to allow you to optimize those functions, 
e.g. changing their signatures. After internalization, there is no guarantee 
they behave like the original functions.


https://github.com/llvm/llvm-project/pull/69371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] [RISCV][GlobalISel] Select G_FRAME_INDEX (PR #68254)

[Nitin John Raj via cfe-commits]

https://github.com/nitinjohnraj closed 
https://github.com/llvm/llvm-project/pull/68254
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [CUDA][HIP] Fix deduction guide (PR #69366)

[Yaxun Liu via cfe-commits]

yxsamliu wrote:

nvcc behavior can be seen here

https://godbolt.org/z/sY1vdYWKe

https://godbolt.org/z/vTer7xa3j

https://github.com/llvm/llvm-project/pull/69366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [CUDA][HIP] Fix deduction guide (PR #69366)

[Yaxun Liu via cfe-commits]

https://github.com/yxsamliu updated 
https://github.com/llvm/llvm-project/pull/69366

>From b28384d33f858a6d4139da931b436cbf1a0a426a Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu" 
Date: Sat, 14 Oct 2023 17:28:13 -0400
Subject: [PATCH] [CUDA][HIP] Fix deduction guide

Currently clang assumes implicit deduction guide to be host
device. This generates two identical implicit deduction
guides when a class have a device and a host constructor
which have the same input parameter, which causes ambiguity.

Since an implicit deduction guide is derived from a constructor,
it should take the same host/device attribute as the originating
constructor. This matches nvcc behavior as seen in
https://godbolt.org/z/sY1vdYWKe and https://godbolt.org/z/vTer7xa3j
---
 clang/docs/HIPSupport.rst  | 55 +
 clang/include/clang/AST/DeclCXX.h  |  9 +--
 clang/lib/AST/DeclCXX.cpp  | 21 +++
 clang/lib/Sema/SemaCUDA.cpp|  5 +-
 clang/lib/Sema/SemaTemplate.cpp| 18 --
 clang/test/SemaCUDA/deduction-guide.cu | 85 ++
 6 files changed, 179 insertions(+), 14 deletions(-)
 create mode 100644 clang/test/SemaCUDA/deduction-guide.cu

diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 8b4649733a9c777..8a9802e19e6367f 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -176,3 +176,58 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
  - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
 
+Support for Deduction Guides
+
+
+Explicit Deduction Guides
+-
+
+Explicit deduction guides in HIP can be annotated with either the
+``__host__`` or ``__device__`` attributes. If no attribute is provided,
+it defaults to ``__host__``.
+
+.. code-block:: cpp
+
+   template 
+   class MyArray {
+   //...
+   };
+
+   template 
+   MyArray(T)->MyArray;
+
+   __device__ MyArray(float)->MyArray;
+
+   // Uses of the deduction guides
+   MyArray arr1 = 10;  // Uses the default host guide
+   __device__ void foo() {
+   MyArray arr2 = 3.14f; // Uses the device guide
+   }
+
+Implicit Deduction Guides
+-
+Implicit deduction guides derived from constructors inherit the same host or
+device attributes as the originating constructor.
+
+.. code-block:: cpp
+
+   template 
+   class MyVector {
+   public:
+   __device__ MyVector(T) { /* ... */ }
+   //...
+   };
+
+   // The implicit deduction guide for MyVector will be `__device__` due to 
the device constructor
+
+   __device__ void foo() {
+   MyVector vec(42);  // Uses the implicit device guide derived from the 
constructor
+   }
+
+Availability Checks
+
+When a deduction guide (either explicit or implicit) is used, HIP checks its
+availability based on its host/device attributes and the context in a similar
+way as checking a function. Utilizing a deduction guide in an incompatible 
context
+results in a compile-time error.
+
diff --git a/clang/include/clang/AST/DeclCXX.h 
b/clang/include/clang/AST/DeclCXX.h
index 5eaae6bdd2bc63e..863ced731d42b2f 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -1948,14 +1948,7 @@ class CXXDeductionGuideDecl : public FunctionDecl {
 ExplicitSpecifier ES,
 const DeclarationNameInfo , QualType T,
 TypeSourceInfo *TInfo, SourceLocation EndLocation,
-CXXConstructorDecl *Ctor, DeductionCandidate Kind)
-  : FunctionDecl(CXXDeductionGuide, C, DC, StartLoc, NameInfo, T, TInfo,
- SC_None, false, false, ConstexprSpecKind::Unspecified),
-Ctor(Ctor), ExplicitSpec(ES) {
-if (EndLocation.isValid())
-  setRangeEnd(EndLocation);
-setDeductionCandidateKind(Kind);
-  }
+CXXConstructorDecl *Ctor, DeductionCandidate Kind);
 
   CXXConstructorDecl *Ctor;
   ExplicitSpecifier ExplicitSpec;
diff --git a/clang/lib/AST/DeclCXX.cpp b/clang/lib/AST/DeclCXX.cpp
index 9107525a44f22c2..e0683173e24f440 100644
--- a/clang/lib/AST/DeclCXX.cpp
+++ b/clang/lib/AST/DeclCXX.cpp
@@ -2113,6 +2113,27 @@ ExplicitSpecifier 
ExplicitSpecifier::getFromDecl(FunctionDecl *Function) {
   }
 }
 
+CXXDeductionGuideDecl::CXXDeductionGuideDecl(
+ASTContext , DeclContext *DC, SourceLocation StartLoc,
+ExplicitSpecifier ES, const DeclarationNameInfo , QualType T,
+TypeSourceInfo *TInfo, SourceLocation EndLocation, CXXConstructorDecl 
*Ctor,
+DeductionCandidate Kind)
+: FunctionDecl(CXXDeductionGuide, C, DC, StartLoc, NameInfo, T, TInfo,
+   SC_None, false, false, ConstexprSpecKind::Unspecified),
+  Ctor(Ctor), ExplicitSpec(ES) {
+  if (EndLocation.isValid())
+setRangeEnd(EndLocation);
+  setDeductionCandidateKind(Kind);
+  // If Ctor is not nullptr, this deduction guide is implicitly derived from
+  // 

[clang] [flang][driver] support -dumpversion and -dumpmachine (PR #68896)

[Yuanfang Chen via cfe-commits]

yuanfang-chen wrote:

> Could this be implemented without any updates to Clang (beyond Options.td)?

The options could work by changing options.td only. However,  
`CLANG_VERSION_STRING` and `FLANG_VERSION_STRING` could be different. This is 
to handle that.

https://github.com/llvm/llvm-project/pull/68896
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-format] Fix a bug in annotating TrailingReturnArrow (PR #69249)

[Owen Pan via cfe-commits]

@@ -3497,6 +3497,15 @@ void 
TokenAnnotator::calculateFormattingInformation(AnnotatedLine ) const {
   Tok->setType(TT_TrailingReturnArrow);
   break;
 }
+if (Tok->isNot(TT_TrailingAnnotation))

owenca wrote:

Before: look for _any_ arrow after the `r_paren` of the function declaration.
Now: look for any arrow _except_ when inside the parentheses after a 
`TT_TrailingAnnotation`.

The case where `Next` is `nullptr` is handled by the condition of the `for` 
loop whereas any tokens (including non-`l_parens`) before a 
`TT_TrailingAnnotation` should be skipped as before.


https://github.com/llvm/llvm-project/pull/69249
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libc++] Fix inconsistency between is_lock_free and is_always_lock_free (PR #68109)

[Louis Dionne via cfe-commits]

https://github.com/ldionne updated 
https://github.com/llvm/llvm-project/pull/68109

>From 84ae453ad32cad94038bdb1e91b4b5c422f3ceb3 Mon Sep 17 00:00:00 2001
From: Louis Dionne 
Date: Tue, 3 Oct 2023 10:06:12 -0400
Subject: [PATCH 1/2] [libc++] Fix inconsistency between is_lock_free and
 is_always_lock_free

std::atomic is implemented with the following (confusing!) hierarchy of
types:

 std::atomic : std::__atomic_base { ... };
 std::__atomic_base {
  std::__cxx_atomic_impl __impl;
 };
 std::__cxx_atomic_impl {
  _Atomic(T) __val;
 };

Inside std::__atomic_base, we implement the is_lock_free() and
is_always_lock_free() functions. However, we used to implement them
inconsistently:
- is_always_lock_free() is based on whether __cxx_atomic_impl is always
  lock free (using the builtin), which means that we include any potential
  padding added by _Atomic(T) into the determination.
- is_lock_free() was based on whether T is lock free (using the builtin),
  which meant that we did not take into account any potential padding
  added by _Atomic(T).

It is important to note that the padding added by _Atomic(T) can turn a
type that wouldn't be lock free into a lock free type, for example by
making its size become a power of two.

The inconsistency of how the two functions were implemented could lead
to cases where is_always_lock_free() would return true, but is_lock_free()
would then return false. This is the case for example of the following
type, which is always lock free on arm64 but was incorrectly reported as
!is_lock_free() before this patch:

 struct Foo { float x[3]; };

This patch switches the determination of is_lock_free() to be based on
__cxx_atomic_impl instead to match how we determine is_always_lock_free().

rdar://115324353
---
 libcxx/include/__atomic/atomic_base.h |  2 +-
 .../atomics/atomics.align/align.pass.cpp  |  1 +
 .../isalwayslockfree.pass.cpp |  2 +-
 .../atomics.types.generic/address.pass.cpp|  7 +--
 .../atomics.types.generic/bool.pass.cpp   | 21 +--
 .../atomics.types.generic/integral.pass.cpp   |  7 +--
 .../atomic_is_lock_free.pass.cpp  |  4 
 7 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/libcxx/include/__atomic/atomic_base.h 
b/libcxx/include/__atomic/atomic_base.h
index 87100ba5d8a50db..775d06d75701833 100644
--- a/libcxx/include/__atomic/atomic_base.h
+++ b/libcxx/include/__atomic/atomic_base.h
@@ -39,7 +39,7 @@ struct __atomic_base  // false
 
 _LIBCPP_HIDE_FROM_ABI
 bool is_lock_free() const volatile _NOEXCEPT
-{return __cxx_atomic_is_lock_free(sizeof(_Tp));}
+{return __cxx_atomic_is_lock_free(sizeof(__cxx_atomic_impl<_Tp>));}
 _LIBCPP_HIDE_FROM_ABI
 bool is_lock_free() const _NOEXCEPT
 {return static_cast<__atomic_base const 
volatile*>(this)->is_lock_free();}
diff --git a/libcxx/test/libcxx/atomics/atomics.align/align.pass.cpp 
b/libcxx/test/libcxx/atomics/atomics.align/align.pass.cpp
index 495d02fbe5c8d44..f9e01bd5d032bd8 100644
--- a/libcxx/test/libcxx/atomics/atomics.align/align.pass.cpp
+++ b/libcxx/test/libcxx/atomics/atomics.align/align.pass.cpp
@@ -100,6 +100,7 @@ int main(int, char**) {
   CHECK_ALIGNMENT(struct Empty {});
   CHECK_ALIGNMENT(struct OneInt { int i; });
   CHECK_ALIGNMENT(struct IntArr2 { int i[2]; });
+  CHECK_ALIGNMENT(struct FloatArr3 { float i[3]; });
   CHECK_ALIGNMENT(struct LLIArr2 { long long int i[2]; });
   CHECK_ALIGNMENT(struct LLIArr4 { long long int i[4]; });
   CHECK_ALIGNMENT(struct LLIArr8 { long long int i[8]; });
diff --git a/libcxx/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp 
b/libcxx/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp
index b2d83f0a6fe8814..6d6e6477bc2511e 100644
--- a/libcxx/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp
+++ b/libcxx/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp
@@ -21,7 +21,6 @@
 template 
 void checkAlwaysLockFree() {
   if (std::atomic::is_always_lock_free) {
-LIBCPP_ASSERT(sizeof(std::atomic) == sizeof(T)); // technically not 
required, but libc++ does it that way
 assert(std::atomic().is_lock_free());
   }
 }
@@ -79,6 +78,7 @@ void run()
 CHECK_ALWAYS_LOCK_FREE(struct Empty {});
 CHECK_ALWAYS_LOCK_FREE(struct OneInt { int i; });
 CHECK_ALWAYS_LOCK_FREE(struct IntArr2 { int i[2]; });
+CHECK_ALWAYS_LOCK_FREE(struct FloatArr3 { float i[3]; });
 CHECK_ALWAYS_LOCK_FREE(struct LLIArr2 { long long int i[2]; });
 CHECK_ALWAYS_LOCK_FREE(struct LLIArr4 { long long int i[4]; });
 CHECK_ALWAYS_LOCK_FREE(struct LLIArr8 { long long int i[8]; });
diff --git a/libcxx/test/std/atomics/atomics.types.generic/address.pass.cpp 
b/libcxx/test/std/atomics/atomics.types.generic/address.pass.cpp
index b3aa1fc47629a3b..f5119cc74821bf2 100644
--- a/libcxx/test/std/atomics/atomics.types.generic/address.pass.cpp
+++ 

[clang-tools-extra] [libc++] Fix inconsistency between is_lock_free and is_always_lock_free (PR #68109)

[Louis Dionne via cfe-commits]

https://github.com/ldionne updated 
https://github.com/llvm/llvm-project/pull/68109

>From 84ae453ad32cad94038bdb1e91b4b5c422f3ceb3 Mon Sep 17 00:00:00 2001
From: Louis Dionne 
Date: Tue, 3 Oct 2023 10:06:12 -0400
Subject: [PATCH 1/2] [libc++] Fix inconsistency between is_lock_free and
 is_always_lock_free

std::atomic is implemented with the following (confusing!) hierarchy of
types:

 std::atomic : std::__atomic_base { ... };
 std::__atomic_base {
  std::__cxx_atomic_impl __impl;
 };
 std::__cxx_atomic_impl {
  _Atomic(T) __val;
 };

Inside std::__atomic_base, we implement the is_lock_free() and
is_always_lock_free() functions. However, we used to implement them
inconsistently:
- is_always_lock_free() is based on whether __cxx_atomic_impl is always
  lock free (using the builtin), which means that we include any potential
  padding added by _Atomic(T) into the determination.
- is_lock_free() was based on whether T is lock free (using the builtin),
  which meant that we did not take into account any potential padding
  added by _Atomic(T).

It is important to note that the padding added by _Atomic(T) can turn a
type that wouldn't be lock free into a lock free type, for example by
making its size become a power of two.

The inconsistency of how the two functions were implemented could lead
to cases where is_always_lock_free() would return true, but is_lock_free()
would then return false. This is the case for example of the following
type, which is always lock free on arm64 but was incorrectly reported as
!is_lock_free() before this patch:

 struct Foo { float x[3]; };

This patch switches the determination of is_lock_free() to be based on
__cxx_atomic_impl instead to match how we determine is_always_lock_free().

rdar://115324353
---
 libcxx/include/__atomic/atomic_base.h |  2 +-
 .../atomics/atomics.align/align.pass.cpp  |  1 +
 .../isalwayslockfree.pass.cpp |  2 +-
 .../atomics.types.generic/address.pass.cpp|  7 +--
 .../atomics.types.generic/bool.pass.cpp   | 21 +--
 .../atomics.types.generic/integral.pass.cpp   |  7 +--
 .../atomic_is_lock_free.pass.cpp  |  4 
 7 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/libcxx/include/__atomic/atomic_base.h 
b/libcxx/include/__atomic/atomic_base.h
index 87100ba5d8a50db..775d06d75701833 100644
--- a/libcxx/include/__atomic/atomic_base.h
+++ b/libcxx/include/__atomic/atomic_base.h
@@ -39,7 +39,7 @@ struct __atomic_base  // false
 
 _LIBCPP_HIDE_FROM_ABI
 bool is_lock_free() const volatile _NOEXCEPT
-{return __cxx_atomic_is_lock_free(sizeof(_Tp));}
+{return __cxx_atomic_is_lock_free(sizeof(__cxx_atomic_impl<_Tp>));}
 _LIBCPP_HIDE_FROM_ABI
 bool is_lock_free() const _NOEXCEPT
 {return static_cast<__atomic_base const 
volatile*>(this)->is_lock_free();}
diff --git a/libcxx/test/libcxx/atomics/atomics.align/align.pass.cpp 
b/libcxx/test/libcxx/atomics/atomics.align/align.pass.cpp
index 495d02fbe5c8d44..f9e01bd5d032bd8 100644
--- a/libcxx/test/libcxx/atomics/atomics.align/align.pass.cpp
+++ b/libcxx/test/libcxx/atomics/atomics.align/align.pass.cpp
@@ -100,6 +100,7 @@ int main(int, char**) {
   CHECK_ALIGNMENT(struct Empty {});
   CHECK_ALIGNMENT(struct OneInt { int i; });
   CHECK_ALIGNMENT(struct IntArr2 { int i[2]; });
+  CHECK_ALIGNMENT(struct FloatArr3 { float i[3]; });
   CHECK_ALIGNMENT(struct LLIArr2 { long long int i[2]; });
   CHECK_ALIGNMENT(struct LLIArr4 { long long int i[4]; });
   CHECK_ALIGNMENT(struct LLIArr8 { long long int i[8]; });
diff --git a/libcxx/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp 
b/libcxx/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp
index b2d83f0a6fe8814..6d6e6477bc2511e 100644
--- a/libcxx/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp
+++ b/libcxx/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp
@@ -21,7 +21,6 @@
 template 
 void checkAlwaysLockFree() {
   if (std::atomic::is_always_lock_free) {
-LIBCPP_ASSERT(sizeof(std::atomic) == sizeof(T)); // technically not 
required, but libc++ does it that way
 assert(std::atomic().is_lock_free());
   }
 }
@@ -79,6 +78,7 @@ void run()
 CHECK_ALWAYS_LOCK_FREE(struct Empty {});
 CHECK_ALWAYS_LOCK_FREE(struct OneInt { int i; });
 CHECK_ALWAYS_LOCK_FREE(struct IntArr2 { int i[2]; });
+CHECK_ALWAYS_LOCK_FREE(struct FloatArr3 { float i[3]; });
 CHECK_ALWAYS_LOCK_FREE(struct LLIArr2 { long long int i[2]; });
 CHECK_ALWAYS_LOCK_FREE(struct LLIArr4 { long long int i[4]; });
 CHECK_ALWAYS_LOCK_FREE(struct LLIArr8 { long long int i[8]; });
diff --git a/libcxx/test/std/atomics/atomics.types.generic/address.pass.cpp 
b/libcxx/test/std/atomics/atomics.types.generic/address.pass.cpp
index b3aa1fc47629a3b..f5119cc74821bf2 100644
--- a/libcxx/test/std/atomics/atomics.types.generic/address.pass.cpp
+++ 

[clang] Reapply "[clang analysis][thread-safety] Handle return-by-reference..… (PR #68572)

[Aaron Puchert via cfe-commits]

@@ -1061,11 +1061,13 @@ def Most : DiagGroup<"most", [
  ]>;
 
 // Thread Safety warnings
-def ThreadSafetyAttributes : DiagGroup<"thread-safety-attributes">;
-def ThreadSafetyAnalysis   : DiagGroup<"thread-safety-analysis">;
-def ThreadSafetyPrecise: DiagGroup<"thread-safety-precise">;
-def ThreadSafetyReference  : DiagGroup<"thread-safety-reference">;
-def ThreadSafetyNegative   : DiagGroup<"thread-safety-negative">;
+def ThreadSafetyAttributes   : DiagGroup<"thread-safety-attributes">;
+def ThreadSafetyAnalysis : DiagGroup<"thread-safety-analysis">;
+def ThreadSafetyPrecise  : DiagGroup<"thread-safety-precise">;

aaronpuchert wrote:

I would suggest to undo the indentation changes here, as the flag is intended 
to be temporary.

https://github.com/llvm/llvm-project/pull/68572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Reapply "[clang analysis][thread-safety] Handle return-by-reference..… (PR #68572)

[Aaron Puchert via cfe-commits]

@@ -2278,7 +2303,7 @@ void 
ThreadSafetyAnalyzer::runAnalysis(AnalysisDeclContext ) {
   PostOrderCFGView::CFGBlockSet VisitedBlocks(CFGraph);
 
   CFGBlockInfo  = BlockInfo[CFGraph->getEntry().getBlockID()];
-  CFGBlockInfo= BlockInfo[CFGraph->getExit().getBlockID()];
+  CFGBlockInfo  = BlockInfo[CFGraph->getExit().getBlockID()];

aaronpuchert wrote:

This change seems unnecessary, but I don't mind either way.

https://github.com/llvm/llvm-project/pull/68572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Reapply "[clang analysis][thread-safety] Handle return-by-reference..… (PR #68572)

[Aaron Puchert via cfe-commits]

https://github.com/aaronpuchert approved this pull request.

Assuming that this is otherwise identical to the Phab review. I would suggest 
to add some release notes (in a separate change).

https://github.com/llvm/llvm-project/pull/68572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Reapply "[clang analysis][thread-safety] Handle return-by-reference..… (PR #68572)

[Aaron Puchert via cfe-commits]

https://github.com/aaronpuchert edited 
https://github.com/llvm/llvm-project/pull/68572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Sema] Use original template pattern when declaring implicit deduction guides for nested template classes (PR #68379)

[Paul Kirth via cfe-commits]

ilovepi wrote:

I think your analysis and approach sounds correct, but probably worth checking 
with someone a bit more familiar with all of the C++ nuance here.

https://github.com/llvm/llvm-project/pull/68379
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Correctly link and optimize device libraries with -mlink-builtin-bitcode (PR #69371)

[Joseph Huber via cfe-commits]

jhuber6 wrote:

> > This approach assumes that whatever the function call was transformed into 
> > also exists in the same library, which isn't necessarily true.
> 
> True, good point. But I don't think it's necessarily due to this approach, 
> but more of how AMDGPULibCalls is implemented. It seems like the instruction 
> folding implementations are assuming the definitions of the new functions 
> they're inserting will be linked in at a later point?
>
> Previously we were doing it via a separate _llvm-link_ call to re-link all 
> the device libraries. With this approach, we're doing it as part of the clang 
> optimization pipeline, and would no longer need that extra link step.
> 
> Maybe this approach could be a solution for the time being? With a longer 
> term solution being to think more carefully about the legality of 
> AMDGPULibCalls inserting function calls that may or may not exist? Maybe 
> device library calls are the exception?

This is part of why I'm not very happy with the current approach to just 
`-mlink-builtin-bitcode` everything and hope it works. We actually had similar 
issues with the `OpenMPOpt`  pass as it would emit OpenMP runtime calls after 
the device library was already linked. The solution there was to simply guard 
emission of function calls to only be possible if we are either executing the 
optimizations pre-linking, or if the function call already exists in the 
module. I think this is a much easier fix than making this already quite 
complicated solution even more complicated. However, this would prevent these 
optimizations from firing without fixing it in other ways.

Generally this occurs because `-mlink-builtin-bitcode` only links *needed* 
symbols, so other ones are ignored. I think there's a few hacks in the ROCm 
device libs to get around this, such as emitting a `printf` symbol that only 
calls `__printf_alloc` so that it can be called. You could potentially link in 
all the symbols and internalize them, assuming that a future DCE or global opt 
pass will trim it down, but that would require some phase ordering to make sure 
this AMDGPULibCalls pass is run first.

https://github.com/llvm/llvm-project/pull/69371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Sema] Use original template pattern when declaring implicit deduction guides for nested template classes (PR #68379)

[via cfe-commits]

antangelo wrote:

When `SubstType` is called on the `const inner &` parameter to substitute the 
outer template args, it eventually calls `FindInstantiatedDecl` on the inner 
template pattern. The presence of the explicit deduction guide causes the outer 
template to already be instantiated at this point.

As a result `FindInstantiatedDecl` attempts to look for the inner template 
within the instantiated outer template. This fails because the inner template 
args are not known (so the inner template cannot have been instantiated at this 
point).

I think that in this case, if the decl passed into `FindInstantiatedDecl` is a 
`CXXRecordDecl` with a described template, and its context is dependent at the 
given template arguments' level, `FindInstantiatedDecl` should return the 
template pattern. Does that make sense, or is it off the mark?

https://github.com/llvm/llvm-project/pull/68379
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libc++] Add assertions for potential OOB reads in std::nth_element (PR #67023)

[via cfe-commits]

philnik777 wrote:

You can use `// NOLINT(check-name)` or `// NOLINTNEXTLINE(check-name)` to 
disable clang-tidy warnings. I would probably put a `// 
NOLINTNEXTLINE(readability-function-cognitive-complexity)` above the function.

https://github.com/llvm/llvm-project/pull/67023
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [libc++] Add assertions for potential OOB reads in std::nth_element (PR #67023)

[via cfe-commits]

philnik777 wrote:

You can use `// NOLINT(check-name)` or `// NOLINTNEXTLINE(check-name)` to 
disable clang-tidy warnings. I would probably put a `// 
NOLINTNEXTLINE(readability-function-cognitive-complexity)` above the function.

https://github.com/llvm/llvm-project/pull/67023
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-format] Fix a bug in annotating TrailingReturnArrow (PR #69249)

[Björn Schäpers via cfe-commits]

@@ -3497,6 +3497,15 @@ void 
TokenAnnotator::calculateFormattingInformation(AnnotatedLine ) const {
   Tok->setType(TT_TrailingReturnArrow);
   break;
 }
+if (Tok->isNot(TT_TrailingAnnotation))

HazardyKnusperkeks wrote:

But why? If there is no `Next` or it isn't a `l_paren` we also `continue`, 
shouldn't all that match to `TT_TrailingAnnotation`?

https://github.com/llvm/llvm-project/pull/69249
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-format] Fix a bug in annotating TrailingReturnArrow (PR #69249)

[Björn Schäpers via cfe-commits]

https://github.com/HazardyKnusperkeks approved this pull request.


https://github.com/llvm/llvm-project/pull/69249
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-format] Fix a bug in annotating TrailingReturnArrow (PR #69249)

[Björn Schäpers via cfe-commits]

https://github.com/HazardyKnusperkeks edited 
https://github.com/llvm/llvm-project/pull/69249
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [libc++] Add assertions for potential OOB reads in std::nth_element (PR #67023)

[Louis Dionne via cfe-commits]

ldionne wrote:

> That depends on what we want to do with these kinds of issues in general. I 
> think we should avoid making functions so complex. If we have a general 
> consensus there, I think we should just suppress the warning with a todo that 
> the function should be split up (or simplified some other way).

I think I agree. I just looked at the function and if this were code being 
committed today, it would likely never pass code review in that state (I'm not 
judging what was done at that time, but realistically we would ask for the 
function to be broken up -- I think).

@philnik777 is there a way to turn off clang-tidy warnings selectively? Do we 
simply use the usual pragma to disable diagnostics?

https://github.com/llvm/llvm-project/pull/67023
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Correctly link and optimize device libraries with -mlink-builtin-bitcode (PR #69371)

[Jacob Lambert via cfe-commits]

lamb-j wrote:

> This approach assumes that whatever the function call was transformed into 
> also exists in the same library, which isn't necessarily true.

True, good point. But I don't think it's necessarily due to this approach, but 
more of how AMDGPULibCalls is implemented. It seems like the instruction 
folding implementations are assuming the definitions of the new functions 
they're inserting will be linked in at a later point?

Previously we were doing it via a separate _llvm-link_ call to re-link all the 
device libraries. With this approach, we're doing it as part of the clang 
optimization pipeline, and would no longer need that extra link step.

Maybe this approach could be a solution for the time being? With a longer term 
solution being to think more carefully about the legality of AMDGPULibCalls 
inserting function calls that may or may not exist? Maybe device library calls 
are the exception?



https://github.com/llvm/llvm-project/pull/69371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] Emit annotations for function declarations. (PR #66716)

[Brendan Dahl via cfe-commits]

brendandahl wrote:

@AaronBallman or @efriedma-quic ping are you able to add reviewers?

https://github.com/llvm/llvm-project/pull/66716
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] Add check to diagnose coroutine-hostile RAII objects (PR #68738)

[Sam McCall via cfe-commits]

@@ -0,0 +1,98 @@
+//===--- CoroutineHostileRAII.cpp - clang-tidy 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "CoroutineHostileRAIICheck.h"
+#include "../utils/OptionsUtils.h"
+#include "clang/AST/Attr.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/ExprCXX.h"
+#include "clang/AST/Stmt.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersInternal.h"
+#include "clang/Basic/AttrKinds.h"
+#include "clang/Basic/DiagnosticIDs.h"
+
+using namespace clang::ast_matchers;
+namespace clang::tidy::misc {
+namespace {
+using clang::ast_matchers::internal::BoundNodesTreeBuilder;
+
+AST_MATCHER_P(Stmt, forEachPrevStmt, ast_matchers::internal::Matcher,

sam-mccall wrote:

even for an locally-defined matcher, it would be helpful to have a comment on 
what this matcher does (the definition of "before" is non-obvious).

I also don't think its contract makes much sense: the definition of `before` 
excludes this:
```
{
  ; // this EmptyStmt is surely "before"...
}
; // this one
```

This is not just an implementation limitation but important to correctness, 
because we're really talking about variable scope (*initialized* before, but 
destroyed after).

But if that's the case, the matcher should also be named differently, and it 
should yield only `VarDecls`, because what it does doesn't make sense for 
anything except variables.

https://github.com/llvm/llvm-project/pull/68738
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] Add check to diagnose coroutine-hostile RAII objects (PR #68738)

[Sam McCall via cfe-commits]

https://github.com/sam-mccall edited 
https://github.com/llvm/llvm-project/pull/68738
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] Add check to diagnose coroutine-hostile RAII objects (PR #68738)

[Sam McCall via cfe-commits]

@@ -0,0 +1,98 @@
+//===--- CoroutineHostileRAII.cpp - clang-tidy 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "CoroutineHostileRAIICheck.h"
+#include "../utils/OptionsUtils.h"
+#include "clang/AST/Attr.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/ExprCXX.h"
+#include "clang/AST/Stmt.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersInternal.h"
+#include "clang/Basic/AttrKinds.h"
+#include "clang/Basic/DiagnosticIDs.h"
+
+using namespace clang::ast_matchers;
+namespace clang::tidy::misc {
+namespace {
+using clang::ast_matchers::internal::BoundNodesTreeBuilder;
+
+AST_MATCHER_P(Stmt, forEachPrevStmt, ast_matchers::internal::Matcher,
+  InnerMatcher) {
+  DynTypedNode P;
+  bool IsHostile = false;
+  for (const Stmt *Child =  Child; Child = P.get()) {
+auto Parents = Finder->getASTContext().getParents(*Child);
+if (Parents.empty())
+  break;
+P = *Parents.begin();
+auto *PCS = P.get();
+if (!PCS)
+  continue;
+for (const auto  : PCS->children()) {
+  // Child contains suspension. Siblings after Child do not persist across
+  // this suspension.
+  if (Sibling == Child)
+break;
+  // In case of a match, add the bindings as a separate match. Also don't
+  // clear the bindings if a match is not found (unlike Matcher::matches).
+  BoundNodesTreeBuilder SiblingBuilder;
+  if (InnerMatcher.matches(*Sibling, Finder, )) {
+Builder->addMatch(SiblingBuilder);
+IsHostile = true;
+  }
+}
+  }
+  return IsHostile;
+}
+} // namespace
+
+CoroutineHostileRAIICheck::CoroutineHostileRAIICheck(StringRef Name,
+ ClangTidyContext *Context)
+: ClangTidyCheck(Name, Context),
+  RAIITypesList(utils::options::parseStringList(
+  Options.get("RAIITypesList", "std::lock_guard;std::scoped_lock"))) {}
+
+void CoroutineHostileRAIICheck::registerMatchers(MatchFinder *Finder) {
+  // A suspension happens with co_await or co_yield.
+  auto ScopedLockable = varDecl(hasType(hasCanonicalType(hasDeclaration(
+hasAttr(attr::Kind::ScopedLockable)
+.bind("scoped-lockable");
+  auto OtherRAII = varDecl(hasType(hasCanonicalType(hasDeclaration(
+   namedDecl(hasAnyName(RAIITypesList))
+   .bind("raii");
+  Finder->addMatcher(expr(anyOf(coawaitExpr(), coyieldExpr()),
+  forEachPrevStmt(declStmt(forEach(

sam-mccall wrote:

this implies a quadratic algorithm: every suspend point is going to walk every 
prior statement. (the matcher framework has memoization but it won't apply 
here).

It may well be fine in practice, and I don't really have a better suggestion - 
leaning heavily on matchers is idiomatic in clang-tidy, and is rarely efficient 
:-) No action needed here.

https://github.com/llvm/llvm-project/pull/68738
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] Add check to diagnose coroutine-hostile RAII objects (PR #68738)

[Sam McCall via cfe-commits]

@@ -0,0 +1,50 @@
+.. title:: clang-tidy - misc-coroutine-hostile-raii
+
+misc-coroutine-hostile-raii
+
+
+Detects when objects of certain hostile RAII types persists across suspension
+points in a coroutine. Such hostile types include scoped-lockable types and
+types belonging to a configurable denylist.
+
+Some objects require that they be destroyed on the same thread that created 
them. 
+Traditionally this requirement was often phrased as "must be a local variable",
+under the assumption that local variables always work this way. However this is
+incorrect with C++20 coroutines, since an intervening ``co_await`` may cause 
the
+coroutine to suspend and later be resumed on another thread.
+
+The lifetime of an object that requires being destroyed on the same thread 
must 
+not encompass a ``co_await`` or ``co_yield`` point. If you create/destroy an 
object,
+you must do so without allowing the coroutine to suspend in the meantime.
+
+Following types are considered as hostile:
+
+ - Scoped-lockable types: A scoped-lockable object persisting across a 
suspension
+ point is problematic as the lock held by this object could be unlocked by a 
+ different thread. This would be undefined behaviour.
+ This includes all types annotated with the ``scoped_lockable`` attribute.

sam-mccall wrote:

it's kind of unfortunate that do this based on `lock_guard` when it's `mutex` 
that's the problem. I see instances of `lock_guard` being used with spinlocks, 
which seem like they should be fine in coroutines.

But in practice this seems like a really useful heuristic, and I don't have a 
better suggestion. Maybe it'll need refinement in future.

https://github.com/llvm/llvm-project/pull/68738
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] Add check to diagnose coroutine-hostile RAII objects (PR #68738)

[Sam McCall via cfe-commits]

@@ -0,0 +1,50 @@
+.. title:: clang-tidy - misc-coroutine-hostile-raii
+
+misc-coroutine-hostile-raii
+
+
+Detects when objects of certain hostile RAII types persists across suspension
+points in a coroutine. Such hostile types include scoped-lockable types and
+types belonging to a configurable denylist.
+
+Some objects require that they be destroyed on the same thread that created 
them. 
+Traditionally this requirement was often phrased as "must be a local variable",
+under the assumption that local variables always work this way. However this is
+incorrect with C++20 coroutines, since an intervening ``co_await`` may cause 
the
+coroutine to suspend and later be resumed on another thread.
+
+The lifetime of an object that requires being destroyed on the same thread 
must 
+not encompass a ``co_await`` or ``co_yield`` point. If you create/destroy an 
object,
+you must do so without allowing the coroutine to suspend in the meantime.
+
+Following types are considered as hostile:
+
+ - Scoped-lockable types: A scoped-lockable object persisting across a 
suspension
+ point is problematic as the lock held by this object could be unlocked by a 
+ different thread. This would be undefined behaviour.
+ This includes all types annotated with the ``scoped_lockable`` attribute.

sam-mccall wrote:

is it worth mentioning that/why `unique_lock` is ignored?

https://github.com/llvm/llvm-project/pull/68738
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] Add check to diagnose coroutine-hostile RAII objects (PR #68738)

[Sam McCall via cfe-commits]

@@ -0,0 +1,50 @@
+.. title:: clang-tidy - misc-coroutine-hostile-raii
+
+misc-coroutine-hostile-raii
+
+
+Detects when objects of certain hostile RAII types persists across suspension
+points in a coroutine. Such hostile types include scoped-lockable types and
+types belonging to a configurable denylist.
+
+Some objects require that they be destroyed on the same thread that created 
them. 
+Traditionally this requirement was often phrased as "must be a local variable",
+under the assumption that local variables always work this way. However this is
+incorrect with C++20 coroutines, since an intervening ``co_await`` may cause 
the
+coroutine to suspend and later be resumed on another thread.
+
+The lifetime of an object that requires being destroyed on the same thread 
must 
+not encompass a ``co_await`` or ``co_yield`` point. If you create/destroy an 
object,
+you must do so without allowing the coroutine to suspend in the meantime.
+
+Following types are considered as hostile:
+
+ - Scoped-lockable types: A scoped-lockable object persisting across a 
suspension
+ point is problematic as the lock held by this object could be unlocked by a 
+ different thread. This would be undefined behaviour.
+ This includes all types annotated with the ``scoped_lockable`` attribute.
+
+ - Types belonging to a configurable denylist.
+
+.. code-block:: c++
+
+  // Call some async API while holding a lock.
+  {
+const my::MutexLock l(_);

sam-mccall wrote:

seems preferable to use std::lock_guard in the docs!

https://github.com/llvm/llvm-project/pull/68738
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] Add check to diagnose coroutine-hostile RAII objects (PR #68738)

[Sam McCall via cfe-commits]

https://github.com/sam-mccall commented:

Sorry to arrive late with this.

This looks pretty solid, all comments optional, happy to stamp a followup 
commit if you find them useful.

https://github.com/llvm/llvm-project/pull/68738
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver] Remove identifier with the comment (PR #68351)

[Fangrui Song via cfe-commits]

MaskRay wrote:

Add `NFC`?

https://github.com/llvm/llvm-project/pull/68351
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver] Remove identifier with the comment (PR #68351)

[Fangrui Song via cfe-commits]

https://github.com/MaskRay approved this pull request.


https://github.com/llvm/llvm-project/pull/68351
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [SystemZ][z/OS] This change adds support for the PPA2 section in zOS (PR #68926)

[Yusra Syeda via cfe-commits]

@@ -976,6 +976,24 @@ void CodeGenModule::Release() {
   Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
   getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
 
+  if (getTriple().isOSzOS()) {
+int32_t ProductVersion, ProductRelease, ProductPatch;
+ProductVersion = LLVM_VERSION_MAJOR, ProductRelease = LLVM_VERSION_MINOR,
+ProductPatch = LLVM_VERSION_PATCH;
+getModule().addModuleFlag(llvm::Module::Warning, "Product Major Version",
+  ProductVersion);
+getModule().addModuleFlag(llvm::Module::Warning, "Product Minor Version",
+  ProductRelease);
+getModule().addModuleFlag(llvm::Module::Warning, "Product Patchlevel",
+  ProductPatch);

ysyeda wrote:

This has been changed to use the `CLANG_VERSION_MAJOR`, `CLANG_VERSION_MINOR`, 
etc.

https://github.com/llvm/llvm-project/pull/68926
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [SystemZ][z/OS] This change adds support for the PPA2 section in zOS (PR #68926)

[Yusra Syeda via cfe-commits]

@@ -976,6 +976,24 @@ void CodeGenModule::Release() {
   Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
   getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
 
+  if (getTriple().isOSzOS()) {
+int32_t ProductVersion, ProductRelease, ProductPatch;
+ProductVersion = LLVM_VERSION_MAJOR, ProductRelease = LLVM_VERSION_MINOR,
+ProductPatch = LLVM_VERSION_PATCH;

ysyeda wrote:

No, I've removed the extra variables.

https://github.com/llvm/llvm-project/pull/68926
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [SystemZ][z/OS] This change adds support for the PPA2 section in zOS (PR #68926)

[Yusra Syeda via cfe-commits]

@@ -1296,6 +1372,124 @@ void SystemZAsmPrinter::emitPPA1(MCSymbol *FnEndSym) {
   4);
 }
 
+void SystemZAsmPrinter::emitStartOfAsmFile(Module ) {
+  if (TM.getTargetTriple().isOSzOS())
+emitPPA2(M);
+  AsmPrinter::emitStartOfAsmFile(M);
+}
+
+void SystemZAsmPrinter::emitPPA2(Module ) {
+  OutStreamer->pushSection();
+  OutStreamer->switchSection(getObjFileLowering().getPPA2Section());
+  MCContext  = OutStreamer->getContext();
+  // Make CELQSTRT symbol.
+  const char *StartSymbolName = "CELQSTRT";
+  MCSymbol *CELQSTRT = OutContext.getOrCreateSymbol(StartSymbolName);
+
+  // Create symbol and assign to class field for use in PPA1.
+  PPA2Sym = OutContext.createTempSymbol("PPA2", false);
+  MCSymbol *DateVersionSym = OutContext.createTempSymbol("DVS", false);
+
+  std::time_t Time = TranslationTime;
+  SmallString<15> CompilationTime; // 14 + null
+  raw_svector_ostream O(CompilationTime);
+  O << formatv("{0:%Y%m%d%H%M%S}", llvm::sys::toUtcTime(Time));
+
+  uint32_t ProductVersion = getProductVersion(M),
+   ProductRelease = getProductRelease(M),
+   ProductPatch = getProductPatch(M);
+
+  SmallString<7> Version; // 6 + null
+  raw_svector_ostream ostr(Version);
+  ostr << formatv("{0,0-2:d}{1,0-2:d}{2,0-2:d}", ProductVersion, 
ProductRelease,
+  ProductPatch);
+
+  // Drop 0 during conversion.
+  SmallString CompilationTimeStr;
+  SmallString VersionStr;
+
+  ConverterEBCDIC::convertToEBCDIC(CompilationTime, CompilationTimeStr);
+  ConverterEBCDIC::convertToEBCDIC(Version, VersionStr);
+
+  enum class PPA2MemberId : uint8_t {
+// See z/OS Language Environment Vendor Interfaces v2r5, p.23, for
+// complete list. Only the C runtime is supported by this backend.
+LE_C_Runtime = 3,
+  };
+  enum class PPA2MemberSubId : uint8_t {
+// List of languages using the LE C runtime implementation.
+C = 0x00,
+CXX = 0x01,
+Swift = 0x03,
+Go = 0x60,
+LLVMBasedLang = 0xe7,
+  };
+  // PPA2 Flags
+  enum class PPA2Flags : uint8_t {
+CompileForBinaryFloatingPoint = 0x80,
+CompiledWithXPLink = 0x01,
+CompiledUnitASCII = 0x04,
+HasServiceInfo = 0x20,
+  };
+
+  PPA2MemberSubId MemberSubId = PPA2MemberSubId::LLVMBasedLang;
+  if (auto *MD = M.getModuleFlag("zos_cu_language")) {
+StringRef Language = cast(MD)->getString();
+MemberSubId = StringSwitch(Language)
+  .Case("C", PPA2MemberSubId::C)
+  .Case("CXX", PPA2MemberSubId::CXX)
+  .Case("Swift", PPA2MemberSubId::Swift)
+  .Case("Go", PPA2MemberSubId::Go)
+  .Default(PPA2MemberSubId::LLVMBasedLang);
+  }
+
+  // Emit PPA2 section.
+  OutStreamer->emitLabel(PPA2Sym);
+  OutStreamer->emitInt8(static_cast(PPA2MemberId::LE_C_Runtime));
+  OutStreamer->emitInt8(static_cast(MemberSubId));
+  OutStreamer->emitInt8(0x22); // Member defined, c370_plist+c370_env
+  OutStreamer->emitInt8(0x04); // Control level 4 (XPLink)
+  OutStreamer->emitAbsoluteSymbolDiff(CELQSTRT, PPA2Sym, 4);
+  OutStreamer->emitInt32(0x);
+  OutStreamer->emitAbsoluteSymbolDiff(DateVersionSym, PPA2Sym, 4);
+  OutStreamer->emitInt32(
+  0x); // Offset to main entry point, always 0 (so says TR).
+  uint8_t Flgs = 
static_cast(PPA2Flags::CompileForBinaryFloatingPoint);
+  Flgs |= static_cast(PPA2Flags::CompiledWithXPLink);
+
+  if (auto *MD = M.getModuleFlag("zos_le_char_mode")) {

ysyeda wrote:

This is now set in clang.

https://github.com/llvm/llvm-project/pull/68926
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [SystemZ][z/OS] This change adds support for the PPA2 section in zOS (PR #68926)

[Yusra Syeda via cfe-commits]

@@ -1026,6 +1036,68 @@ void SystemZAsmPrinter::emitADASection() {
   OutStreamer->popSection();
 }
 
+static uint32_t getProductVersion(Module ) {
+  if (auto *VersionVal = cast_or_null(
+  M.getModuleFlag("Product Major Version")))
+return cast(VersionVal->getValue())->getZExtValue();
+  return LLVM_VERSION_MAJOR;
+}
+
+static uint32_t getProductRelease(Module ) {
+  if (auto *ReleaseVal = cast_or_null(
+  M.getModuleFlag("Product Minor Version")))
+return cast(ReleaseVal->getValue())->getZExtValue();
+  return LLVM_VERSION_MINOR;
+}
+
+static uint32_t getProductPatch(Module ) {
+  if (auto *PatchVal = cast_or_null(
+  M.getModuleFlag("Product Patchlevel")))
+return cast(PatchVal->getValue())->getZExtValue();
+  return LLVM_VERSION_PATCH;
+}
+
+void SystemZAsmPrinter::emitIDRLSection(Module ) {
+  OutStreamer->pushSection();
+  OutStreamer->switchSection(getObjFileLowering().getIDRLSection());
+  constexpr unsigned IDRLDataLength = 30;
+  std::time_t Time = TranslationTime;
+
+  uint32_t ProductVersion = getProductVersion(M);
+  uint32_t ProductRelease = getProductRelease(M);
+
+  std::string ProductID;
+  if (auto *MD = M.getModuleFlag("Product Id"))

ysyeda wrote:

This is now set in clang.

https://github.com/llvm/llvm-project/pull/68926
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [SystemZ][z/OS] This change adds support for the PPA2 section in zOS (PR #68926)

[Yusra Syeda via cfe-commits]

@@ -10,9 +10,49 @@
 #include "clang/Config/config.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/FormatVariadic.h"
 #include "llvm/TargetParser/Triple.h"
 using namespace clang;
 
+const char *clang::languageToString(Language L) {
+  // I would like to make this function and the definition of Language
+  // in the .h file simply expand the contents of a .def file.
+  // However, in the .h the members of the enum have doxygen annotations
+  // and/or comments which would be lost.

ysyeda wrote:

Sure, I can create another PR for this.

https://github.com/llvm/llvm-project/pull/68926
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [SystemZ][z/OS] This change adds support for the PPA2 section in zOS (PR #68926)

[Yusra Syeda via cfe-commits]

https://github.com/ysyeda updated 
https://github.com/llvm/llvm-project/pull/68926

>From 5ea8bea2bdf345e2baee07e0a94ac40bd0f109c4 Mon Sep 17 00:00:00 2001
From: Yusra Syeda 
Date: Thu, 12 Oct 2023 16:56:27 -0400
Subject: [PATCH 1/7] This change adds support for the PPA2 section in zOS

---
 clang/include/clang/Basic/LangStandard.h  |   1 +
 clang/lib/Basic/LangStandards.cpp |  39 
 clang/lib/CodeGen/CodeGenModule.cpp   |  15 ++
 clang/lib/Driver/ToolChains/Clang.cpp |  13 +-
 clang/lib/Driver/ToolChains/Clang.h   |   3 +-
 clang/test/CodeGen/SystemZ/systemz-ppa2.c |  25 +++
 llvm/include/llvm/BinaryFormat/GOFF.h |   1 +
 llvm/include/llvm/MC/MCObjectFileInfo.h   |   4 +
 llvm/lib/MC/MCObjectFileInfo.cpp  |   5 +
 llvm/lib/Target/SystemZ/SystemZAsmPrinter.cpp | 197 +-
 llvm/lib/Target/SystemZ/SystemZAsmPrinter.h   |   7 +-
 llvm/test/CodeGen/SystemZ/zos-ppa2.ll |  26 +++
 12 files changed, 331 insertions(+), 5 deletions(-)
 create mode 100644 clang/test/CodeGen/SystemZ/systemz-ppa2.c
 create mode 100644 llvm/test/CodeGen/SystemZ/zos-ppa2.ll

diff --git a/clang/include/clang/Basic/LangStandard.h 
b/clang/include/clang/Basic/LangStandard.h
index 6356f16acc811e0..d94567adf2bfb99 100644
--- a/clang/include/clang/Basic/LangStandard.h
+++ b/clang/include/clang/Basic/LangStandard.h
@@ -43,6 +43,7 @@ enum class Language : uint8_t {
   HLSL,
   ///@}
 };
+const char *LanguageToString(Language L);
 
 enum LangFeatures {
   LineComment = (1 << 0),
diff --git a/clang/lib/Basic/LangStandards.cpp 
b/clang/lib/Basic/LangStandards.cpp
index af9cf4f273920ee..e9b75d78e820a64 100644
--- a/clang/lib/Basic/LangStandards.cpp
+++ b/clang/lib/Basic/LangStandards.cpp
@@ -10,9 +10,48 @@
 #include "clang/Config/config.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/FormatVariadic.h"
 #include "llvm/TargetParser/Triple.h"
 using namespace clang;
 
+const char *clang::LanguageToString(Language L) {
+  // I would like to make this function and the definition of Language
+  // in the .h file simply expand the contents of a .def file.
+  // However, in the .h the members of the enum have doxygen annotations
+  // and/or comments which would be lost.
+  switch (L) {
+  case Language::Unknown:
+return "Unknown";
+  case Language::Asm:
+return "Asm";
+  case Language::LLVM_IR:
+return "LLVM_IR";
+  case Language::C:
+return "C";
+  case Language::CXX:
+return "CXX";
+  case Language::ObjC:
+return "ObjC";
+  case Language::ObjCXX:
+return "ObjCXX";
+  case Language::OpenCL:
+return "OpenCL";
+  case Language::OpenCLCXX:
+return "OpenCLCXX";
+  case Language::CUDA:
+return "CUDA";
+  case Language::RenderScript:
+return "RenderScript";
+  case Language::HIP:
+return "HIP";
+  case Language::HLSL:
+return "HLSL";
+  }
+
+  std::string msg = llvm::formatv("Unknown value ({0}) passed to 
LanguageToString", (unsigned int) L);
+  llvm_unreachable(msg.c_str());
+}
+
 #define LANGSTANDARD(id, name, lang, desc, features)   
\
   static const LangStandard Lang_##id = {name, desc, features, Language::lang};
 #include "clang/Basic/LangStandards.def"
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 754377bed7f7eef..4fd5f8ad2d94c55 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -976,6 +976,21 @@ void CodeGenModule::Release() {
   Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
   getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
 
+  if (getTriple().isOSzOS()) {
+int32_t ProductVersion, ProductRelease, ProductPatch;
+ProductVersion = LLVM_VERSION_MAJOR,
+ProductRelease = LLVM_VERSION_MINOR, ProductPatch = LLVM_VERSION_PATCH;
+getModule().addModuleFlag(llvm::Module::Warning, "Product Major Version", 
ProductVersion);
+getModule().addModuleFlag(llvm::Module::Warning, "Product Minor Version", 
ProductRelease);
+getModule().addModuleFlag(llvm::Module::Warning, "Product Patchlevel", 
ProductPatch);
+
+// Record the language because we need it for the PPA2.
+const char *lang_str = LanguageToString(
+LangStandard::getLangStandardForKind(LangOpts.LangStd).Language);
+getModule().addModuleFlag(llvm::Module::Error, "zos_cu_language",
+  llvm::MDString::get(VMContext, lang_str));
+  }
+
   llvm::Triple::ArchType Arch = Context.getTargetInfo().getTriple().getArch();
   if (   Arch == llvm::Triple::arm
   || Arch == llvm::Triple::armeb
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index b91126ebed0186c..4f02fa2fc3c788a 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -1738,7 +1738,7 @@ void Clang::RenderTargetOptions(const llvm::Triple 

[clang-tools-extra] Fix #41439: Update the documentation with the correct information. (PR #69377)

[Piotr Zegar via cfe-commits]

https://github.com/PiotrZSL edited 
https://github.com/llvm/llvm-project/pull/69377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] Fix #41439: Update the documentation with the correct information. (PR #69377)

[Piotr Zegar via cfe-commits]

@@ -10,7 +10,12 @@ Guide:
 
 
https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions
 
-All parameters should be named, with identical names in the declaration and
-implementation.
+A parameter name may be omitted only if the parameter is not used in the

PiotrZSL wrote:

Maybe:
```
All parameters should have the same name in both the function declaration and 
definition.
If a parameter is not utilized, its name can be commented out in a function 
definition.
```

https://github.com/llvm/llvm-project/pull/69377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] Fix #41439: Update the documentation with the correct information. (PR #69377)

[Piotr Zegar via cfe-commits]

https://github.com/PiotrZSL edited 
https://github.com/llvm/llvm-project/pull/69377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] Fix #41439: Update the documentation with the correct information. (PR #69377)

[Piotr Zegar via cfe-commits]

@@ -10,7 +10,12 @@ Guide:
 
 
https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions
 
-All parameters should be named, with identical names in the declaration and
-implementation.
+A parameter name may be omitted only if the parameter is not used in the
+function's definition.
+
+.. code-block:: c++

PiotrZSL wrote:

format this as:

```
.. code-block:: c++

  int doingSomething(int a, int b, int) {  // Ok: the third paramet is not used
  return a + b;
  }
```

https://github.com/llvm/llvm-project/pull/69377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-format] Fix a bug in annotating TrailingReturnArrow (PR #69249)

[Owen Pan via cfe-commits]

owenca wrote:

@HazardyKnusperkeks any other concerns?

https://github.com/llvm/llvm-project/pull/69249
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver] Remove identifier with the comment (PR #68351)

[Brad Smith via cfe-commits]

brad0 wrote:

@MaskRay Ping.

https://github.com/llvm/llvm-project/pull/68351
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Correctly link and optimize device libraries with -mlink-builtin-bitcode (PR #69371)

[Joseph Huber via cfe-commits]

jhuber6 wrote:

> sincos() is just one example. There are several other cases that can trigger 
> this issue. fold_rootn() generates new function calls for square and cubic 
> roots, fold_pow() does a similar thing for specific powers (ex 2), etc.
> 
> We did try disabling -amdgpu-prelink, and it did lead to a significant 
> performance difference for a couple of key applications
> 
> With this approach we're also hoping to cover future optimizations added that 
> may fall under this category

This approach assumes that whatever the function call was transformed into also 
exists in the same library, which isn't necessarily true. This is related to a 
whole host of problems with handling known runtime library calls inside of 
bitcode. It's possible that we could use some module metadata to indicate when 
these sorts of transformations are legal within LLVM-IR. I've had similar 
issues with LTO, where a `sin` call gets turned into `llvm.sin.f64` which then 
no longer links with the `sin` function implemented in an LTO library. Then 
when the backend runs it will turn back into `sin` but will not be resolved.

https://github.com/llvm/llvm-project/pull/69371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [RISCV] Implement shadow stack on shadow stack mode with Zicfiss. (PR #68075)

[Paul Kirth via cfe-commits]

@@ -106,9 +111,14 @@ static void emitSCSEpilogue(MachineFunction , 
MachineBasicBlock ,
   CSI, [&](CalleeSavedInfo ) { return CSR.getReg() == RAReg; }))
 return;
 
+  const RISCVInstrInfo *TII = STI.getInstrInfo();
+  if (STI.hasFeature(RISCV::FeatureStdExtZicfiss)) {

ilovepi wrote:

Ah, you're totally right. I read that bit incorrectly. Thanks for pointing that 
out.

https://github.com/llvm/llvm-project/pull/68075
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [RISCV] Implement shadow stack on shadow stack mode with Zicfiss. (PR #68075)

[Craig Topper via cfe-commits]

@@ -106,9 +111,14 @@ static void emitSCSEpilogue(MachineFunction , 
MachineBasicBlock ,
   CSI, [&](CalleeSavedInfo ) { return CSR.getReg() == RAReg; }))
 return;
 
+  const RISCVInstrInfo *TII = STI.getInstrInfo();
+  if (STI.hasFeature(RISCV::FeatureStdExtZicfiss)) {

topperc wrote:

As @samitolvanen wrote earlier the SSPUSH and SSPOPCHK instruction fall back to 
NOPs based on configuration.

> If the kernel doesn't support Zicfiss, it presumably also hasn't enabled the 
> extension for U-mode. Therefore, my understanding is that the application 
> loader can simply skip shadow stack setup for the program, including the 
> prctl (which would fail with -EINVAL), and since the Zicfiss (Zimop) 
> instructions are no-ops when the extension is disabled, the program would run 
> normally, just without shadow stacks. Does this sound correct?

https://github.com/llvm/llvm-project/pull/68075
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-format]: Split alignment of declarations around assignment (PR #69340)

[Björn Schäpers via cfe-commits]

@@ -973,13 +974,51 @@ void 
WhitespaceManager::alignConsecutiveShortCaseStatements() {
  Changes);
 }
 
-void WhitespaceManager::alignConsecutiveDeclarations() {
+void WhitespaceManager::alignConsecutiveDeclarationsPreAssignment() {
   if (!Style.AlignConsecutiveDeclarations.Enabled)
 return;
 
   AlignTokens(
   Style,
   [](Change const ) {
+for (FormatToken *Prev = C.Tok->Previous; Prev; Prev = Prev->Previous)

HazardyKnusperkeks wrote:

Could you extract that check and use the same function for the alignment? I'd 
not like the code duplication.

https://github.com/llvm/llvm-project/pull/69340
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-format]: Split alignment of declarations around assignment (PR #69340)

[Björn Schäpers via cfe-commits]

@@ -18783,6 +18783,15 @@ TEST_F(FormatTest, AlignConsecutiveDeclarations) {
" \"bb\"};\n"
"int   bbb = 0;",
Alignment);
+  // http://llvm.org/PR68079
+  verifyFormat("using Fn   = int (A::*)();\n"
+   "using RFn  = int (A::*)() &;\n"
+   "using RRFn = int (A::*)() &&;",
+   Alignment);
+  verifyFormat("using Fn   = int(A::*)();\n"

HazardyKnusperkeks wrote:

See https://github.com/llvm/llvm-project/issues/68079#issuecomment-1767116044

https://github.com/llvm/llvm-project/pull/69340
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [RISCV] Implement shadow stack on shadow stack mode with Zicfiss. (PR #68075)

[Paul Kirth via cfe-commits]

@@ -106,9 +111,14 @@ static void emitSCSEpilogue(MachineFunction , 
MachineBasicBlock ,
   CSI, [&](CalleeSavedInfo ) { return CSR.getReg() == RAReg; }))
 return;
 
+  const RISCVInstrInfo *TII = STI.getInstrInfo();
+  if (STI.hasFeature(RISCV::FeatureStdExtZicfiss)) {

ilovepi wrote:

I thought that the scenario was that the platform only supported software, but 
the CPU did support the instructions, and would therefore execute 
`SSPUSH`/`SSPOPCHK`. I would expect those instructions fail when the memory 
region wasn't initialized and the `SSP` register would point to invalid memory.

If that's not what you meant, then I've misunderstood the scenario. 

https://github.com/llvm/llvm-project/pull/68075
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] [libunwind] Fix running tests with MSan (PR #67860)

[Louis Dionne via cfe-commits]

@@ -115,6 +121,18 @@ extern int unw_set_reg(unw_cursor_t *, unw_regnum_t, 
unw_word_t) LIBUNWIND_AVAIL
 extern int unw_set_fpreg(unw_cursor_t *, unw_regnum_t, unw_fpreg_t)  
LIBUNWIND_AVAIL;
 extern int unw_resume(unw_cursor_t *) LIBUNWIND_AVAIL;
 
+#ifdef LIBUNWIND_HAVE_MSAN
+// unw_getcontext is implemented in assembly so it is rather difficult to
+// mark the MSan shadow as initialized from within the function. Instead we
+// use a macro wrapper when compiling with MSan to avoid false-positives.
+#define unw_getcontext(context)
\

ldionne wrote:

I think I'd defer to the libunwind regulars. @MaskRay perhaps?

https://github.com/llvm/llvm-project/pull/67860
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] [libunwind][test] Avoid calling back into libunwind on sanitizer errors (PR #67861)

[Louis Dionne via cfe-commits]

@@ -28,6 +28,14 @@ if @LIBUNWIND_USES_ARM_EHABI@:
 if not @LIBUNWIND_ENABLE_THREADS@:
 config.available_features.add('libunwind-no-threads')
 
+config.extra_executor_env = ""

ldionne wrote:

Could we instead do something like this?

```diff
diff --git a/libcxx/utils/libcxx/test/params.py 
b/libcxx/utils/libcxx/test/params.py
index c3732560f5e4..3814863cf3fe 100644
--- a/libcxx/utils/libcxx/test/params.py
+++ b/libcxx/utils/libcxx/test/params.py
@@ -227,6 +227,7 @@ DEFAULT_PARAMETERS = [
 
 AddFlag("-fsanitize=address") if sanitizer == "Address" else 
None,
 AddFeature("asan")if sanitizer == "Address" else 
None,
+AddEnvironment("ASAN_OPTIONS", "fast_unwind_on_fatal=1") if 
sanitizer == "Address" else None,
 
 AddFlag("-fsanitize=hwaddress") if sanitizer == "HWAddress" 
else None,
 AddFeature("hwasan")if sanitizer == "HWAddress" 
else None,
@@ -234,6 +235,7 @@ DEFAULT_PARAMETERS = [
 AddFlag("-fsanitize=memory")   if sanitizer in 
["Memory", "MemoryWithOrigins"] else None,
 AddFeature("msan") if sanitizer in 
["Memory", "MemoryWithOrigins"] else None,
 AddFlag("-fsanitize-memory-track-origins") if sanitizer == 
"MemoryWithOrigins" else None,
+AddEnvironment("MSAN_OPTIONS", "fast_unwind_on_fatal=1") if 
sanitizer in ["Memory", "MemoryWithOrigins"] else None,
 
 AddFlag("-fsanitize=thread") if sanitizer == "Thread" else 
None,
 AddFeature("tsan")   if sanitizer == "Thread" else 
None,
```

This would require a bit more plumbing cause we don't have `AddEnvironment` 
right now, but it seems like the better way of doing this instead of forcing 
the way in the cmake bridge.

https://github.com/llvm/llvm-project/pull/67861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] [libunwind][test] Avoid calling back into libunwind on sanitizer errors (PR #67861)

[Louis Dionne via cfe-commits]

https://github.com/ldionne requested changes to this pull request.

> The underlying issues is fixed in 
> https://github.com/llvm/llvm-project/pull/67860 but if we ever introduce an 
> new MSan error inside libunwind we will see the same infinite recursion 
> because MSan diagnotics try to print a stacktrace using libunwind (calling 
> __unw_getcontext again).

Got it, I think this makes sense then, but I don't think the current 
implementation is really ideal -- let's see what you think about my suggestion.

https://github.com/llvm/llvm-project/pull/67861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] [libunwind][test] Avoid calling back into libunwind on sanitizer errors (PR #67861)

[Louis Dionne via cfe-commits]

https://github.com/ldionne edited 
https://github.com/llvm/llvm-project/pull/67861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] Fix #41439: Update the documentation with the correct information. (PR #69377)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang-tidy

Author: None (Da-Viper)


Changes

Fixes #41439

 The documentation is update to say it is allowed to have omitted parameter 
names if the variable is not used 

---
Full diff: https://github.com/llvm/llvm-project/pull/69377.diff


1 Files Affected:

- (modified) 
clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.rst (+7-2) 


``diff
diff --git 
a/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.rst 
b/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.rst
index 8d28c0aa02169a7..7e7099b3df251d1 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.rst
@@ -10,7 +10,12 @@ Guide:
 
 
https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions
 
-All parameters should be named, with identical names in the declaration and
-implementation.
+A parameter name may be omitted only if the parameter is not used in the
+function's definition.
+
+.. code-block:: c++
+int doingSomething(int a, int b, int) {  // Ok: the third paramet is not used
+return a + b;
+}
 
 Corresponding cpplint.py check name: `readability/function`.

``




https://github.com/llvm/llvm-project/pull/69377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] Fix #41439: Update the documentation with the correct information. (PR #69377)

[via cfe-commits]

https://github.com/Da-Viper created 
https://github.com/llvm/llvm-project/pull/69377

Fixes #41439

 The documentation is update to say it is allowed to have omitted parameter 
names if the variable is not used 

>From 0e0a3e7ad1a0a7098e05a5164413369eaa58c55b Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Tue, 17 Oct 2023 20:49:47 +0100
Subject: [PATCH] Fix #41439: Update the documentation with the correct
 information.

---
 .../clang-tidy/checks/readability/named-parameter.rst| 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git 
a/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.rst 
b/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.rst
index 8d28c0aa02169a7..7e7099b3df251d1 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.rst
@@ -10,7 +10,12 @@ Guide:
 
 
https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions
 
-All parameters should be named, with identical names in the declaration and
-implementation.
+A parameter name may be omitted only if the parameter is not used in the
+function's definition.
+
+.. code-block:: c++
+int doingSomething(int a, int b, int) {  // Ok: the third paramet is not used
+return a + b;
+}
 
 Corresponding cpplint.py check name: `readability/function`.

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

[clang] [RISCV] Implement shadow stack on shadow stack mode with Zicfiss. (PR #68075)

[Craig Topper via cfe-commits]

@@ -106,9 +111,14 @@ static void emitSCSEpilogue(MachineFunction , 
MachineBasicBlock ,
   CSI, [&](CalleeSavedInfo ) { return CSR.getReg() == RAReg; }))
 return;
 
+  const RISCVInstrInfo *TII = STI.getInstrInfo();
+  if (STI.hasFeature(RISCV::FeatureStdExtZicfiss)) {

topperc wrote:

> Today, if you use software SCS on a platform without support they just fail, 
> since the SCS won't be setup and gp(probably) points to invalid memory. Is it 
> unreasonable to have it work the same in this case?

If the hardware shadow stack isn't set up, won't the instructions become silent 
NOPs rather than failing?

https://github.com/llvm/llvm-project/pull/68075
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Correctly link and optimize device libraries with -mlink-builtin-bitcode (PR #69371)

[via cfe-commits]

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff fbf0a77e80f18a6d0fd8a28833b0bc87a99b1b2f 
b7af255d2cb8f9a00d1977f92d4e3723ef0720bf -- clang/lib/CodeGen/BackendConsumer.h 
clang/lib/CodeGen/LinkInModulesPass.cpp clang/lib/CodeGen/LinkInModulesPass.h 
clang/lib/CodeGen/BackendUtil.cpp clang/lib/CodeGen/CodeGenAction.cpp
``





View the diff from clang-format here.


``diff
diff --git a/clang/lib/CodeGen/BackendConsumer.h 
b/clang/lib/CodeGen/BackendConsumer.h
index 72a814cd43d7..17d5ca3d1b80 100644
--- a/clang/lib/CodeGen/BackendConsumer.h
+++ b/clang/lib/CodeGen/BackendConsumer.h
@@ -16,7 +16,7 @@
 #include "llvm/Support/Timer.h"
 
 namespace llvm {
-  class DiagnosticInfoDontCall;
+class DiagnosticInfoDontCall;
 }
 
 namespace clang {
@@ -60,9 +60,7 @@ class BackendConsumer : public ASTConsumer {
   // location which is not severe. This is a vector instead of an actual map
   // because we optimize for time building this map rather than time
   // retrieving an entry, as backend diagnostics are uncommon.
-  std::vector>
-ManglingFullSourceLocs;
-
+  std::vector> 
ManglingFullSourceLocs;
 
   // This is here so that the diagnostic printer knows the module a diagnostic
   // refers to.
@@ -74,8 +72,8 @@ public:
   const HeaderSearchOptions ,
   const PreprocessorOptions ,
   const CodeGenOptions ,
-  const TargetOptions ,
-  const LangOptions , const std::string ,
+  const TargetOptions , const LangOptions ,
+  const std::string ,
   SmallVector LinkModules,
   std::unique_ptr OS, llvm::LLVMContext ,
   CoverageSourceInfo *CoverageInfo = nullptr);
@@ -88,9 +86,9 @@ public:
   const HeaderSearchOptions ,
   const PreprocessorOptions ,
   const CodeGenOptions ,
-  const TargetOptions ,
-  const LangOptions , llvm::Module *Module,
-  SmallVector LinkModules, llvm::LLVMContext ,
+  const TargetOptions , const LangOptions ,
+  llvm::Module *Module, SmallVector LinkModules,
+  llvm::LLVMContext ,
   CoverageSourceInfo *CoverageInfo = nullptr);
 
   llvm::Module *getModule() const;
@@ -111,19 +109,18 @@ public:
   void AssignInheritanceModel(CXXRecordDecl *RD) override;
   void HandleVTable(CXXRecordDecl *RD) override;
 
-
- // Links each entry in LinkModules into our module.  Returns true on error.
+  // Links each entry in LinkModules into our module.  Returns true on error.
   bool LinkInModules(llvm::Module *M, bool ShouldLinkFiles = true);
 
   /// Get the best possible source location to represent a diagnostic that
   /// may have associated debug info.
-  const FullSourceLoc getBestLocationFromDebugLoc(
-const llvm::DiagnosticInfoWithLocationBase ,
-bool , StringRef ,
-unsigned , unsigned ) const;
+  const FullSourceLoc
+  getBestLocationFromDebugLoc(const llvm::DiagnosticInfoWithLocationBase ,
+  bool , StringRef ,
+  unsigned , unsigned ) const;
 
-  std::optional getFunctionSourceLocation(
-const llvm::Function ) const;
+  std::optional
+  getFunctionSourceLocation(const llvm::Function ) const;
 
   void DiagnosticHandlerImpl(const llvm::DiagnosticInfo );
   /// Specialized handler for InlineAsm diagnostic.
@@ -148,14 +145,13 @@ public:
   /// them.
   void EmitOptimizationMessage(const llvm::DiagnosticInfoOptimizationBase ,
unsigned DiagID);
+  void OptimizationRemarkHandler(const llvm::DiagnosticInfoOptimizationBase 
);
+  void
+  OptimizationRemarkHandler(const llvm::OptimizationRemarkAnalysisFPCommute 
);
+  void
+  OptimizationRemarkHandler(const llvm::OptimizationRemarkAnalysisAliasing );
   void
-OptimizationRemarkHandler(const llvm::DiagnosticInfoOptimizationBase );
-  void OptimizationRemarkHandler(
-const llvm::OptimizationRemarkAnalysisFPCommute );
-  void OptimizationRemarkHandler(
-const llvm::OptimizationRemarkAnalysisAliasing );
-  void OptimizationFailureHandler(
-const llvm::DiagnosticInfoOptimizationFailure );
+  OptimizationFailureHandler(const llvm::DiagnosticInfoOptimizationFailure );
   void DontCallDiagHandler(const llvm::DiagnosticInfoDontCall );
   /// Specialized handler for misexpect warnings.
   /// Note that misexpect remarks are emitted through ORE
diff --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index 894daced377f..d5bf0402c267 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -6,9 +6,9 @@
 //
 
//===--===//
 
+#include 

[clang] Correctly link and optimize device libraries with -mlink-builtin-bitcode (PR #69371)

[Jacob Lambert via cfe-commits]

lamb-j wrote:

sincos() is just one example. There are several other cases that can trigger 
this issue. fold_rootn() generates new function calls for square and cubic 
roots, fold_pow() does a similar thing for specific powers (ex 2)

We did try disabling -llvm-prelink, and it did lead to a significant 
performance difference for a couple of key applications



https://github.com/llvm/llvm-project/pull/69371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Correctly link and optimize device libraries with -mlink-builtin-bitcode (PR #69371)

[Joseph Huber via cfe-commits]

jhuber6 wrote:

> This handles the edge case where optimization introduces new device library 
> functions, such as a fused sincos() from separate sin() and cos() calls.

This seems like a pretty big change to solve just this problem. Could we not 
just put `nobuiltin` on said function to stop it from doing that? Is this 
optimization explicitly valuable in this case?

https://github.com/llvm/llvm-project/pull/69371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Correctly link and optimize device libraries with -mlink-builtin-bitcode (PR #69371)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Jacob Lambert (lamb-j)


Changes

This set of patches updates device library linking and optimization to do the 
following:

Link
Optimize
Link (New)

This handles the edge case where optimization introduces new device library 
functions, such as a fused sincos() from separate sin() and cos() calls. The 
second link step ensures the sincos() definition is also linked in from the 
device libraries.

---

Patch is 51.23 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/69371.diff


6 Files Affected:

- (added) clang/lib/CodeGen/BackendConsumer.h (+166) 
- (modified) clang/lib/CodeGen/BackendUtil.cpp (+42-30) 
- (modified) clang/lib/CodeGen/CMakeLists.txt (+1) 
- (modified) clang/lib/CodeGen/CodeGenAction.cpp (+303-361) 
- (added) clang/lib/CodeGen/LinkInModulesPass.cpp (+29) 
- (added) clang/lib/CodeGen/LinkInModulesPass.h (+43) 


``diff
diff --git a/clang/lib/CodeGen/BackendConsumer.h 
b/clang/lib/CodeGen/BackendConsumer.h
new file mode 100644
index 000..72a814cd43d738d
--- /dev/null
+++ b/clang/lib/CodeGen/BackendConsumer.h
@@ -0,0 +1,166 @@
+//===--- BackendConsumer.h - LLVM BackendConsumer Header File 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_LIB_CODEGEN_BACKENDCONSUMER_H
+#define LLVM_CLANG_LIB_CODEGEN_BACKENDCONSUMER_H
+
+#include "clang/CodeGen/BackendUtil.h"
+#include "clang/CodeGen/CodeGenAction.h"
+
+#include "llvm/IR/DiagnosticInfo.h"
+#include "llvm/Support/Timer.h"
+
+namespace llvm {
+  class DiagnosticInfoDontCall;
+}
+
+namespace clang {
+class ASTContext;
+class CodeGenAction;
+class CoverageSourceInfo;
+
+class BackendConsumer : public ASTConsumer {
+  using LinkModule = CodeGenAction::LinkModule;
+
+  virtual void anchor();
+  DiagnosticsEngine 
+  BackendAction Action;
+  const HeaderSearchOptions 
+  const CodeGenOptions 
+  const TargetOptions 
+  const LangOptions 
+  std::unique_ptr AsmOutStream;
+  ASTContext *Context;
+  IntrusiveRefCntPtr FS;
+
+  llvm::Timer LLVMIRGeneration;
+  unsigned LLVMIRGenerationRefCount;
+
+  /// True if we've finished generating IR. This prevents us from generating
+  /// additional LLVM IR after emitting output in HandleTranslationUnit. This
+  /// can happen when Clang plugins trigger additional AST deserialization.
+  bool IRGenFinished = false;
+
+  bool TimerIsEnabled = false;
+
+  std::unique_ptr Gen;
+
+  SmallVector LinkModules;
+
+  // A map from mangled names to their function's source location, used for
+  // backend diagnostics as the Clang AST may be unavailable. We actually use
+  // the mangled name's hash as the key because mangled names can be very
+  // long and take up lots of space. Using a hash can cause name collision,
+  // but that is rare and the consequences are pointing to a wrong source
+  // location which is not severe. This is a vector instead of an actual map
+  // because we optimize for time building this map rather than time
+  // retrieving an entry, as backend diagnostics are uncommon.
+  std::vector>
+ManglingFullSourceLocs;
+
+
+  // This is here so that the diagnostic printer knows the module a diagnostic
+  // refers to.
+  llvm::Module *CurLinkModule = nullptr;
+
+public:
+  BackendConsumer(BackendAction Action, DiagnosticsEngine ,
+  IntrusiveRefCntPtr VFS,
+  const HeaderSearchOptions ,
+  const PreprocessorOptions ,
+  const CodeGenOptions ,
+  const TargetOptions ,
+  const LangOptions , const std::string ,
+  SmallVector LinkModules,
+  std::unique_ptr OS, llvm::LLVMContext ,
+  CoverageSourceInfo *CoverageInfo = nullptr);
+
+  // This constructor is used in installing an empty BackendConsumer
+  // to use the clang diagnostic handler for IR input files. It avoids
+  // initializing the OS field.
+  BackendConsumer(BackendAction Action, DiagnosticsEngine ,
+  IntrusiveRefCntPtr VFS,
+  const HeaderSearchOptions ,
+  const PreprocessorOptions ,
+  const CodeGenOptions ,
+  const TargetOptions ,
+  const LangOptions , llvm::Module *Module,
+  SmallVector LinkModules, llvm::LLVMContext ,
+  CoverageSourceInfo *CoverageInfo = nullptr);
+
+  llvm::Module *getModule() const;
+  std::unique_ptr takeModule();
+
+  CodeGenerator *getCodeGenerator();
+
+  void HandleCXXStaticMemberVarInstantiation(VarDecl *VD) override;
+  void Initialize(ASTContext ) override;
+  bool HandleTopLevelDecl(DeclGroupRef D) override;
+  void 

[clang] Correctly link and optimize device libraries with -mlink-builtin-bitcode (PR #69371)

[Jacob Lambert via cfe-commits]

https://github.com/lamb-j created 
https://github.com/llvm/llvm-project/pull/69371

This set of patches updates device library linking and optimization to do the 
following:

Link
Optimize
Link (New)

This handles the edge case where optimization introduces new device library 
functions, such as a fused sincos() from separate sin() and cos() calls. The 
second link step ensures the sincos() definition is also linked in from the 
device libraries.

>From 25302c315360c166f34ab9acde2561dc7865b3bb Mon Sep 17 00:00:00 2001
From: Jacob Lambert 
Date: Tue, 17 Oct 2023 12:01:15 -0700
Subject: [PATCH 1/3] [NFC] Refactor BackendConsumer class definition into new
 header

Previously the BackendConsumer class was defined in CodeGenAction.cpp.
In order to use this class and its member functions in other files
for upcoming changes, we first need to refactor the class definition
into a separate header
---
 clang/lib/CodeGen/BackendConsumer.h | 166 +++
 clang/lib/CodeGen/CodeGenAction.cpp | 643 
 2 files changed, 448 insertions(+), 361 deletions(-)
 create mode 100644 clang/lib/CodeGen/BackendConsumer.h

diff --git a/clang/lib/CodeGen/BackendConsumer.h 
b/clang/lib/CodeGen/BackendConsumer.h
new file mode 100644
index 000..2a4f70d5668ed6b
--- /dev/null
+++ b/clang/lib/CodeGen/BackendConsumer.h
@@ -0,0 +1,166 @@
+//===--- BackendConsumer.h - LLVM BackendConsumer Header File 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_LIB_CODEGEN_BACKENDCONSUMER_H
+#define LLVM_CLANG_LIB_CODEGEN_BACKENDCONSUMER_H
+
+#include "clang/CodeGen/BackendUtil.h"
+#include "clang/CodeGen/CodeGenAction.h"
+
+#include "llvm/IR/DiagnosticInfo.h"
+#include "llvm/Support/Timer.h"
+
+namespace llvm {
+  class DiagnosticInfoDontCall;
+}
+
+namespace clang {
+class ASTContext;
+class CodeGenAction;
+class CoverageSourceInfo;
+
+class BackendConsumer : public ASTConsumer {
+  using LinkModule = CodeGenAction::LinkModule;
+
+  virtual void anchor();
+  DiagnosticsEngine 
+  BackendAction Action;
+  const HeaderSearchOptions 
+  const CodeGenOptions 
+  const TargetOptions 
+  const LangOptions 
+  std::unique_ptr AsmOutStream;
+  ASTContext *Context;
+  IntrusiveRefCntPtr FS;
+
+  llvm::Timer LLVMIRGeneration;
+  unsigned LLVMIRGenerationRefCount;
+
+  /// True if we've finished generating IR. This prevents us from generating
+  /// additional LLVM IR after emitting output in HandleTranslationUnit. This
+  /// can happen when Clang plugins trigger additional AST deserialization.
+  bool IRGenFinished = false;
+
+  bool TimerIsEnabled = false;
+
+  std::unique_ptr Gen;
+
+  SmallVector LinkModules;
+
+  // A map from mangled names to their function's source location, used for
+  // backend diagnostics as the Clang AST may be unavailable. We actually use
+  // the mangled name's hash as the key because mangled names can be very
+  // long and take up lots of space. Using a hash can cause name collision,
+  // but that is rare and the consequences are pointing to a wrong source
+  // location which is not severe. This is a vector instead of an actual map
+  // because we optimize for time building this map rather than time
+  // retrieving an entry, as backend diagnostics are uncommon.
+  std::vector>
+ManglingFullSourceLocs;
+
+
+  // This is here so that the diagnostic printer knows the module a diagnostic
+  // refers to.
+  llvm::Module *CurLinkModule = nullptr;
+
+public:
+  BackendConsumer(BackendAction Action, DiagnosticsEngine ,
+  IntrusiveRefCntPtr VFS,
+  const HeaderSearchOptions ,
+  const PreprocessorOptions ,
+  const CodeGenOptions ,
+  const TargetOptions ,
+  const LangOptions , const std::string ,
+  SmallVector LinkModules,
+  std::unique_ptr OS, llvm::LLVMContext ,
+  CoverageSourceInfo *CoverageInfo = nullptr);
+
+  // This constructor is used in installing an empty BackendConsumer
+  // to use the clang diagnostic handler for IR input files. It avoids
+  // initializing the OS field.
+  BackendConsumer(BackendAction Action, DiagnosticsEngine ,
+  IntrusiveRefCntPtr VFS,
+  const HeaderSearchOptions ,
+  const PreprocessorOptions ,
+  const CodeGenOptions ,
+  const TargetOptions ,
+  const LangOptions , llvm::Module *Module,
+  SmallVector LinkModules, llvm::LLVMContext ,
+  CoverageSourceInfo *CoverageInfo = nullptr);
+
+  llvm::Module *getModule() const;
+  std::unique_ptr takeModule();
+
+  CodeGenerator *getCodeGenerator();
+
+  void 

[clang-tools-extra] [libc++] Implement ranges::contains (PR #65148)

[via cfe-commits]

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/65148

>From 02e9afd761228f401df4d9f8dfaaca44ffae0c6e Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Thu, 31 Aug 2023 20:08:32 +
Subject: [PATCH 01/16] [libc++] Implement ranges::contains

Differential Revision: https://reviews.llvm.org/D159232
---
 libcxx/include/CMakeLists.txt |   1 +
 libcxx/include/__algorithm/ranges_contains.h  |  60 ++
 libcxx/include/algorithm  |   9 +
 ...obust_against_copying_projections.pass.cpp |   4 +
 .../alg.contains/ranges.contains.pass.cpp | 190 ++
 .../niebloid.compile.pass.cpp |   1 +
 6 files changed, 265 insertions(+)
 create mode 100644 libcxx/include/__algorithm/ranges_contains.h
 create mode 100644 
libcxx/test/std/algorithms/alg.nonmodifying/alg.contains/ranges.contains.pass.cpp

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index 77a7269121ec142..024aa8959fb7200 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -104,6 +104,7 @@ set(files
   __algorithm/ranges_any_of.h
   __algorithm/ranges_binary_search.h
   __algorithm/ranges_clamp.h
+  __algorithm/ranges_contains.h
   __algorithm/ranges_copy.h
   __algorithm/ranges_copy_backward.h
   __algorithm/ranges_copy_if.h
diff --git a/libcxx/include/__algorithm/ranges_contains.h 
b/libcxx/include/__algorithm/ranges_contains.h
new file mode 100644
index 000..647b7ea34be3421
--- /dev/null
+++ b/libcxx/include/__algorithm/ranges_contains.h
@@ -0,0 +1,60 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+#define _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+
+#include <__algorithm/in_in_result.h>
+#include <__algorithm/ranges_find.h>
+#include <__config>
+#include <__functional/identity.h>
+#include <__functional/ranges_operations.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/indirectly_comparable.h>
+#include <__iterator/projected.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace ranges {
+namespace __contains {
+struct __fn {
+  template  _Sent, class _Type, 
class _Proj = identity>
+requires indirect_binary_predicate, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = 
{}) const {
+return ranges::find(std::move(__first), std::move(__last), __value, 
std::ref(__proj)) != __last;
+  }
+
+  template 
+requires indirect_binary_predicate, _Proj>, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) const {
+return ranges::find(ranges::begin(__range), ranges::end(__range), __value, 
std::ref(__proj)) != ranges::end(__range);
+  }
+};
+} // namespace __contains
+inline namespace __cpo {
+inline constexpr auto contains = __contains::__fn{};
+} // namespace __cpo
+} // namespace ranges
+
+_LIBCPP_END_NAMESPACE_STD
+
+#endif // _LIBCPP_STD_VER >= 23
+
+#endif // _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
diff --git a/libcxx/include/algorithm b/libcxx/include/algorithm
index 76e0d22bf73ef85..003bf132b38b4d8 100644
--- a/libcxx/include/algorithm
+++ b/libcxx/include/algorithm
@@ -226,6 +226,14 @@ namespace ranges {
   template
 using copy_backward_result = in_out_result;
 // since C++20
 
+  template S, class T, class Proj = identity>
+requires indirect_binary_predicate, 
const T*>
+constexpr bool ranges::contains(I first, S last, const T& value, Proj proj 
= {});   // since C++23
+
+  template
+requires indirect_binary_predicate, Proj>, const T*>
+constexpr bool ranges::contains(R&& r, const T& value, Proj proj = {});
 // since C++23
+
   template S, weakly_incrementable O>
 requires indirectly_copyable
 constexpr ranges::copy_result ranges::copy(I first, S last, O 
result);// since C++20
@@ -1827,6 +1835,7 @@ template 
 #include <__algorithm/ranges_any_of.h>
 #include <__algorithm/ranges_binary_search.h>
 #include <__algorithm/ranges_clamp.h>
+#include <__algorithm/ranges_contains.h>
 #include <__algorithm/ranges_copy.h>
 #include <__algorithm/ranges_copy_backward.h>
 #include <__algorithm/ranges_copy_if.h>
diff --git 

[libunwind] [libc++] Implement ranges::contains (PR #65148)

[via cfe-commits]

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/65148

>From 02e9afd761228f401df4d9f8dfaaca44ffae0c6e Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Thu, 31 Aug 2023 20:08:32 +
Subject: [PATCH 01/16] [libc++] Implement ranges::contains

Differential Revision: https://reviews.llvm.org/D159232
---
 libcxx/include/CMakeLists.txt |   1 +
 libcxx/include/__algorithm/ranges_contains.h  |  60 ++
 libcxx/include/algorithm  |   9 +
 ...obust_against_copying_projections.pass.cpp |   4 +
 .../alg.contains/ranges.contains.pass.cpp | 190 ++
 .../niebloid.compile.pass.cpp |   1 +
 6 files changed, 265 insertions(+)
 create mode 100644 libcxx/include/__algorithm/ranges_contains.h
 create mode 100644 
libcxx/test/std/algorithms/alg.nonmodifying/alg.contains/ranges.contains.pass.cpp

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index 77a7269121ec142..024aa8959fb7200 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -104,6 +104,7 @@ set(files
   __algorithm/ranges_any_of.h
   __algorithm/ranges_binary_search.h
   __algorithm/ranges_clamp.h
+  __algorithm/ranges_contains.h
   __algorithm/ranges_copy.h
   __algorithm/ranges_copy_backward.h
   __algorithm/ranges_copy_if.h
diff --git a/libcxx/include/__algorithm/ranges_contains.h 
b/libcxx/include/__algorithm/ranges_contains.h
new file mode 100644
index 000..647b7ea34be3421
--- /dev/null
+++ b/libcxx/include/__algorithm/ranges_contains.h
@@ -0,0 +1,60 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+#define _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+
+#include <__algorithm/in_in_result.h>
+#include <__algorithm/ranges_find.h>
+#include <__config>
+#include <__functional/identity.h>
+#include <__functional/ranges_operations.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/indirectly_comparable.h>
+#include <__iterator/projected.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace ranges {
+namespace __contains {
+struct __fn {
+  template  _Sent, class _Type, 
class _Proj = identity>
+requires indirect_binary_predicate, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = 
{}) const {
+return ranges::find(std::move(__first), std::move(__last), __value, 
std::ref(__proj)) != __last;
+  }
+
+  template 
+requires indirect_binary_predicate, _Proj>, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) const {
+return ranges::find(ranges::begin(__range), ranges::end(__range), __value, 
std::ref(__proj)) != ranges::end(__range);
+  }
+};
+} // namespace __contains
+inline namespace __cpo {
+inline constexpr auto contains = __contains::__fn{};
+} // namespace __cpo
+} // namespace ranges
+
+_LIBCPP_END_NAMESPACE_STD
+
+#endif // _LIBCPP_STD_VER >= 23
+
+#endif // _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
diff --git a/libcxx/include/algorithm b/libcxx/include/algorithm
index 76e0d22bf73ef85..003bf132b38b4d8 100644
--- a/libcxx/include/algorithm
+++ b/libcxx/include/algorithm
@@ -226,6 +226,14 @@ namespace ranges {
   template
 using copy_backward_result = in_out_result;
 // since C++20
 
+  template S, class T, class Proj = identity>
+requires indirect_binary_predicate, 
const T*>
+constexpr bool ranges::contains(I first, S last, const T& value, Proj proj 
= {});   // since C++23
+
+  template
+requires indirect_binary_predicate, Proj>, const T*>
+constexpr bool ranges::contains(R&& r, const T& value, Proj proj = {});
 // since C++23
+
   template S, weakly_incrementable O>
 requires indirectly_copyable
 constexpr ranges::copy_result ranges::copy(I first, S last, O 
result);// since C++20
@@ -1827,6 +1835,7 @@ template 
 #include <__algorithm/ranges_any_of.h>
 #include <__algorithm/ranges_binary_search.h>
 #include <__algorithm/ranges_clamp.h>
+#include <__algorithm/ranges_contains.h>
 #include <__algorithm/ranges_copy.h>
 #include <__algorithm/ranges_copy_backward.h>
 #include <__algorithm/ranges_copy_if.h>
diff --git 

[clang] [libc++] Implement ranges::contains (PR #65148)

[via cfe-commits]

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/65148

>From 02e9afd761228f401df4d9f8dfaaca44ffae0c6e Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Thu, 31 Aug 2023 20:08:32 +
Subject: [PATCH 01/16] [libc++] Implement ranges::contains

Differential Revision: https://reviews.llvm.org/D159232
---
 libcxx/include/CMakeLists.txt |   1 +
 libcxx/include/__algorithm/ranges_contains.h  |  60 ++
 libcxx/include/algorithm  |   9 +
 ...obust_against_copying_projections.pass.cpp |   4 +
 .../alg.contains/ranges.contains.pass.cpp | 190 ++
 .../niebloid.compile.pass.cpp |   1 +
 6 files changed, 265 insertions(+)
 create mode 100644 libcxx/include/__algorithm/ranges_contains.h
 create mode 100644 
libcxx/test/std/algorithms/alg.nonmodifying/alg.contains/ranges.contains.pass.cpp

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index 77a7269121ec142..024aa8959fb7200 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -104,6 +104,7 @@ set(files
   __algorithm/ranges_any_of.h
   __algorithm/ranges_binary_search.h
   __algorithm/ranges_clamp.h
+  __algorithm/ranges_contains.h
   __algorithm/ranges_copy.h
   __algorithm/ranges_copy_backward.h
   __algorithm/ranges_copy_if.h
diff --git a/libcxx/include/__algorithm/ranges_contains.h 
b/libcxx/include/__algorithm/ranges_contains.h
new file mode 100644
index 000..647b7ea34be3421
--- /dev/null
+++ b/libcxx/include/__algorithm/ranges_contains.h
@@ -0,0 +1,60 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+#define _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+
+#include <__algorithm/in_in_result.h>
+#include <__algorithm/ranges_find.h>
+#include <__config>
+#include <__functional/identity.h>
+#include <__functional/ranges_operations.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/indirectly_comparable.h>
+#include <__iterator/projected.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace ranges {
+namespace __contains {
+struct __fn {
+  template  _Sent, class _Type, 
class _Proj = identity>
+requires indirect_binary_predicate, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = 
{}) const {
+return ranges::find(std::move(__first), std::move(__last), __value, 
std::ref(__proj)) != __last;
+  }
+
+  template 
+requires indirect_binary_predicate, _Proj>, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) const {
+return ranges::find(ranges::begin(__range), ranges::end(__range), __value, 
std::ref(__proj)) != ranges::end(__range);
+  }
+};
+} // namespace __contains
+inline namespace __cpo {
+inline constexpr auto contains = __contains::__fn{};
+} // namespace __cpo
+} // namespace ranges
+
+_LIBCPP_END_NAMESPACE_STD
+
+#endif // _LIBCPP_STD_VER >= 23
+
+#endif // _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
diff --git a/libcxx/include/algorithm b/libcxx/include/algorithm
index 76e0d22bf73ef85..003bf132b38b4d8 100644
--- a/libcxx/include/algorithm
+++ b/libcxx/include/algorithm
@@ -226,6 +226,14 @@ namespace ranges {
   template
 using copy_backward_result = in_out_result;
 // since C++20
 
+  template S, class T, class Proj = identity>
+requires indirect_binary_predicate, 
const T*>
+constexpr bool ranges::contains(I first, S last, const T& value, Proj proj 
= {});   // since C++23
+
+  template
+requires indirect_binary_predicate, Proj>, const T*>
+constexpr bool ranges::contains(R&& r, const T& value, Proj proj = {});
 // since C++23
+
   template S, weakly_incrementable O>
 requires indirectly_copyable
 constexpr ranges::copy_result ranges::copy(I first, S last, O 
result);// since C++20
@@ -1827,6 +1835,7 @@ template 
 #include <__algorithm/ranges_any_of.h>
 #include <__algorithm/ranges_binary_search.h>
 #include <__algorithm/ranges_clamp.h>
+#include <__algorithm/ranges_contains.h>
 #include <__algorithm/ranges_copy.h>
 #include <__algorithm/ranges_copy_backward.h>
 #include <__algorithm/ranges_copy_if.h>
diff --git 

[clang-tools-extra] [libc++] Implement ranges::contains (PR #65148)

[via cfe-commits]

@@ -0,0 +1,252 @@
+//===--===//

ZijunZhaoCCK wrote:

I add `robust` tests about projector, invoking and proxy iterators like 
`ranges::ends_with()` and `ranges::find()` but I don't add any `robust` tests 
about comparator because there is no comparator in `ranges::contains()`. Hope I 
miss nothing!

https://github.com/llvm/llvm-project/pull/65148
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] [libc++] Implement ranges::contains (PR #65148)

[via cfe-commits]

@@ -0,0 +1,252 @@
+//===--===//

ZijunZhaoCCK wrote:

I add `robust` tests about projector, invoking and proxy iterators like 
`ranges::ends_with()` and `ranges::find()` but I don't add any `robust` tests 
about comparator because there is no comparator in `ranges::contains()`. Hope I 
miss nothing!

https://github.com/llvm/llvm-project/pull/65148
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libc++] Implement ranges::contains (PR #65148)

[via cfe-commits]

@@ -0,0 +1,252 @@
+//===--===//

ZijunZhaoCCK wrote:

I add `robust` tests about projector, invoking and proxy iterators like 
`ranges::ends_with()` and `ranges::find()` but I don't add any `robust` tests 
about comparator because there is no comparator in `ranges::contains()`. Hope I 
miss nothing!

https://github.com/llvm/llvm-project/pull/65148
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [libc++] Implement ranges::contains (PR #65148)

[via cfe-commits]

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/65148

>From 02e9afd761228f401df4d9f8dfaaca44ffae0c6e Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Thu, 31 Aug 2023 20:08:32 +
Subject: [PATCH 01/16] [libc++] Implement ranges::contains

Differential Revision: https://reviews.llvm.org/D159232
---
 libcxx/include/CMakeLists.txt |   1 +
 libcxx/include/__algorithm/ranges_contains.h  |  60 ++
 libcxx/include/algorithm  |   9 +
 ...obust_against_copying_projections.pass.cpp |   4 +
 .../alg.contains/ranges.contains.pass.cpp | 190 ++
 .../niebloid.compile.pass.cpp |   1 +
 6 files changed, 265 insertions(+)
 create mode 100644 libcxx/include/__algorithm/ranges_contains.h
 create mode 100644 
libcxx/test/std/algorithms/alg.nonmodifying/alg.contains/ranges.contains.pass.cpp

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index 77a7269121ec142..024aa8959fb7200 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -104,6 +104,7 @@ set(files
   __algorithm/ranges_any_of.h
   __algorithm/ranges_binary_search.h
   __algorithm/ranges_clamp.h
+  __algorithm/ranges_contains.h
   __algorithm/ranges_copy.h
   __algorithm/ranges_copy_backward.h
   __algorithm/ranges_copy_if.h
diff --git a/libcxx/include/__algorithm/ranges_contains.h 
b/libcxx/include/__algorithm/ranges_contains.h
new file mode 100644
index 000..647b7ea34be3421
--- /dev/null
+++ b/libcxx/include/__algorithm/ranges_contains.h
@@ -0,0 +1,60 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+#define _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+
+#include <__algorithm/in_in_result.h>
+#include <__algorithm/ranges_find.h>
+#include <__config>
+#include <__functional/identity.h>
+#include <__functional/ranges_operations.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/indirectly_comparable.h>
+#include <__iterator/projected.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace ranges {
+namespace __contains {
+struct __fn {
+  template  _Sent, class _Type, 
class _Proj = identity>
+requires indirect_binary_predicate, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = 
{}) const {
+return ranges::find(std::move(__first), std::move(__last), __value, 
std::ref(__proj)) != __last;
+  }
+
+  template 
+requires indirect_binary_predicate, _Proj>, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) const {
+return ranges::find(ranges::begin(__range), ranges::end(__range), __value, 
std::ref(__proj)) != ranges::end(__range);
+  }
+};
+} // namespace __contains
+inline namespace __cpo {
+inline constexpr auto contains = __contains::__fn{};
+} // namespace __cpo
+} // namespace ranges
+
+_LIBCPP_END_NAMESPACE_STD
+
+#endif // _LIBCPP_STD_VER >= 23
+
+#endif // _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
diff --git a/libcxx/include/algorithm b/libcxx/include/algorithm
index 76e0d22bf73ef85..003bf132b38b4d8 100644
--- a/libcxx/include/algorithm
+++ b/libcxx/include/algorithm
@@ -226,6 +226,14 @@ namespace ranges {
   template
 using copy_backward_result = in_out_result;
 // since C++20
 
+  template S, class T, class Proj = identity>
+requires indirect_binary_predicate, 
const T*>
+constexpr bool ranges::contains(I first, S last, const T& value, Proj proj 
= {});   // since C++23
+
+  template
+requires indirect_binary_predicate, Proj>, const T*>
+constexpr bool ranges::contains(R&& r, const T& value, Proj proj = {});
 // since C++23
+
   template S, weakly_incrementable O>
 requires indirectly_copyable
 constexpr ranges::copy_result ranges::copy(I first, S last, O 
result);// since C++20
@@ -1827,6 +1835,7 @@ template 
 #include <__algorithm/ranges_any_of.h>
 #include <__algorithm/ranges_binary_search.h>
 #include <__algorithm/ranges_clamp.h>
+#include <__algorithm/ranges_contains.h>
 #include <__algorithm/ranges_copy.h>
 #include <__algorithm/ranges_copy_backward.h>
 #include <__algorithm/ranges_copy_if.h>
diff --git 

[clang] [libc++] Implement ranges::contains (PR #65148)

[via cfe-commits]

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/65148

>From 02e9afd761228f401df4d9f8dfaaca44ffae0c6e Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Thu, 31 Aug 2023 20:08:32 +
Subject: [PATCH 01/16] [libc++] Implement ranges::contains

Differential Revision: https://reviews.llvm.org/D159232
---
 libcxx/include/CMakeLists.txt |   1 +
 libcxx/include/__algorithm/ranges_contains.h  |  60 ++
 libcxx/include/algorithm  |   9 +
 ...obust_against_copying_projections.pass.cpp |   4 +
 .../alg.contains/ranges.contains.pass.cpp | 190 ++
 .../niebloid.compile.pass.cpp |   1 +
 6 files changed, 265 insertions(+)
 create mode 100644 libcxx/include/__algorithm/ranges_contains.h
 create mode 100644 
libcxx/test/std/algorithms/alg.nonmodifying/alg.contains/ranges.contains.pass.cpp

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index 77a7269121ec142..024aa8959fb7200 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -104,6 +104,7 @@ set(files
   __algorithm/ranges_any_of.h
   __algorithm/ranges_binary_search.h
   __algorithm/ranges_clamp.h
+  __algorithm/ranges_contains.h
   __algorithm/ranges_copy.h
   __algorithm/ranges_copy_backward.h
   __algorithm/ranges_copy_if.h
diff --git a/libcxx/include/__algorithm/ranges_contains.h 
b/libcxx/include/__algorithm/ranges_contains.h
new file mode 100644
index 000..647b7ea34be3421
--- /dev/null
+++ b/libcxx/include/__algorithm/ranges_contains.h
@@ -0,0 +1,60 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+#define _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+
+#include <__algorithm/in_in_result.h>
+#include <__algorithm/ranges_find.h>
+#include <__config>
+#include <__functional/identity.h>
+#include <__functional/ranges_operations.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/indirectly_comparable.h>
+#include <__iterator/projected.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace ranges {
+namespace __contains {
+struct __fn {
+  template  _Sent, class _Type, 
class _Proj = identity>
+requires indirect_binary_predicate, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = 
{}) const {
+return ranges::find(std::move(__first), std::move(__last), __value, 
std::ref(__proj)) != __last;
+  }
+
+  template 
+requires indirect_binary_predicate, _Proj>, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) const {
+return ranges::find(ranges::begin(__range), ranges::end(__range), __value, 
std::ref(__proj)) != ranges::end(__range);
+  }
+};
+} // namespace __contains
+inline namespace __cpo {
+inline constexpr auto contains = __contains::__fn{};
+} // namespace __cpo
+} // namespace ranges
+
+_LIBCPP_END_NAMESPACE_STD
+
+#endif // _LIBCPP_STD_VER >= 23
+
+#endif // _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
diff --git a/libcxx/include/algorithm b/libcxx/include/algorithm
index 76e0d22bf73ef85..003bf132b38b4d8 100644
--- a/libcxx/include/algorithm
+++ b/libcxx/include/algorithm
@@ -226,6 +226,14 @@ namespace ranges {
   template
 using copy_backward_result = in_out_result;
 // since C++20
 
+  template S, class T, class Proj = identity>
+requires indirect_binary_predicate, 
const T*>
+constexpr bool ranges::contains(I first, S last, const T& value, Proj proj 
= {});   // since C++23
+
+  template
+requires indirect_binary_predicate, Proj>, const T*>
+constexpr bool ranges::contains(R&& r, const T& value, Proj proj = {});
 // since C++23
+
   template S, weakly_incrementable O>
 requires indirectly_copyable
 constexpr ranges::copy_result ranges::copy(I first, S last, O 
result);// since C++20
@@ -1827,6 +1835,7 @@ template 
 #include <__algorithm/ranges_any_of.h>
 #include <__algorithm/ranges_binary_search.h>
 #include <__algorithm/ranges_clamp.h>
+#include <__algorithm/ranges_contains.h>
 #include <__algorithm/ranges_copy.h>
 #include <__algorithm/ranges_copy_backward.h>
 #include <__algorithm/ranges_copy_if.h>
diff --git 

[clang] [clang][index] Fix processing of CompoundAssignOperator at setting up reference roles (PR #69370)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Aleksandr Platonov (ArcsinX)


Changes

Without this patch in expressions like `foo += 1` reference `foo` has no read 
and write roles.

This happens because `CompoundAssignOperator` is also a `BinaryOperator`, thus 
handling `CompoindAssignOperator` in `else` branch is a dead code.

---
Full diff: https://github.com/llvm/llvm-project/pull/69370.diff


2 Files Affected:

- (modified) clang/lib/Index/IndexBody.cpp (+9-9) 
- (modified) clang/unittests/Index/IndexTests.cpp (+25) 


``diff
diff --git a/clang/lib/Index/IndexBody.cpp b/clang/lib/Index/IndexBody.cpp
index e88f321f18a7129..08136baa5d408e9 100644
--- a/clang/lib/Index/IndexBody.cpp
+++ b/clang/lib/Index/IndexBody.cpp
@@ -77,9 +77,15 @@ class BodyIndexer : public RecursiveASTVisitor {
 const Stmt *Parent = *It;
 
 if (auto BO = dyn_cast(Parent)) {
-  if (BO->getOpcode() == BO_Assign && BO->getLHS()->IgnoreParenCasts() == 
E)
-Roles |= (unsigned)SymbolRole::Write;
-
+  if (BO->getOpcode() == BO_Assign) {
+if (BO->getLHS()->IgnoreParenCasts() == E)
+  Roles |= (unsigned)SymbolRole::Write;
+  } else if (auto CA = dyn_cast(Parent)) {
+if (CA->getLHS()->IgnoreParenCasts() == E) {
+  Roles |= (unsigned)SymbolRole::Read;
+  Roles |= (unsigned)SymbolRole::Write;
+}
+  }
 } else if (auto UO = dyn_cast(Parent)) {
   if (UO->isIncrementDecrementOp()) {
 Roles |= (unsigned)SymbolRole::Read;
@@ -88,12 +94,6 @@ class BodyIndexer : public RecursiveASTVisitor {
 Roles |= (unsigned)SymbolRole::AddressOf;
   }
 
-} else if (auto CA = dyn_cast(Parent)) {
-  if (CA->getLHS()->IgnoreParenCasts() == E) {
-Roles |= (unsigned)SymbolRole::Read;
-Roles |= (unsigned)SymbolRole::Write;
-  }
-
 } else if (auto CE = dyn_cast(Parent)) {
   if (CE->getCallee()->IgnoreParenCasts() == E) {
 addCallRole(Roles, Relations);
diff --git a/clang/unittests/Index/IndexTests.cpp 
b/clang/unittests/Index/IndexTests.cpp
index 4d19f47283c2853..8e9a1c6bf88245c 100644
--- a/clang/unittests/Index/IndexTests.cpp
+++ b/clang/unittests/Index/IndexTests.cpp
@@ -428,6 +428,31 @@ TEST(IndexTest, NonTypeTemplateParameter) {
  WrittenAt(Position(3, 15);
 }
 
+TEST(IndexTest, ReadWriteRoles) {
+  std::string Code = R"cpp(
+int main() {
+  int foo = 0;
+  foo = 2;
+  foo += 1;
+  int bar = foo;
+  }
+  )cpp";
+  auto Index = std::make_shared();
+  IndexingOptions Opts;
+  Opts.IndexFunctionLocals = true;
+  tooling::runToolOnCode(std::make_unique(Index, Opts), Code);
+  EXPECT_THAT(
+  Index->Symbols,
+  AllOf(Contains(AllOf(QName("foo"), HasRole(SymbolRole::Write),
+   WrittenAt(Position(4, 7,
+Contains(AllOf(QName("foo"),
+   HasRole(static_cast(SymbolRole::Read) |
+   static_cast(SymbolRole::Write)),
+   WrittenAt(Position(5, 7,
+Contains(AllOf(QName("foo"), HasRole(SymbolRole::Read),
+   WrittenAt(Position(6, 17));
+}
+
 } // namespace
 } // namespace index
 } // namespace clang

``




https://github.com/llvm/llvm-project/pull/69370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][index] Fix processing of CompoundAssignOperator at setting up reference roles (PR #69370)

[Aleksandr Platonov via cfe-commits]

https://github.com/ArcsinX created 
https://github.com/llvm/llvm-project/pull/69370

Without this patch in expressions like `foo += 1` reference `foo` has no read 
and write roles.

This happens because `CompoundAssignOperator` is also a `BinaryOperator`, thus 
handling `CompoindAssignOperator` in `else` branch is a dead code.

>From 849d366ae5824d7b072fcb28ecad0138dade6324 Mon Sep 17 00:00:00 2001
From: Aleksandr Platonov 
Date: Tue, 17 Oct 2023 21:44:10 +0300
Subject: [PATCH] [clang][index] Fix processing of CompoundAssignOperator at
 setting up reference roles

Without this patch in expressions like `foo += 1` reference `foo` has no read 
and write roles.

This happens because `CompoundAssignOperator` is also a `BinaryOperator`, thus 
handling `CompoindAssignOperator` in `else` branch is a dead code.
---
 clang/lib/Index/IndexBody.cpp| 18 +-
 clang/unittests/Index/IndexTests.cpp | 25 +
 2 files changed, 34 insertions(+), 9 deletions(-)

diff --git a/clang/lib/Index/IndexBody.cpp b/clang/lib/Index/IndexBody.cpp
index e88f321f18a7129..08136baa5d408e9 100644
--- a/clang/lib/Index/IndexBody.cpp
+++ b/clang/lib/Index/IndexBody.cpp
@@ -77,9 +77,15 @@ class BodyIndexer : public RecursiveASTVisitor {
 const Stmt *Parent = *It;
 
 if (auto BO = dyn_cast(Parent)) {
-  if (BO->getOpcode() == BO_Assign && BO->getLHS()->IgnoreParenCasts() == 
E)
-Roles |= (unsigned)SymbolRole::Write;
-
+  if (BO->getOpcode() == BO_Assign) {
+if (BO->getLHS()->IgnoreParenCasts() == E)
+  Roles |= (unsigned)SymbolRole::Write;
+  } else if (auto CA = dyn_cast(Parent)) {
+if (CA->getLHS()->IgnoreParenCasts() == E) {
+  Roles |= (unsigned)SymbolRole::Read;
+  Roles |= (unsigned)SymbolRole::Write;
+}
+  }
 } else if (auto UO = dyn_cast(Parent)) {
   if (UO->isIncrementDecrementOp()) {
 Roles |= (unsigned)SymbolRole::Read;
@@ -88,12 +94,6 @@ class BodyIndexer : public RecursiveASTVisitor {
 Roles |= (unsigned)SymbolRole::AddressOf;
   }
 
-} else if (auto CA = dyn_cast(Parent)) {
-  if (CA->getLHS()->IgnoreParenCasts() == E) {
-Roles |= (unsigned)SymbolRole::Read;
-Roles |= (unsigned)SymbolRole::Write;
-  }
-
 } else if (auto CE = dyn_cast(Parent)) {
   if (CE->getCallee()->IgnoreParenCasts() == E) {
 addCallRole(Roles, Relations);
diff --git a/clang/unittests/Index/IndexTests.cpp 
b/clang/unittests/Index/IndexTests.cpp
index 4d19f47283c2853..8e9a1c6bf88245c 100644
--- a/clang/unittests/Index/IndexTests.cpp
+++ b/clang/unittests/Index/IndexTests.cpp
@@ -428,6 +428,31 @@ TEST(IndexTest, NonTypeTemplateParameter) {
  WrittenAt(Position(3, 15);
 }
 
+TEST(IndexTest, ReadWriteRoles) {
+  std::string Code = R"cpp(
+int main() {
+  int foo = 0;
+  foo = 2;
+  foo += 1;
+  int bar = foo;
+  }
+  )cpp";
+  auto Index = std::make_shared();
+  IndexingOptions Opts;
+  Opts.IndexFunctionLocals = true;
+  tooling::runToolOnCode(std::make_unique(Index, Opts), Code);
+  EXPECT_THAT(
+  Index->Symbols,
+  AllOf(Contains(AllOf(QName("foo"), HasRole(SymbolRole::Write),
+   WrittenAt(Position(4, 7,
+Contains(AllOf(QName("foo"),
+   HasRole(static_cast(SymbolRole::Read) |
+   static_cast(SymbolRole::Write)),
+   WrittenAt(Position(5, 7,
+Contains(AllOf(QName("foo"), HasRole(SymbolRole::Read),
+   WrittenAt(Position(6, 17));
+}
+
 } // namespace
 } // namespace index
 } // namespace clang

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

[clang] [CodeGen] Avoid potential sideeffects from XOR (PR #67193)

[Bill Wendling via cfe-commits]

https://github.com/bwendling closed 
https://github.com/llvm/llvm-project/pull/67193
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver] Link Flang runtime on Solaris (PR #65644)

[Fangrui Song via cfe-commits]

@@ -2,8 +2,9 @@
 ! invocation. These libraries are added on top of other standard runtime
 ! libraries that the Clang driver will include.
 
-! RUN: %flang -### -target ppc64le-linux-gnu %S/Inputs/hello.f90 2>&1 | 
FileCheck %s --check-prefixes=CHECK,GNU
+! RUN: %flang -### -target ppc64le-linux-gnu %S/Inputs/hello.f90 2>&1 | 
FileCheck %s --check-prefixes=CHECK,UNIX

MaskRay wrote:

while changing the lines, change deprecated `-target ` to `--target=`

https://github.com/llvm/llvm-project/pull/65644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver] Link Flang runtime on Solaris (PR #65644)

[Fangrui Song via cfe-commits]

@@ -21,12 +22,12 @@
 !   run on any other platform, such as Windows that use a .exe
 !   suffix. Clang's driver will try to resolve the path to the ld
 !   executable and may find the GNU linker from MinGW or Cygwin.
-! GNU-LABEL:  "{{.*}}ld{{(\.exe)?}}"
-! GNU-SAME: "[[object_file]]"
-! GNU-SAME: -lFortran_main
-! GNU-SAME: -lFortranRuntime
-! GNU-SAME: -lFortranDecimal
-! GNU-SAME: -lm
+! UNIX-LABEL:  "{{.*}}ld{{(\.exe)?}}"
+! UNIX-SAME: "[[object_file]]"
+! UNIX-SAME: -lFortran_main

MaskRay wrote:

Personally I prefer testing `-lx -ly -lz` on one line to assert that is no 
extra argument in between.
This line isn't very long.

https://github.com/llvm/llvm-project/pull/65644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [CodeGen] Avoid potential sideeffects from XOR (PR #67193)

[Bill Wendling via cfe-commits]

@@ -9066,21 +9066,18 @@ bool 
AArch64InstrInfo::shouldOutlineFromFunctionByDefault(
 
 void AArch64InstrInfo::buildClearRegister(Register Reg, MachineBasicBlock ,
   MachineBasicBlock::iterator Iter,
-  DebugLoc ) const {
+  DebugLoc ,
+  bool NoSideEffects) const {
   const MachineFunction  = *MBB.getParent();
   const AArch64Subtarget  = MF.getSubtarget();
   const AArch64RegisterInfo  = *STI.getRegisterInfo();
 
   if (TRI.isGeneralPurposeRegister(MF, Reg)) {
-BuildMI(MBB, Iter, DL, get(AArch64::MOVi64imm), Reg)
-  .addImm(0);
+BuildMI(MBB, Iter, DL, get(AArch64::MOVZXi), Reg).addImm(0).addImm(0);

bwendling wrote:

It does appear to be related to the "shift" argument of `MOVZXi`.

https://github.com/llvm/llvm-project/pull/67193
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [CodeGen] Avoid potential sideeffects from XOR (PR #67193)

[Bill Wendling via cfe-commits]

@@ -9066,21 +9066,18 @@ bool 
AArch64InstrInfo::shouldOutlineFromFunctionByDefault(
 
 void AArch64InstrInfo::buildClearRegister(Register Reg, MachineBasicBlock ,
   MachineBasicBlock::iterator Iter,
-  DebugLoc ) const {
+  DebugLoc ,
+  bool NoSideEffects) const {
   const MachineFunction  = *MBB.getParent();
   const AArch64Subtarget  = MF.getSubtarget();
   const AArch64RegisterInfo  = *STI.getRegisterInfo();
 
   if (TRI.isGeneralPurposeRegister(MF, Reg)) {
-BuildMI(MBB, Iter, DL, get(AArch64::MOVi64imm), Reg)
-  .addImm(0);
+BuildMI(MBB, Iter, DL, get(AArch64::MOVZXi), Reg).addImm(0).addImm(0);

bwendling wrote:

It does appear to be related to the "shift" argument of `MOVZXi`.

https://github.com/llvm/llvm-project/pull/67193
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

[Utkarsh Saxena via cfe-commits]

https://github.com/usx95 closed https://github.com/llvm/llvm-project/pull/68999
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] e6d0b12 - Correctly compute conversion seq for args to fn with reversed param order (#68999)

[via cfe-commits]

Author: Utkarsh Saxena
Date: 2023-10-17T20:53:42+02:00
New Revision: e6d0b126c824222fca2f31a2ba571c2ee2bb4760

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

LOG: Correctly compute conversion seq for args to fn with reversed param order 
(#68999)

We associated conversion seq for args (when reversed) to the wrong
index.
This lead to clang believing reversed `operator==` a worse overload
candidate than the `operator==` without reversed args when both these
candidate were ambiguous.

Fixes https://github.com/llvm/llvm-project/issues/53954

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Sema/SemaOverload.cpp
clang/test/CXX/over/over.match/over.match.funcs/over.match.oper/p3-2a.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 81cbfd90155fe0b..443325bb0d1e17d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -117,6 +117,8 @@ C++ Language Changes
 
 C++20 Feature Support
 ^
+- Fix a bug in conversion sequence of arguments to a function with reversed 
parameter order.
+  Fixes `GH `_.
 
 C++23 Feature Support
 ^

diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index ce78994e6553814..c271cebb9eb638f 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -7688,7 +7688,7 @@ bool Sema::CheckNonDependentConversions(
 QualType ParamType = ParamTypes[I + Offset];
 if (!ParamType->isDependentType()) {
   unsigned ConvIdx = PO == OverloadCandidateParamOrder::Reversed
- ? 0
+ ? Args.size() - 1 - (ThisConversions + I)
  : (ThisConversions + I);
   Conversions[ConvIdx]
 = TryCopyInitialization(*this, Args[I], ParamType,

diff  --git 
a/clang/test/CXX/over/over.match/over.match.funcs/over.match.oper/p3-2a.cpp 
b/clang/test/CXX/over/over.match/over.match.funcs/over.match.oper/p3-2a.cpp
index 5c6804eb7726b5f..02fe37dc1be5058 100644
--- a/clang/test/CXX/over/over.match/over.match.funcs/over.match.oper/p3-2a.cpp
+++ b/clang/test/CXX/over/over.match/over.match.funcs/over.match.oper/p3-2a.cpp
@@ -324,6 +324,41 @@ bool x = X() == X(); // expected-warning {{ambiguous}}
 }
 } // namespace P2468R2
 
+namespace GH53954{
+namespace test1 {
+struct P {
+template 
+friend bool operator==(const P&, const T&); // expected-note {{candidate}} 
\
+  // expected-note {{reversed 
parameter order}}
+};
+struct A : public P {};
+struct B : public P {};
+bool check(A a, B b) { return a == b; } // expected-error {{ '==' is 
ambiguous}}
+}
+
+namespace test2 {
+struct P {
+template 
+friend bool operator==(const T&, const P&); // expected-note {{candidate}} 
\
+// expected-note {{reversed 
parameter order}}
+};
+struct A : public P {};
+struct B : public P {};
+bool check(A a, B b) { return a == b; } // expected-error {{ '==' is 
ambiguous}}
+}
+
+namespace test3 {
+struct P {
+  template
+  bool operator==(const S &) const; // expected-note {{candidate}} \
+// expected-note {{reversed parameter 
order}}
+};
+struct A : public P {};
+struct B : public P {};
+bool check(A a, B b) { return a == b; } // expected-error {{ '==' is 
ambiguous}}
+}
+}
+
 #else // NO_ERRORS
 
 namespace problem_cases {



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

[clang] [CodeGen] Avoid potential sideeffects from XOR (PR #67193)

[Bill Wendling via cfe-commits]

https://github.com/bwendling updated 
https://github.com/llvm/llvm-project/pull/67193

>From 6db37f7f76347a7821d9a95c0fdac4e250df2e78 Mon Sep 17 00:00:00 2001
From: Bill Wendling 
Date: Fri, 22 Sep 2023 12:35:09 -0700
Subject: [PATCH 1/5] [CodeGen] Avoid potential sideeffects from XOR

XOR may change flag values (e.g. for X86 gprs). In the case where that's
not desirable, specify that buildClearRegister() should use MOV instead.
---
 llvm/include/llvm/CodeGen/TargetInstrInfo.h  |  7 +++--
 llvm/lib/Target/AArch64/AArch64InstrInfo.cpp | 14 +
 llvm/lib/Target/AArch64/AArch64InstrInfo.h   |  4 +--
 llvm/lib/Target/X86/X86InstrInfo.cpp | 31 +---
 llvm/lib/Target/X86/X86InstrInfo.h   |  4 +--
 5 files changed, 38 insertions(+), 22 deletions(-)

diff --git a/llvm/include/llvm/CodeGen/TargetInstrInfo.h 
b/llvm/include/llvm/CodeGen/TargetInstrInfo.h
index 04859a50d6fdeb4..7c2bd83d1d623ef 100644
--- a/llvm/include/llvm/CodeGen/TargetInstrInfo.h
+++ b/llvm/include/llvm/CodeGen/TargetInstrInfo.h
@@ -2057,10 +2057,13 @@ class TargetInstrInfo : public MCInstrInfo {
 "Target didn't implement TargetInstrInfo::insertOutlinedCall!");
   }
 
-  /// Insert an architecture-specific instruction to clear a register.
+  /// Insert an architecture-specific instruction to clear a register. If you
+  /// need to avoid sideeffects (e.g. XOR on x86), set \p NoSideEffects to \p
+  /// true.
   virtual void buildClearRegister(Register Reg, MachineBasicBlock ,
   MachineBasicBlock::iterator Iter,
-  DebugLoc ) const {
+  DebugLoc ,
+  bool NoSideEffects = false) const {
 llvm_unreachable(
 "Target didn't implement TargetInstrInfo::buildClearRegister!");
   }
diff --git a/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp 
b/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
index a1e6a8177c10013..3b1e301e576a1b1 100644
--- a/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
+++ b/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
@@ -8337,21 +8337,23 @@ bool 
AArch64InstrInfo::shouldOutlineFromFunctionByDefault(
 
 void AArch64InstrInfo::buildClearRegister(Register Reg, MachineBasicBlock ,
   MachineBasicBlock::iterator Iter,
-  DebugLoc ) const {
+  DebugLoc ,
+  bool NoSideEffects) const {
   const MachineFunction  = *MBB.getParent();
   const AArch64Subtarget  = MF.getSubtarget();
   const AArch64RegisterInfo  = *STI.getRegisterInfo();
 
   if (TRI.isGeneralPurposeRegister(MF, Reg)) {
-BuildMI(MBB, Iter, DL, get(AArch64::MOVi64imm), Reg)
-  .addImm(0);
+BuildMI(MBB, Iter, DL, get(AArch64::MOVZXi), Reg)
+.addImm(0)
+.addImm(0);
   } else if (STI.hasSVE()) {
 BuildMI(MBB, Iter, DL, get(AArch64::DUP_ZI_D), Reg)
-  .addImm(0)
-  .addImm(0);
+.addImm(0)
+.addImm(0);
   } else {
 BuildMI(MBB, Iter, DL, get(AArch64::MOVIv2d_ns), Reg)
-  .addImm(0);
+.addImm(0);
   }
 }
 
diff --git a/llvm/lib/Target/AArch64/AArch64InstrInfo.h 
b/llvm/lib/Target/AArch64/AArch64InstrInfo.h
index 4a4d87c1b1f6ba5..5c5e7e4fe39068a 100644
--- a/llvm/lib/Target/AArch64/AArch64InstrInfo.h
+++ b/llvm/lib/Target/AArch64/AArch64InstrInfo.h
@@ -320,8 +320,8 @@ class AArch64InstrInfo final : public AArch64GenInstrInfo {
   bool shouldOutlineFromFunctionByDefault(MachineFunction ) const override;
 
   void buildClearRegister(Register Reg, MachineBasicBlock ,
-  MachineBasicBlock::iterator Iter,
-  DebugLoc ) const override;
+  MachineBasicBlock::iterator Iter, DebugLoc ,
+  bool NoSideEffects = false) const override;
 
   /// Returns the vector element size (B, H, S or D) of an SVE opcode.
   uint64_t getElementSizeForOpcode(unsigned Opc) const;
diff --git a/llvm/lib/Target/X86/X86InstrInfo.cpp 
b/llvm/lib/Target/X86/X86InstrInfo.cpp
index 73675a868239ea1..24a7d632f951385 100644
--- a/llvm/lib/Target/X86/X86InstrInfo.cpp
+++ b/llvm/lib/Target/X86/X86InstrInfo.cpp
@@ -9796,27 +9796,34 @@ X86InstrInfo::insertOutlinedCall(Module , 
MachineBasicBlock ,
   return It;
 }
 
-void X86InstrInfo::buildClearRegister(Register Reg,
-  MachineBasicBlock ,
+void X86InstrInfo::buildClearRegister(Register Reg, MachineBasicBlock ,
   MachineBasicBlock::iterator Iter,
-  DebugLoc ) const {
+  DebugLoc , bool NoSideEffects) const {
   const MachineFunction  = *MBB.getParent();
   const X86Subtarget  = MF.getSubtarget();
   const TargetRegisterInfo  = getRegisterInfo();
 
   if (ST.hasMMX() && X86::VR64RegClass.contains(Reg))
-// FIXME: Ignore MMX registers?
+  

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

[Utkarsh Saxena via cfe-commits]

usx95 wrote:

+1 I agree that this is confusing and error prone.

https://github.com/llvm/llvm-project/pull/68999
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] [unittest] Add a test for Generic_GCC::GCCVersion::Parse (PR #69078)

[Fangrui Song via cfe-commits]

@@ -0,0 +1,48 @@
+//===- unittests/Driver/GCCVersionTest.cpp --- GCCVersion parser tests 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Unit tests for Generic_GCC::GCCVersion
+//
+//===--===//
+
+#include "../../lib/Driver/ToolChains/Gnu.h"
+#include "gtest/gtest.h"
+
+using namespace clang::driver;

MaskRay wrote:

it's more conventional to place clang before clang::driver

https://github.com/llvm/llvm-project/pull/69078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] [unittest] Add a test for Generic_GCC::GCCVersion::Parse (PR #69078)

[Fangrui Song via cfe-commits]

https://github.com/MaskRay edited 
https://github.com/llvm/llvm-project/pull/69078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] [unittest] Add a test for Generic_GCC::GCCVersion::Parse (PR #69078)

[Fangrui Song via cfe-commits]

https://github.com/MaskRay approved this pull request.


https://github.com/llvm/llvm-project/pull/69078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] [unittest] Add a test for Generic_GCC::GCCVersion::Parse (PR #69078)

[Fangrui Song via cfe-commits]

https://github.com/MaskRay edited 
https://github.com/llvm/llvm-project/pull/69078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] [unittest] Add a test for Generic_GCC::GCCVersion::Parse (PR #69078)

[Fangrui Song via cfe-commits]

@@ -0,0 +1,48 @@
+//===- unittests/Driver/GCCVersionTest.cpp --- GCCVersion parser tests 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Unit tests for Generic_GCC::GCCVersion
+//
+//===--===//
+
+#include "../../lib/Driver/ToolChains/Gnu.h"
+#include "gtest/gtest.h"
+
+using namespace clang::driver;
+using namespace clang;
+
+struct VersionParseTest {
+  std::string Text;
+
+  int Major, Minor, Patch;
+  std::string MajorStr, MinorStr, PatchSuffix;
+};
+
+const VersionParseTest TestCases[] = {
+{"5", 5, -1, -1, "5", "", ""},
+{"4.4", 4, 4, -1, "4", "4", ""},
+{"4.4-patched", 4, 4, -1, "4", "4", "-patched"},
+{"4.4.0", 4, 4, 0, "4", "4", ""},
+{"4.4.x", 4, 4, -1, "4", "4", ""},
+{"4.4.2-rc4", 4, 4, 2, "4", "4", "-rc4"},
+{"4.4.x-patched", 4, 4, -1, "4", "4", ""},
+{"not-a-version", -1, -1, -1, "", "", ""},
+};
+
+TEST(GCCVersionTest, Parse) {
+  for (const auto  : TestCases) {
+auto V = toolchains::Generic_GCC::GCCVersion::Parse(TC.Text);
+ASSERT_EQ(V.Text, TC.Text);

MaskRay wrote:

`EXPECT_EQ`

http://google.github.io/googletest/primer.html

> The assertions come in pairs that test the same thing but have different 
> effects on the current function. ASSERT_* versions generate fatal failures 
> when they fail, and abort the current function. EXPECT_* versions generate 
> nonfatal failures, which don’t abort the current function. Usually EXPECT_* 
> are preferred, as they allow more than one failure to be reported in a test. 
> However, you should use ASSERT_* if it doesn’t make sense to continue when 
> the assertion in question fails.

https://github.com/llvm/llvm-project/pull/69078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] Add check to diagnose coroutine-hostile RAII objects (PR #68738)

[Utkarsh Saxena via cfe-commits]

https://github.com/usx95 closed https://github.com/llvm/llvm-project/pull/68738
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits