[PATCH] D129242: [clang-repl] Add host exception support check utility flag.

2022-07-29 Thread Sunho Kim via Phabricator via cfe-commits
sunho added a comment.

@uabelho Hi, that's a typeinfo symbol of libc++ abi. It's quite weird that 
__cxa_throw is availble while _ZTIPKc is not. Do you have some special setting 
regarding libc++ in your environment?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129242

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


[PATCH] D130470: [clang][analyzer] Add more wide-character functions to CStringChecker

2022-07-29 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:136-137
   {{CDF_MaybeBuiltin, "memcpy", 3},
-   std::bind(&CStringChecker::evalMemcpy, _1, _2, _3, false)},
+   std::bind(&CStringChecker::evalMemcpy, _1, _2, _3,
+ CharacterKind::Regular)},
   {{CDF_MaybeBuiltin, "wmemcpy", 3},

If you were using a plain-old enum, it would feel less repetitive.
You are already in the anonymous namespace, so it would not pollute anything 
anyway.
You could also `use std::bind`, to make it denser.



Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:179
+ CharacterKind::Regular)},
+  //{{CDF_MaybeBuiltin, "bcmp", 3}, &CStringChecker::evalMemcmp},
   {{CDF_MaybeBuiltin, "bzero", 2}, &CStringChecker::evalBzero},

This line looks dead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130470

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


[clang] 9b1897b - [Driver] Use libatomic for 32-bit SPARC atomics support on Linux

2022-07-29 Thread Rainer Orth via cfe-commits

Author: Rainer Orth
Date: 2022-07-29T09:19:38+02:00
New Revision: 9b1897bbd0e3a6e9ef099e74c3d3ed35428c0460

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

LOG: [Driver] Use libatomic for 32-bit SPARC atomics support on Linux

This is the Linux/sparc64 equivalent to D118021
, necessary to provide an external
implementation of atomics on 32-bit SPARC which LLVM cannot inline even
with `-mcpu=v9` or an equivalent default.

Tested on `sparc64-unknown-linux-gnu`.

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp
clang/test/Driver/linux-ld.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 34396b0b59c2..f203cae1d329 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -631,6 +631,16 @@ void tools::gnutools::Linker::ConstructJob(Compilation &C, 
const JobAction &JA,
 
   AddRunTimeLibs(ToolChain, D, CmdArgs, Args);
 
+  // LLVM support for atomics on 32-bit SPARC V8+ is incomplete, so
+  // forcibly link with libatomic as a workaround.
+  // TODO: Issue #41880 and D118021.
+  if (getToolChain().getTriple().getArch() == llvm::Triple::sparc) {
+CmdArgs.push_back("--push-state");
+CmdArgs.push_back("--as-needed");
+CmdArgs.push_back("-latomic");
+CmdArgs.push_back("--pop-state");
+  }
+
   if (WantPthread && !isAndroid)
 CmdArgs.push_back("-lpthread");
 

diff  --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index d7c58431fa76..e76b35d6137c 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -1007,6 +1007,7 @@
 // CHECK-SPARCV8: "{{.*}}ld{{(.exe)?}}"
 // CHECK-SPARCV8: "-m" "elf32_sparc"
 // CHECK-SPARCV8: "-dynamic-linker" 
"{{(/usr/sparc-unknown-linux-gnu)?}}/lib/ld-linux.so.2"
+// CHECK-SPARCV8: "--push-state" "--as-needed" "-latomic" "--pop-state"
 //
 // RUN: %clang -### %s -no-pie 2>&1 \
 // RUN: --target=sparcel-unknown-linux-gnu \
@@ -1021,6 +1022,7 @@
 // CHECK-SPARCV9: "{{.*}}ld{{(.exe)?}}"
 // CHECK-SPARCV9: "-m" "elf64_sparc"
 // CHECK-SPARCV9: "-dynamic-linker" 
"{{(/usr/sparcv9-unknown-linux-gnu)?}}/lib{{(64)?}}/ld-linux.so.2"
+// CHECK-SPARCV9-NOT: "-latomic"
 
 // Test linker invocation on Android.
 // RUN: %clang -### %s -no-pie 2>&1 \



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


[PATCH] D130569: [Driver] Use libatomic for 32-bit SPARC atomics support on Linux

2022-07-29 Thread Rainer Orth via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9b1897bbd0e3: [Driver] Use libatomic for 32-bit SPARC 
atomics support on Linux (authored by ro).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130569

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/test/Driver/linux-ld.c


Index: clang/test/Driver/linux-ld.c
===
--- clang/test/Driver/linux-ld.c
+++ clang/test/Driver/linux-ld.c
@@ -1007,6 +1007,7 @@
 // CHECK-SPARCV8: "{{.*}}ld{{(.exe)?}}"
 // CHECK-SPARCV8: "-m" "elf32_sparc"
 // CHECK-SPARCV8: "-dynamic-linker" 
"{{(/usr/sparc-unknown-linux-gnu)?}}/lib/ld-linux.so.2"
+// CHECK-SPARCV8: "--push-state" "--as-needed" "-latomic" "--pop-state"
 //
 // RUN: %clang -### %s -no-pie 2>&1 \
 // RUN: --target=sparcel-unknown-linux-gnu \
@@ -1021,6 +1022,7 @@
 // CHECK-SPARCV9: "{{.*}}ld{{(.exe)?}}"
 // CHECK-SPARCV9: "-m" "elf64_sparc"
 // CHECK-SPARCV9: "-dynamic-linker" 
"{{(/usr/sparcv9-unknown-linux-gnu)?}}/lib{{(64)?}}/ld-linux.so.2"
+// CHECK-SPARCV9-NOT: "-latomic"
 
 // Test linker invocation on Android.
 // RUN: %clang -### %s -no-pie 2>&1 \
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -631,6 +631,16 @@
 
   AddRunTimeLibs(ToolChain, D, CmdArgs, Args);
 
+  // LLVM support for atomics on 32-bit SPARC V8+ is incomplete, so
+  // forcibly link with libatomic as a workaround.
+  // TODO: Issue #41880 and D118021.
+  if (getToolChain().getTriple().getArch() == llvm::Triple::sparc) {
+CmdArgs.push_back("--push-state");
+CmdArgs.push_back("--as-needed");
+CmdArgs.push_back("-latomic");
+CmdArgs.push_back("--pop-state");
+  }
+
   if (WantPthread && !isAndroid)
 CmdArgs.push_back("-lpthread");
 


Index: clang/test/Driver/linux-ld.c
===
--- clang/test/Driver/linux-ld.c
+++ clang/test/Driver/linux-ld.c
@@ -1007,6 +1007,7 @@
 // CHECK-SPARCV8: "{{.*}}ld{{(.exe)?}}"
 // CHECK-SPARCV8: "-m" "elf32_sparc"
 // CHECK-SPARCV8: "-dynamic-linker" "{{(/usr/sparc-unknown-linux-gnu)?}}/lib/ld-linux.so.2"
+// CHECK-SPARCV8: "--push-state" "--as-needed" "-latomic" "--pop-state"
 //
 // RUN: %clang -### %s -no-pie 2>&1 \
 // RUN: --target=sparcel-unknown-linux-gnu \
@@ -1021,6 +1022,7 @@
 // CHECK-SPARCV9: "{{.*}}ld{{(.exe)?}}"
 // CHECK-SPARCV9: "-m" "elf64_sparc"
 // CHECK-SPARCV9: "-dynamic-linker" "{{(/usr/sparcv9-unknown-linux-gnu)?}}/lib{{(64)?}}/ld-linux.so.2"
+// CHECK-SPARCV9-NOT: "-latomic"
 
 // Test linker invocation on Android.
 // RUN: %clang -### %s -no-pie 2>&1 \
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -631,6 +631,16 @@
 
   AddRunTimeLibs(ToolChain, D, CmdArgs, Args);
 
+  // LLVM support for atomics on 32-bit SPARC V8+ is incomplete, so
+  // forcibly link with libatomic as a workaround.
+  // TODO: Issue #41880 and D118021.
+  if (getToolChain().getTriple().getArch() == llvm::Triple::sparc) {
+CmdArgs.push_back("--push-state");
+CmdArgs.push_back("--as-needed");
+CmdArgs.push_back("-latomic");
+CmdArgs.push_back("--pop-state");
+  }
+
   if (WantPthread && !isAndroid)
 CmdArgs.push_back("-lpthread");
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130273: [clang][Driver] Handle SPARC -mcpu=native etc.

2022-07-29 Thread Rainer Orth via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbf3714884ae4: [clang][Driver] Handle SPARC -mcpu=native etc. 
(authored by ro).

Changed prior to commit:
  https://reviews.llvm.org/D130273?vs=448290&id=448529#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130273

Files:
  clang/lib/Driver/ToolChains/Arch/Sparc.cpp
  clang/lib/Driver/ToolChains/Arch/Sparc.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/sparc-march.c
  clang/test/Driver/sparc-mcpu.c
  clang/test/Driver/sparc-mtune.c

Index: clang/test/Driver/sparc-mtune.c
===
--- /dev/null
+++ clang/test/Driver/sparc-mtune.c
@@ -0,0 +1,21 @@
+// RUN: %clang -target sparcv9 -### -c %s 2>&1 | FileCheck -check-prefix=SPARCV9 %s
+// SPARCV9: "-cc1"{{.*}} "-triple" "sparcv9"
+
+// RUN: %clang -target sparc64 -### -c %s 2>&1 | FileCheck -check-prefix=SPARC64 %s
+// SPARC64: "-cc1"{{.*}} "-triple" "sparc64"
+
+// RUN: %clang -target sparcv9 -mtune=v9 -### -c %s 2>&1 | FileCheck -check-prefix=SPARCV9_V9 %s
+// SPARCV9_V9: "-cc1"{{.*}} "-triple" "sparcv9"{{.*}} "-tune-cpu" "v9"
+
+// RUN: %clang -target sparcv9 -mtune=ultrasparc -### -c %s 2>&1 | FileCheck -check-prefix=SPARCV9_US %s
+// SPARCV9_US: "-cc1"{{.*}} "-triple" "sparcv9"{{.*}} "-tune-cpu" "ultrasparc"
+
+// RUN: %clang -target sparc -### -c %s 2>&1 | FileCheck -check-prefix=SPARC %s
+// SPARC: "-cc1"{{.*}} "-triple" "sparc"
+
+// RUN: %clang -target sparc -mtune=v9 -### -c %s 2>&1 | FileCheck -check-prefix=SPARC_V9 %s
+// SPARC_V9: "-cc1"{{.*}} "-triple" "sparc"{{.*}} "-tune-cpu" "v9"
+
+// RUN: %clang -target sparc -mtune=ultrasparc -### -c %s 2>&1 | FileCheck -check-prefix=SPARC_US %s
+// SPARC_US: "-cc1"{{.*}} "-triple" "sparc"{{.*}} "-tune-cpu" "ultrasparc"
+
Index: clang/test/Driver/sparc-mcpu.c
===
--- /dev/null
+++ clang/test/Driver/sparc-mcpu.c
@@ -0,0 +1,21 @@
+// RUN: %clang -target sparcv9 -### -c %s 2>&1 | FileCheck -check-prefix=SPARCV9 %s
+// SPARCV9: "-cc1"{{.*}} "-triple" "sparcv9"
+
+// RUN: %clang -target sparc64 -### -c %s 2>&1 | FileCheck -check-prefix=SPARC64 %s
+// SPARC64: "-cc1"{{.*}} "-triple" "sparc64"
+
+// RUN: %clang -target sparcv9 -mcpu=v9 -### -c %s 2>&1 | FileCheck -check-prefix=SPARCV9_V9 %s
+// SPARCV9_V9: "-cc1"{{.*}} "-triple" "sparcv9"{{.*}} "-target-cpu" "v9"
+
+// RUN: %clang -target sparcv9 -mcpu=ultrasparc -### -c %s 2>&1 | FileCheck -check-prefix=SPARCV9_US %s
+// SPARCV9_US: "-cc1"{{.*}} "-triple" "sparcv9"{{.*}} "-target-cpu" "ultrasparc"
+
+// RUN: %clang -target sparc -### -c %s 2>&1 | FileCheck -check-prefix=SPARC %s
+// SPARC: "-cc1"{{.*}} "-triple" "sparc"
+
+// RUN: %clang -target sparc -mcpu=v9 -### -c %s 2>&1 | FileCheck -check-prefix=SPARC_V9 %s
+// SPARC_V9: "-cc1"{{.*}} "-triple" "sparc"{{.*}} "-target-cpu" "v9"
+
+// RUN: %clang -target sparc -mcpu=ultrasparc -### -c %s 2>&1 | FileCheck -check-prefix=SPARC_US %s
+// SPARC_US: "-cc1"{{.*}} "-triple" "sparc"{{.*}} "-target-cpu" "ultrasparc"
+
Index: clang/test/Driver/sparc-march.c
===
--- /dev/null
+++ clang/test/Driver/sparc-march.c
@@ -0,0 +1,4 @@
+// RUN: %clang -target sparcv9 -march=v9 -### -c %s 2>&1 | FileCheck %s
+// RUN: %clang -target sparc64 -march=v9 -### -c %s 2>&1 | FileCheck %s
+// RUN: %clang -target sparc -march=v9 -### -c %s 2>&1 | FileCheck %s
+// CHECK: error: unsupported option '-march=' for target
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -12,6 +12,7 @@
 #include "Arch/M68k.h"
 #include "Arch/Mips.h"
 #include "Arch/PPC.h"
+#include "Arch/Sparc.h"
 #include "Arch/SystemZ.h"
 #include "Arch/VE.h"
 #include "Arch/X86.h"
@@ -431,15 +432,15 @@
 
   case llvm::Triple::bpfel:
   case llvm::Triple::bpfeb:
-  case llvm::Triple::sparc:
-  case llvm::Triple::sparcel:
-  case llvm::Triple::sparcv9:
 if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
   return A->getValue();
-if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
-  return "v9";
 return "";
 
+  case llvm::Triple::sparc:
+  case llvm::Triple::sparcel:
+  case llvm::Triple::sparcv9:
+return sparc::getSparcTargetCPU(D, Args, T);
+
   case llvm::Triple::x86:
   case llvm::Triple::x86_64:
 return x86::getX86TargetCPU(D, Args, T);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2213,6 +2213,18 @@
 CmdArgs.push_back("-mfloat-abi");

[clang] bf37148 - [clang][Driver] Handle SPARC -mcpu=native etc.

2022-07-29 Thread Rainer Orth via cfe-commits

Author: Rainer Orth
Date: 2022-07-29T09:27:09+02:00
New Revision: bf3714884ae4b4a0301bc6af78e8b4deff12558b

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

LOG: [clang][Driver] Handle SPARC -mcpu=native etc.

To make use of SPARC support in `getHostCPUName` as implemented by D130272
, this patch uses it to handle
`-mcpu=native` and `-mtune=native`.  To match GCC, this patch rejects
`-march` instead of silently treating it as a no-op.

Tested on `sparcv9-sun-solaris2.11` and checking that those options are
passed on as `-target-cpu` resp. `-tune-cpu` as expected.

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

Added: 
clang/test/Driver/sparc-march.c
clang/test/Driver/sparc-mcpu.c
clang/test/Driver/sparc-mtune.c

Modified: 
clang/lib/Driver/ToolChains/Arch/Sparc.cpp
clang/lib/Driver/ToolChains/Arch/Sparc.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/CommonArgs.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/Sparc.cpp 
b/clang/lib/Driver/ToolChains/Arch/Sparc.cpp
index 70ba8eb2a7d0..2c9d65e7714a 100644
--- a/clang/lib/Driver/ToolChains/Arch/Sparc.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/Sparc.cpp
@@ -12,6 +12,7 @@
 #include "clang/Driver/Options.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Option/ArgList.h"
+#include "llvm/Support/Host.h"
 
 using namespace clang::driver;
 using namespace clang::driver::tools;
@@ -113,6 +114,30 @@ sparc::FloatABI sparc::getSparcFloatABI(const Driver &D,
   return ABI;
 }
 
+std::string sparc::getSparcTargetCPU(const Driver &D, const ArgList &Args,
+ const llvm::Triple &Triple) {
+  if (const Arg *A = Args.getLastArg(clang::driver::options::OPT_march_EQ)) {
+D.Diag(diag::err_drv_unsupported_opt_for_target)
+<< A->getSpelling() << Triple.getTriple();
+return "";
+  }
+
+  if (const Arg *A = Args.getLastArg(clang::driver::options::OPT_mcpu_EQ)) {
+StringRef CPUName = A->getValue();
+if (CPUName == "native") {
+  std::string CPU = std::string(llvm::sys::getHostCPUName());
+  if (!CPU.empty() && CPU != "generic")
+return CPU;
+  return "";
+}
+return std::string(CPUName);
+  }
+
+  if (Triple.getArch() == llvm::Triple::sparc && Triple.isOSSolaris())
+return "v9";
+  return "";
+}
+
 void sparc::getSparcTargetFeatures(const Driver &D, const ArgList &Args,
std::vector &Features) {
   sparc::FloatABI FloatABI = sparc::getSparcFloatABI(D, Args);

diff  --git a/clang/lib/Driver/ToolChains/Arch/Sparc.h 
b/clang/lib/Driver/ToolChains/Arch/Sparc.h
index d12a9a70e264..44658c4259c6 100644
--- a/clang/lib/Driver/ToolChains/Arch/Sparc.h
+++ b/clang/lib/Driver/ToolChains/Arch/Sparc.h
@@ -28,6 +28,9 @@ enum class FloatABI {
 
 FloatABI getSparcFloatABI(const Driver &D, const llvm::opt::ArgList &Args);
 
+std::string getSparcTargetCPU(const Driver &D, const llvm::opt::ArgList &Args,
+  const llvm::Triple &Triple);
+
 void getSparcTargetFeatures(const Driver &D, const llvm::opt::ArgList &Args,
 std::vector &Features);
 const char *getSparcAsmModeForCPU(llvm::StringRef Name,

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index e94a4e814510..f41d6f4228b6 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2213,6 +2213,18 @@ void Clang::AddSparcTargetArgs(const ArgList &Args,
 CmdArgs.push_back("-mfloat-abi");
 CmdArgs.push_back("hard");
   }
+
+  if (const Arg *A = Args.getLastArg(clang::driver::options::OPT_mtune_EQ)) {
+StringRef Name = A->getValue();
+std::string TuneCPU;
+if (Name == "native")
+  TuneCPU = std::string(llvm::sys::getHostCPUName());
+else
+  TuneCPU = std::string(Name);
+
+CmdArgs.push_back("-tune-cpu");
+CmdArgs.push_back(Args.MakeArgString(TuneCPU));
+  }
 }
 
 void Clang::AddSystemZTargetArgs(const ArgList &Args,

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 05afa712a809..77ce0395cf3c 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -12,6 +12,7 @@
 #include "Arch/M68k.h"
 #include "Arch/Mips.h"
 #include "Arch/PPC.h"
+#include "Arch/Sparc.h"
 #include "Arch/SystemZ.h"
 #include "Arch/VE.h"
 #include "Arch/X86.h"
@@ -431,15 +432,15 @@ std::string tools::getCPUName(const Driver &D, const 
ArgList &Args,
 
   case llvm::Triple::bpfel:
   case llvm::Triple::bpfeb:
-  case llvm::Triple::sparc:
-  case llvm::Triple::sparcel:
-  case llvm::Triple::sparcv9:
 if (const Arg *A = Args.getLastArg(options::OPT

[PATCH] D130688: [Driver][Sparc] Default to -mcpu=v9 for SparcV8 on Linux

2022-07-29 Thread Rainer Orth via Phabricator via cfe-commits
ro added a comment.

In D130688#3686512 , @MaskRay wrote:

> Making the behavior different for different Linux distributions is not great, 
> but if it matches the practice, I think it is fine.

It's the best we can do in `clang`, I fear, due to the compiler's desire to 
decide as much as possible at runtime.  GCC is way more static here, and 
whoever builds it can decide on the default CPU with `--with-cpu=v9` e.g. at 
configure time.

> I don't know Sparc enough to suggest anything for 32-bit, though...

An alternative would be to just check the host CPU with `getHostCPUName` as 
updated by D130272 .  That CPU name then 
needs to be checked if it supports the V9 ISA.  That could be done using 
`getCPUGeneration(CPU) == CG_V9` in `clang/lib/Basic/Targets/Sparc.h`.  
However, `SparcTargetInfo` (or `TargetInfo` in general) is not currently used 
inside the driver code.

Of course, this only works in the native case, but that's true for distro 
checks, too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130688

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


[PATCH] D130747: [pseudo] wip/prototype: eliminate identifier ambiguities in the grammar.

2022-07-29 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added reviewers: sammccall, usaxena95.
Herald added a project: All.
hokein requested review of this revision.
Herald added a subscriber: alextsao1999.
Herald added a project: clang-tools-extra.

See https://reviews.llvm.org/D130626 for details;

A prototype to eliminate "local" identifier ambiguties in the grammar:

- use a unified type-name instead, and remove all different type rules ( 
class-name/enum-name/typedef-name), this eliminates the top#1 type-name 
ambiguity;
- use a generic identifier for nested-name-specifier, and don't distinguish 
with the type-name and namespace-name cases;
- remove template-name rule, it is mainly used for the template argument 
deduction in simple-type-specifier, it has the same syntax with type-name, 
merged with type-name case;

After this patch, remaining ambiguities are real ambiguities in C++:
Some numbers with this patch:

| file | ambiguous nodes | forest size  | glrParse 
performance |
| SemaCodeComplete.cpp | 1.1w -> 2k  | 10.4MB -> 7.12MB | 7.1MB/s -> 11MB/s 
   |
| AST.cpp  | 1.3k -> 286 | 0.99MB -> 0.68MB | 6.7MB/s -> 
9.9MB/s   |


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130747

Files:
  clang-tools-extra/pseudo/lib/cxx/CXX.cpp
  clang-tools-extra/pseudo/lib/cxx/cxx.bnf

Index: clang-tools-extra/pseudo/lib/cxx/cxx.bnf
===
--- clang-tools-extra/pseudo/lib/cxx/cxx.bnf
+++ clang-tools-extra/pseudo/lib/cxx/cxx.bnf
@@ -34,15 +34,15 @@
 _ := declaration-seq
 
 # gram.key
-typedef-name := IDENTIFIER
-typedef-name := simple-template-id
+#typedef-name := IDENTIFIER
+#typedef-name := simple-template-id
 namespace-name := IDENTIFIER
-namespace-name := namespace-alias
-namespace-alias := IDENTIFIER
-class-name := IDENTIFIER
-class-name := simple-template-id
-enum-name := IDENTIFIER
-template-name := IDENTIFIER
+#namespace-name := namespace-alias
+#namespace-alias := IDENTIFIER
+#class-name := IDENTIFIER
+#class-name := simple-template-id
+#enum-name := IDENTIFIER
+#template-name := IDENTIFIER
 
 # gram.basic
 #! Custom modifications to eliminate optional declaration-seq
@@ -69,8 +69,10 @@
 unqualified-id := template-id
 qualified-id := nested-name-specifier TEMPLATE_opt unqualified-id
 nested-name-specifier := :: [guard]
-nested-name-specifier := type-name ::
-nested-name-specifier := namespace-name ::
+#nested-name-specifier := type-name ::
+#nested-name-specifier := namespace-name ::
+nested-name-specifier := IDENTIFIER ::
+nested-name-specifier := simple-template-id ::
 nested-name-specifier := decltype-specifier ::
 nested-name-specifier := nested-name-specifier IDENTIFIER ::
 nested-name-specifier := nested-name-specifier TEMPLATE_opt simple-template-id ::
@@ -374,7 +376,7 @@
 simple-type-specifier := nested-name-specifier TEMPLATE simple-template-id
 simple-type-specifier := decltype-specifier
 simple-type-specifier := placeholder-type-specifier
-simple-type-specifier := nested-name-specifier_opt template-name
+#simple-type-specifier := nested-name-specifier_opt template-name
 simple-type-specifier := builtin-type
 builtin-type := CHAR
 builtin-type := CHAR8_T
@@ -390,9 +392,12 @@
 builtin-type := FLOAT
 builtin-type := DOUBLE
 builtin-type := VOID
-type-name := class-name
-type-name := enum-name
-type-name := typedef-name
+#type-name := class-name
+#type-name := enum-name
+#type-name := typedef-name
+type-name := IDENTIFIER
+type-name := simple-template-id
+
 elaborated-type-specifier := class-key nested-name-specifier_opt IDENTIFIER
 elaborated-type-specifier := class-key simple-template-id
 elaborated-type-specifier := class-key nested-name-specifier TEMPLATE_opt simple-template-id
@@ -550,7 +555,8 @@
 class-specifier := class-head { member-specification_opt [recover=Brackets] }
 class-head := class-key class-head-name class-virt-specifier_opt base-clause_opt
 class-head := class-key base-clause_opt
-class-head-name := nested-name-specifier_opt class-name
+class-head-name := nested-name-specifier_opt IDENTIFIER
+class-head-name := nested-name-specifier_opt simple-template-id
 class-virt-specifier := contextual-final
 class-key := CLASS
 class-key := STRUCT
@@ -674,7 +680,7 @@
 type-parameter-key := TYPENAME
 type-constraint := nested-name-specifier_opt concept-name
 type-constraint := nested-name-specifier_opt concept-name < template-argument-list_opt >
-simple-template-id := template-name < template-argument-list_opt >
+simple-template-id := IDENTIFIER < template-argument-list_opt >
 template-id := simple-template-id
 template-id := operator-function-id < template-argument-list_opt >
 template-id := literal-operator-id < template-argument-list_opt >
@@ -684,7 +690,7 @@
 template-argument := type-id
 template-argument := id-expression
 constraint-expression := logical-or-expression
-deduction-guide := explicit-specifier_opt template-name ( parameter-declaration-list_opt ) -> simple-template-id ;
+d

[PATCH] D129242: [clang-repl] Add host exception support check utility flag.

2022-07-29 Thread Mikael Holmén via Phabricator via cfe-commits
uabelho added a comment.

In D129242#3686610 , @sunho wrote:

> @uabelho Hi, that's a typeinfo symbol of libc++ abi. It's quite weird that 
> __cxa_throw is availble while _ZTIPKc is not. Do you have some special 
> setting regarding libc++ in your environment?

We compile with clang 8 on a RHEL7 machine, but since we then got too old libs 
we do

  
--gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler

since we have newer libs there. This is seen in the cmake command:

  cmake command: CC='/proj/flexasic/app/llvm/8.0/bin/clang -march=corei7 
--gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler'
 CXX='/proj/flexasic/app/llvm/8.0/bin/clang++ -march=corei7 
--gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler'
 LDFLAGS='-Wl,-R/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1/lib64' 
PATH=/proj/flexasic/app/ninja/1.8.2/SLED11-64/bin:$PATH  
/app/vbuild/RHEL7-x86_64/cmake/3.16.4/bin/cmake /repo/uabelho/main-github/llvm 
--debug-trycompile -G Ninja 
-DCMAKE_MAKE_PROGRAM=/proj/flexasic/app/ninja/1.8.2/SLED11-64/bin/ninja 
-DCMAKE_BUILD_TYPE=Release 
-DCMAKE_C_FLAGS='-Wno-error=unused-command-line-argument' 
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_INSTALL_PREFIX=/compiler-clang 
-DLLVM_APPEND_VC_REV=OFF -DLLVM_CCACHE_DIR=/repo/uabelho/.ccache/ 
-DLLVM_CCACHE_BUILD=ON 
-DLLVM_CCACHE_PROGRAM=/app/vbuild/RHEL7-x86_64/ccache/3.2.2/bin/ccache 
-DLLVM_CCACHE_NOHASHDIR=ON -DLLVM_CCACHE_BASEDIR=/repo 
-DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_WERROR=ON 
-DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld' -DLLVM_ENABLE_Z3_SOLVER=ON 
-DLLVM_Z3_INSTALL_DIR=/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1 
-DLLVM_ENABLE_LIBPFM=OFF -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_TERMINFO=OFF 
-DLLVM_ENABLE_LIBEDIT=OFF -DLLVM_STATIC_LINK_CXX_STDLIB=ON 
-DCLANG_ENABLE_ARCMT=OFF -DCLANG_TOOLING_BUILD_AST_INTROSPECTION=OFF

Could it be something like that there is a mismatch somewhere so the support 
checks will use some libs but then the actual libs used when compiling/running 
is something else?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129242

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


[PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread Tobias Hieta via Phabricator via cfe-commits
thieta added a comment.

In D130689#3686397 , @thakis wrote:

> It'd be nice if this was landed opt-in behind some cmake variable at first, 
> so that folks could try it out on their bots and see how well things work.

You can already test this with `-DCMAKE_CXX_STANDARD=17` afaik. I wonder how 
many bot owners would actually test this if we made another flag available.

Since we can already test this with a current flag maybe we should just post to 
discourse that bot-owners can test it and a date when this will be merged. But 
I don't expect this to be a big problem, when we merged the soft error earlier 
this year - it only broke one bot which was out of date.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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


[PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread Tobias Hieta via Phabricator via cfe-commits
thieta added a comment.

In D130689#3684399 , @h-vetinari 
wrote:

> It may be worth calling out that this is about C++17 core language and not 
> the standard library?
>
> libstdcxx only finished C++17 support in GCC 12, and libcxx is still missing 
> various pieces even today (much less for Clang 5).

I will add a small line about this in the coding standards document.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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


[PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread Tobias Hieta via Phabricator via cfe-commits
thieta added a comment.

In D130689#3686718 , @thieta wrote:

> In D130689#3684399 , @h-vetinari 
> wrote:
>
>> It may be worth calling out that this is about C++17 core language and not 
>> the standard library?
>>
>> libstdcxx only finished C++17 support in GCC 12, and libcxx is still missing 
>> various pieces even today (much less for Clang 5).
>
> I will add a small line about this in the coding standards document.

Actually - never mind this is already well documented in the coding standards 
document:

  Unless otherwise documented, LLVM subprojects are written using standard C++17
  code and avoid unnecessary vendor-specific extensions.
  
  Nevertheless, we restrict ourselves to features which are available in the
  major toolchains supported as host compilers (see :doc:`GettingStarted` page,
  section `Software`).
  
  Each toolchain provides a good reference for what it accepts:
  
  * Clang: https://clang.llvm.org/cxx_status.html
  * GCC: https://gcc.gnu.org/projects/cxx-status.html#cxx17
  * MSVC: https://msdn.microsoft.com/en-us/library/hh567368.aspx

I feel that's good enough.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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


[PATCH] D122768: [Clang][C++20] Support capturing structured bindings in lambdas

2022-07-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 448539.
cor3ntin added a comment.

Put `isInitCapture` in `ValueDecl`.

This allows a few code simplification in the resst of the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122768

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/AST/LambdaCapture.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/Analysis/AnalysisDeclContext.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/WebKit/UncountedLambdaCapturesChecker.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp
  clang/test/CodeGenCXX/cxx20-decomposition.cpp
  clang/test/SemaCXX/cxx1z-decomposition.cpp
  clang/test/SemaCXX/cxx20-decomposition.cpp
  clang/test/SemaCXX/decomposition-blocks.cpp
  clang/test/SemaCXX/decomposition-openmp.cpp
  clang/tools/libclang/CIndex.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1140,7 +1140,7 @@
 
   Structured binding extensions
   https://wg21.link/p1091r3";>P1091R3
-  Partial
+  Clang 16
 
   
 https://wg21.link/p1381r1";>P1381R1
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -3482,9 +3482,11 @@
C != CEnd; ++C) {
 if (!C->capturesVariable())
   continue;
-
-if (Visit(MakeCursorVariableRef(C->getCapturedVar(), C->getLocation(),
-TU)))
+// TODO: handle structured bindings here ?
+if (!isa(C->getCapturedVar()))
+  continue;
+if (Visit(MakeCursorVariableRef(cast(C->getCapturedVar()),
+C->getLocation(), TU)))
   return true;
   }
   // Visit init captures
Index: clang/test/SemaCXX/decomposition-openmp.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/decomposition-openmp.cpp
@@ -0,0 +1,13 @@
+
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 -fopenmp %s
+
+// FIXME: OpenMP should support capturing structured bindings
+auto f() {
+  int i[2] = {};
+  auto [a, b] = i; // expected-note 2{{declared here}}
+  return [=, &a] {
+// expected-error@-1 {{capturing a structured binding is not yet supported in OpenMP}}
+return a + b;
+// expected-error@-1 {{capturing a structured binding is not yet supported in OpenMP}}
+  };
+}
Index: clang/test/SemaCXX/decomposition-blocks.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/decomposition-blocks.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify %s -fblocks
+
+struct S {
+  int i : 1;
+  int j;
+};
+
+void run(void (^)());
+void test() {
+  auto [i, j] = S{1, 42}; // expected-note {{'i' declared here}}
+  run(^{
+(void)i; // expected-error {{reference to local binding 'i' declared in enclosing function 'test'}}
+  });
+}
Index: clang/test/SemaCXX/cxx20-decomposition.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx20-decomposition.cpp
@@ -0,0 +1,141 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+// expected-no-diagnostics
+
+template 
+constexpr bool is_same = false;
+template 
+constexpr bool is_same = true;
+
+struct S {
+  int i;
+  int &j;
+};
+
+void check_category() {
+  int a = 42;
+  {
+auto [v, r] = S{1, a};
+(void)[ v, r ] {
+  static_assert(is_same);
+  static_assert(is_same);
+};
+  }
+  {
+auto [v, r] = S{1, a};
+(void)[&v, &r ] {
+  static_assert(is_same);
+  static_assert(is_same);
+};
+  }
+  {
+S s{1, a};
+const auto &[v, r] = s;
+(void)[ v, r ] {
+  static_ass

[PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread H. Vetinari via Phabricator via cfe-commits
h-vetinari added a comment.

From the text you quoted:

> LLVM subprojects are written using standard C++17

code and avoid unnecessary vendor-specific extensions.

I don't think the standard library can be called a vendor-specific extension, 
and so I think this still could/should be made clearer (even though the status 
links below would show upon inspection that there's no full support yet, but 
that's a bit too tucked away I feel).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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


[PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread Tobias Hieta via Phabricator via cfe-commits
thieta added a comment.

In D130689#3686723 , @h-vetinari 
wrote:

> I don't think the standard library can be called a vendor-specific extension, 
> and so I think this still could/should be made clearer (even though the 
> status links below would show upon inspection that there's no full support 
> yet, but that's a bit too tucked away I feel).

For libstdc++ and libc++ there are also pages with status in a specific 
version. Maybe we should link those matrixes as well?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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


[PATCH] D130224: [Clang][Attribute] Introduce maybe_undef attribute for function arguments which accepts undef values

2022-07-29 Thread Nuno Lopes via Phabricator via cfe-commits
nlopes added a comment.

Would it be possible to implement this by dropping the `noundef` attribute 
rather than emitting a freeze? Seems like a much better option to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130224

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


[PATCH] D122768: [Clang][C++20] Support capturing structured bindings in lambdas

2022-07-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 448543.
cor3ntin marked 7 inline comments as done.
cor3ntin added a comment.

Add comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122768

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/AST/LambdaCapture.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/Analysis/AnalysisDeclContext.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/WebKit/UncountedLambdaCapturesChecker.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp
  clang/test/CodeGenCXX/cxx20-decomposition.cpp
  clang/test/SemaCXX/cxx1z-decomposition.cpp
  clang/test/SemaCXX/cxx20-decomposition.cpp
  clang/test/SemaCXX/decomposition-blocks.cpp
  clang/test/SemaCXX/decomposition-openmp.cpp
  clang/tools/libclang/CIndex.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1140,7 +1140,7 @@
 
   Structured binding extensions
   https://wg21.link/p1091r3";>P1091R3
-  Partial
+  Clang 16
 
   
 https://wg21.link/p1381r1";>P1381R1
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -3482,9 +3482,11 @@
C != CEnd; ++C) {
 if (!C->capturesVariable())
   continue;
-
-if (Visit(MakeCursorVariableRef(C->getCapturedVar(), C->getLocation(),
-TU)))
+// TODO: handle structured bindings here ?
+if (!isa(C->getCapturedVar()))
+  continue;
+if (Visit(MakeCursorVariableRef(cast(C->getCapturedVar()),
+C->getLocation(), TU)))
   return true;
   }
   // Visit init captures
Index: clang/test/SemaCXX/decomposition-openmp.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/decomposition-openmp.cpp
@@ -0,0 +1,13 @@
+
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 -fopenmp %s
+
+// FIXME: OpenMP should support capturing structured bindings
+auto f() {
+  int i[2] = {};
+  auto [a, b] = i; // expected-note 2{{declared here}}
+  return [=, &a] {
+// expected-error@-1 {{capturing a structured binding is not yet supported in OpenMP}}
+return a + b;
+// expected-error@-1 {{capturing a structured binding is not yet supported in OpenMP}}
+  };
+}
Index: clang/test/SemaCXX/decomposition-blocks.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/decomposition-blocks.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify %s -fblocks
+
+struct S {
+  int i : 1;
+  int j;
+};
+
+void run(void (^)());
+void test() {
+  auto [i, j] = S{1, 42}; // expected-note {{'i' declared here}}
+  run(^{
+(void)i; // expected-error {{reference to local binding 'i' declared in enclosing function 'test'}}
+  });
+}
Index: clang/test/SemaCXX/cxx20-decomposition.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx20-decomposition.cpp
@@ -0,0 +1,141 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+// expected-no-diagnostics
+
+template 
+constexpr bool is_same = false;
+template 
+constexpr bool is_same = true;
+
+struct S {
+  int i;
+  int &j;
+};
+
+void check_category() {
+  int a = 42;
+  {
+auto [v, r] = S{1, a};
+(void)[ v, r ] {
+  static_assert(is_same);
+  static_assert(is_same);
+};
+  }
+  {
+auto [v, r] = S{1, a};
+(void)[&v, &r ] {
+  static_assert(is_same);
+  static_assert(is_same);
+};
+  }
+  {
+S s{1, a};
+const auto &[v, r] = s;
+(void)[ v, r ] {
+  static_assert(is_same);
+  static_assert(is_same);
+

[PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread H. Vetinari via Phabricator via cfe-commits
h-vetinari added a comment.

My point boils down to: "written using standard C++17
code" does not sound at all like "core language, no stdlib", but very much like 
"core+stdlib".

This is also the first time this split becomes relevant AFAIK, because for 
moving to C++14, the stdlib was ready basically around the same time / compiler 
versions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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


[PATCH] D122768: [Clang][C++20] Support capturing structured bindings in lambdas

2022-07-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 448544.
cor3ntin added a comment.

Rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122768

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/AST/LambdaCapture.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/Analysis/AnalysisDeclContext.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/WebKit/UncountedLambdaCapturesChecker.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp
  clang/test/CodeGenCXX/cxx20-decomposition.cpp
  clang/test/SemaCXX/cxx1z-decomposition.cpp
  clang/test/SemaCXX/cxx20-decomposition.cpp
  clang/test/SemaCXX/decomposition-blocks.cpp
  clang/test/SemaCXX/decomposition-openmp.cpp
  clang/tools/libclang/CIndex.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1140,7 +1140,7 @@
 
   Structured binding extensions
   https://wg21.link/p1091r3";>P1091R3
-  Partial
+  Clang 16
 
   
 https://wg21.link/p1381r1";>P1381R1
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -3482,9 +3482,11 @@
C != CEnd; ++C) {
 if (!C->capturesVariable())
   continue;
-
-if (Visit(MakeCursorVariableRef(C->getCapturedVar(), C->getLocation(),
-TU)))
+// TODO: handle structured bindings here ?
+if (!isa(C->getCapturedVar()))
+  continue;
+if (Visit(MakeCursorVariableRef(cast(C->getCapturedVar()),
+C->getLocation(), TU)))
   return true;
   }
   // Visit init captures
Index: clang/test/SemaCXX/decomposition-openmp.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/decomposition-openmp.cpp
@@ -0,0 +1,13 @@
+
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 -fopenmp %s
+
+// FIXME: OpenMP should support capturing structured bindings
+auto f() {
+  int i[2] = {};
+  auto [a, b] = i; // expected-note 2{{declared here}}
+  return [=, &a] {
+// expected-error@-1 {{capturing a structured binding is not yet supported in OpenMP}}
+return a + b;
+// expected-error@-1 {{capturing a structured binding is not yet supported in OpenMP}}
+  };
+}
Index: clang/test/SemaCXX/decomposition-blocks.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/decomposition-blocks.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify %s -fblocks
+
+struct S {
+  int i : 1;
+  int j;
+};
+
+void run(void (^)());
+void test() {
+  auto [i, j] = S{1, 42}; // expected-note {{'i' declared here}}
+  run(^{
+(void)i; // expected-error {{reference to local binding 'i' declared in enclosing function 'test'}}
+  });
+}
Index: clang/test/SemaCXX/cxx20-decomposition.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx20-decomposition.cpp
@@ -0,0 +1,141 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+// expected-no-diagnostics
+
+template 
+constexpr bool is_same = false;
+template 
+constexpr bool is_same = true;
+
+struct S {
+  int i;
+  int &j;
+};
+
+void check_category() {
+  int a = 42;
+  {
+auto [v, r] = S{1, a};
+(void)[ v, r ] {
+  static_assert(is_same);
+  static_assert(is_same);
+};
+  }
+  {
+auto [v, r] = S{1, a};
+(void)[&v, &r ] {
+  static_assert(is_same);
+  static_assert(is_same);
+};
+  }
+  {
+S s{1, a};
+const auto &[v, r] = s;
+(void)[ v, r ] {
+  static_assert(is_same);
+  static_assert(is_same);
+};
+  }
+  {
+S s{1, a};
+const auto

[PATCH] D130550: [pseudo] Start rules are `_ := start-symbol EOF`, improve recovery.

2022-07-29 Thread Haojian Wu via Phabricator via cfe-commits
hokein added inline comments.



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/GLR.h:74
 bool GCParity;
+// Have we already used this node for error recovery? (prevents loops)
+mutable bool Recovered = false;

sammccall wrote:
> hokein wrote:
> > haven't look at it deeply -- is this bug related to this eof change? This 
> > looks like a different bug in recovery.
> They're "related" in that they both fix repeated-recovery scenarios.
> This change fixes that we can hit an infinite loop when applying recovery 
> repeatedly.
> The eof change fixes that recovery is (erroneously) only applied once at eof.
> 
> I hoped to cover them with the same testcase, which tests repeated recovery 
> at EOF. I can extract this change with a separate test if you like, though it 
> will be very similar to the one I have here.
> This change fixes that we can hit an infinite loop when applying recovery 
> repeatedly.

I'm more worried about this bug, I think this is an important bug, worth a 
separate patch to fix it, right now it looks like a join-effort in the eof 
change. 

> The eof change fixes that recovery is (erroneously) only applied once at eof.

Not sure I follow this. I think the eof change is basically to remove a 
technical debt (avoid the special case and repeated code after main parsing 
loop).  Am I missing something?




Comment at: clang-tools-extra/pseudo/lib/Forest.cpp:191
+  // This is important to drive the final shift/recover/reduce loop.
+  new (&Terminals[Index])
+  ForestNode(ForestNode::Terminal, tokenSymbol(tok::eof),

sammccall wrote:
> hokein wrote:
> > nit: in the underlying TokenStream implementation, `tokens()` has a 
> > trailing eof token, I think we can fold this into the above loop (if we 
> > expose a `token_eof()` method in TokenStream). Not sure we should do this. 
> I think this doesn't generalize well... at the moment we're parsing the whole 
> stream, but in future we likely want to parse a subrange (pp-disabled 
> regions?). In such a case we would still want the terminating EOF terminal as 
> a device for parsing, even though there's no corresponding token.
oh, ok, that's fair enough.



Comment at: clang-tools-extra/pseudo/test/lr-build-basic.test:16
 # GRAPH-NEXT: State 3
 # GRAPH-NEXT: id := IDENTIFIER • 
 

there should be a State 4 (with a `_ := expr EOF •` item)



Comment at: clang-tools-extra/pseudo/unittests/GLRTest.cpp:622
+  TestLang.Table = LRTable::buildSLR(TestLang.G);
+  llvm::errs() << TestLang.Table.dumpForTests(TestLang.G);
+  TestLang.RecoveryStrategies.try_emplace(

remove the debugging statement.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130550

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


[PATCH] D130470: [clang][analyzer] Add more wide-character functions to CStringChecker

2022-07-29 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 448546.
balazske marked an inline comment as done.
balazske added a comment.

Use shorter enum names, remove unneeded line.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130470

Files:
  clang/docs/analyzer/checkers.rst
  clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
  clang/test/Analysis/wstring.c

Index: clang/test/Analysis/wstring.c
===
--- clang/test/Analysis/wstring.c
+++ clang/test/Analysis/wstring.c
@@ -33,7 +33,7 @@
 void clang_analyzer_eval(int);
 
 //===--===
-// wwmemcpy()
+// wmemcpy()
 //===--===
 
 #define wmemcpy BUILTIN(wmemcpy)
@@ -139,6 +139,255 @@
   clang_analyzer_eval(result == a); // no-warning (above is fatal)
 }
 
+//===--===
+// wmempcpy()
+//===--===
+
+wchar_t *wmempcpy(wchar_t *restrict s1, const wchar_t *restrict s2, size_t n);
+
+void wmempcpy0 (void) {
+  wchar_t src[] = {1, 2, 3, 4};
+  wchar_t dst[5] = {0};
+
+  wmempcpy(dst, src, 4); // no-warning
+
+  clang_analyzer_eval(wmempcpy(dst, src, 4) == &dst[4]); // expected-warning{{TRUE}}
+
+  // If we actually model the copy, we can make this known.
+  // The important thing for now is that the old value has been invalidated.
+  clang_analyzer_eval(dst[0] != 0); // expected-warning{{UNKNOWN}}
+}
+
+void wmempcpy1 (void) {
+  wchar_t src[] = {1, 2, 3, 4};
+  wchar_t dst[10];
+
+  wmempcpy(dst, src, 5); // expected-warning{{Memory copy function accesses out-of-bound array element}}
+}
+
+void wmempcpy2 (void) {
+  wchar_t src[] = {1, 2, 3, 4};
+  wchar_t dst[1];
+
+  wmempcpy(dst, src, 4); // expected-warning{{Memory copy function overflows the destination buffer}}
+}
+
+void wmempcpy3 (void) {
+  wchar_t src[] = {1, 2, 3, 4};
+  wchar_t dst[3];
+
+  wmempcpy(dst+1, src+2, 2); // no-warning
+}
+
+void wmempcpy4 (void) {
+  wchar_t src[] = {1, 2, 3, 4};
+  wchar_t dst[10];
+
+  wmempcpy(dst+2, src+2, 3); // expected-warning{{Memory copy function accesses out-of-bound array element}}
+}
+
+void wmempcpy5(void) {
+  wchar_t src[] = {1, 2, 3, 4};
+  wchar_t dst[3];
+
+  wmempcpy(dst + 2, src + 2, 2); // expected-warning{{Memory copy function overflows the destination buffer}}
+}
+
+void wmempcpy6(void) {
+  wchar_t a[4] = {0};
+  wmempcpy(a, a, 2); // expected-warning{{overlapping}}
+}
+
+void wmempcpy7(void) {
+  wchar_t a[4] = {0};
+  wmempcpy(a+2, a+1, 2); // expected-warning{{overlapping}}
+}
+
+void wmempcpy8(void) {
+  wchar_t a[4] = {0};
+  wmempcpy(a+1, a+2, 2); // expected-warning{{overlapping}}
+}
+
+void wmempcpy9(void) {
+  wchar_t a[4] = {0};
+  wmempcpy(a+2, a+1, 1); // no-warning
+  wmempcpy(a+1, a+2, 1); // no-warning
+}
+
+void wmempcpy10(void) {
+  wchar_t a[4] = {0};
+  wmempcpy(0, a, 1); // expected-warning{{Null pointer passed as 1st argument to memory copy function}}
+}
+
+void wmempcpy11(void) {
+  wchar_t a[4] = {0};
+  wmempcpy(a, 0, 1); // expected-warning{{Null pointer passed as 2nd argument to memory copy function}}
+}
+
+void wmempcpy12(void) {
+  wchar_t a[4] = {0};
+  wmempcpy(0, a, 0); // no-warning
+}
+
+void wmempcpy13(void) {
+  wchar_t a[4] = {0};
+  wmempcpy(a, 0, 0); // no-warning
+}
+
+void wmempcpy14(void) {
+  wchar_t src[] = {1, 2, 3, 4};
+  wchar_t dst[5] = {0};
+  wchar_t *p;
+
+  p = wmempcpy(dst, src, 4);
+
+  clang_analyzer_eval(p == &dst[4]); // expected-warning{{TRUE}}
+}
+
+struct st {
+  wchar_t i;
+  wchar_t j;
+};
+
+void wmempcpy15(void) {
+  struct st s1 = {0};
+  struct st s2;
+  struct st *p1;
+  struct st *p2;
+
+  p1 = (&s2) + 1;
+  p2 = (struct st *)wmempcpy((wchar_t *)&s2, (wchar_t *)&s1, 2);
+
+  clang_analyzer_eval(p1 == p2); // expected-warning{{TRUE}}
+}
+
+void wmempcpy16(void) {
+  struct st s1[10] = {{0}};
+  struct st s2[10];
+  struct st *p1;
+  struct st *p2;
+
+  p1 = (&s2[0]) + 5;
+  p2 = (struct st *)wmempcpy((wchar_t *)&s2[0], (wchar_t *)&s1[0], 5 * 2);
+
+  clang_analyzer_eval(p1 == p2); // expected-warning{{TRUE}}
+}
+
+void wmempcpy_unknown_size_warn (size_t n) {
+  wchar_t a[4];
+  void *result = wmempcpy(a, 0, n); // expected-warning{{Null pointer passed as 2nd argument to memory copy function}}
+  clang_analyzer_eval(result == a); // no-warning (above is fatal)
+}
+
+void wmempcpy_unknownable_size (wchar_t *src, float n) {
+  wchar_t a[4];
+  // This used to crash because we don't model floats.
+  wmempcpy(a, src, (size_t)n);
+}
+
+//===--===
+// wmemmove()
+//===--===
+
+#define wmemmove BUILTIN(wmemmove)
+wchar_t *wmemmove(wchar_t *s1, const wchar_t *s2, si

[PATCH] D130470: [clang][analyzer] Add more wide-character functions to CStringChecker

2022-07-29 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:136-137
   {{CDF_MaybeBuiltin, "memcpy", 3},
-   std::bind(&CStringChecker::evalMemcpy, _1, _2, _3, false)},
+   std::bind(&CStringChecker::evalMemcpy, _1, _2, _3,
+ CharacterKind::Regular)},
   {{CDF_MaybeBuiltin, "wmemcpy", 3},

steakhal wrote:
> If you were using a plain-old enum, it would feel less repetitive.
> You are already in the anonymous namespace, so it would not pollute anything 
> anyway.
> You could also `use std::bind`, to make it denser.
Every other enum in the file is `enum class`, I like more to use enum class. 
But the name can be shortened and constants added because it is used often.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130470

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


[PATCH] D129954: [CodeGen][inlineasm] assume the flag output of inline asm is boolean value

2022-07-29 Thread Nikita Popov via Phabricator via cfe-commits
nikic accepted this revision.
nikic added a comment.
This revision is now accepted and ready to land.

LGTM. After some further consideration, implementing this properly in LLVM 
would probably take more effort than is worthwhile (especially as this is 
target-specific functionality, so we'd actually have to expose TTI queries for 
this, etc.)




Comment at: clang/lib/CodeGen/CGStmt.cpp:2734
+  llvm::Value *IsBooleanValue =
+  Builder.CreateCmp(llvm::CmpInst::ICMP_ULE, Tmp, OneVal);
+  llvm::Function *FnAssume = CGM.getIntrinsic(llvm::Intrinsic::assume);

The canonical form of this is `< 2` rather than `<= 1`.



Comment at: clang/test/CodeGen/inline-asm-x86-flag-output.c:378
+
+int test_assume_boolean_flag(long nr, volatile long *addr) {
+  //CHECK-LABEL: @test_assume_boolean_flag

You might want to check that we're doing the right thing if there are multiple 
output constraints (via extractvalue).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129954

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


[PATCH] D130108: git-clang-format: format index not worktree when using --staged

2022-07-29 Thread Mészáros Gergely via Phabricator via cfe-commits
Maetveis added a comment.

In D130108#3685620 , @owenpan wrote:

> Can you open an issue at https://github.com/llvm/llvm-project/issues? See 
> https://github.com/llvm/llvm-project/issues/56736 for an example.

Of course, here it is: https://github.com/llvm/llvm-project/issues/56797


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130108

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


[PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread Mehdi AMINI via Phabricator via cfe-commits
mehdi_amini added a comment.

In D130689#3686760 , @h-vetinari 
wrote:

> My point boils down to: "written using standard C++17
> code" does not sound at all like "core language, no stdlib", but very much 
> like "core+stdlib".

We're allowing C++17 library feature, this isn't covered by the "vendor 
extensions" part but by the following paragraph:

> Nevertheless, we restrict ourselves to features which are available in the 
> major toolchains supported as host compilers

This includes not only missing features in libstdc++ but also gcc and clang 
bugs/limitations that we'll have to work around.

> This is also the first time this split becomes relevant AFAIK

I don't : the migration to C++11 was done the same way, piecewise by making 
sure that when we start using a new feature (core or stdlib) it actually works 
on the stated minimum version of the toolchains we support.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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


[PATCH] D130550: [pseudo] Start rules are `_ := start-symbol EOF`, improve recovery.

2022-07-29 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/GLR.h:74
 bool GCParity;
+// Have we already used this node for error recovery? (prevents loops)
+mutable bool Recovered = false;

hokein wrote:
> sammccall wrote:
> > hokein wrote:
> > > haven't look at it deeply -- is this bug related to this eof change? This 
> > > looks like a different bug in recovery.
> > They're "related" in that they both fix repeated-recovery scenarios.
> > This change fixes that we can hit an infinite loop when applying recovery 
> > repeatedly.
> > The eof change fixes that recovery is (erroneously) only applied once at 
> > eof.
> > 
> > I hoped to cover them with the same testcase, which tests repeated recovery 
> > at EOF. I can extract this change with a separate test if you like, though 
> > it will be very similar to the one I have here.
> > This change fixes that we can hit an infinite loop when applying recovery 
> > repeatedly.
> 
> I'm more worried about this bug, I think this is an important bug, worth a 
> separate patch to fix it, right now it looks like a join-effort in the eof 
> change. 
> 
> > The eof change fixes that recovery is (erroneously) only applied once at 
> > eof.
> 
> Not sure I follow this. I think the eof change is basically to remove a 
> technical debt (avoid the special case and repeated code after main parsing 
> loop).  Am I missing something?
> 
> Not sure I follow this. I think the eof change is basically to remove a 
> technical debt (avoid the special case and repeated code after main parsing 
> loop). Am I missing something?

There's a bug lurking in that tech debt: if recovery does not advance the 
cursor then we should go around the loop again, but if it happens at eof then 
(in the old code) there's no loop to go around at all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130550

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


[PATCH] D130268: [NFC] Add SmallVector constructor to allow creation of SmallVector from ArrayRef of items convertible to type T

2022-07-29 Thread Dawid Jurczak via Phabricator via cfe-commits
yurai007 added a comment.

In D130268#3684244 , @nikic wrote:

> I think my only concern with this change is that it will also allow some 
> implicit ArrayRef constructors. For example, this will permit creating a 
> SmallVector from `std::array`, `std::vector`, or just `T` -- but only if 
> `ArrayRef` is in scope. This seems somewhat dangerous.

Maybe I'm missing something, but is it right? It appears that only one implicit 
conversion in constructor is allowed: 
https://stackoverflow.com/questions/63320366/double-implicit-conversion-in-c
I think going from vector/array to SmallVector is ill-formed unless we 
explicitly create temporary ArrayRef in-between: https://godbolt.org/z/Geqbajf1x


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130268

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


[PATCH] D130268: [NFC] Add SmallVector constructor to allow creation of SmallVector from ArrayRef of items convertible to type T

2022-07-29 Thread Nikita Popov via Phabricator via cfe-commits
nikic accepted this revision.
nikic added a comment.
This revision is now accepted and ready to land.

LGTM

In D130268#3686811 , @yurai007 wrote:

> In D130268#3684244 , @nikic wrote:
>
>> I think my only concern with this change is that it will also allow some 
>> implicit ArrayRef constructors. For example, this will permit creating a 
>> SmallVector from `std::array`, `std::vector`, or just `T` -- but only if 
>> `ArrayRef` is in scope. This seems somewhat dangerous.
>
> Maybe I'm missing something, but is it right? It appears that only one 
> implicit conversion in constructor is allowed: 
> https://stackoverflow.com/questions/63320366/double-implicit-conversion-in-c
> I think going from vector/array to SmallVector is ill-formed unless we 
> explicitly create temporary ArrayRef in-between: 
> https://godbolt.org/z/Geqbajf1x

You're right... Everything's good then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130268

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


[PATCH] D130709: MSVC compatibility mode: fix error on unqualified templated base class initialization in case of partial specialization

2022-07-29 Thread Fred Tingaud via Phabricator via cfe-commits
frederic-tingaud-sonarsource updated this revision to Diff 448549.
frederic-tingaud-sonarsource added a comment.

Use getAs to see through ElaboratedType as recommended by 
https://reviews.llvm.org/D112374


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

https://reviews.llvm.org/D130709

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/SemaTemplate/ms-unqualified-base-class.cpp


Index: clang/test/SemaTemplate/ms-unqualified-base-class.cpp
===
--- clang/test/SemaTemplate/ms-unqualified-base-class.cpp
+++ clang/test/SemaTemplate/ms-unqualified-base-class.cpp
@@ -83,3 +83,37 @@
 
   return I;
 }
+
+template  class Vec {}; // expected-note {{template 
is declared here}}
+
+template  class Index : public Vec {
+  // after-error@+1 {{member initializer 'Vec' does not name a non-static data 
member or base class}}
+  Index() : Vec() {} // before-warning {{unqualified base initializer of class 
templates is a Microsoft extension}}
+};
+
+template class Index<0>;
+
+template  class Array : public Vec {
+  // after-error@+1 {{member initializer 'Vec' does not name a non-static data 
member or base class}}
+  Array() : Vec() {} // before-warning {{unqualified base initializer of class 
templates is a Microsoft extension}}
+};
+
+template class Array;
+
+template  class Wrong : public Vec {
+  Wrong() : NonExistent() {} // expected-error {{member initializer 
'NonExistent' does not name a non-static data member or base class}}
+};
+
+template class Wrong;
+
+template  class Wrong2 : public Vec {
+  Wrong2() : Vec() {} // expected-error {{too few template arguments for 
class template 'Vec'}}
+};
+
+template class Wrong2;
+
+template  class Wrong3 : public Vec {
+  Wrong3() : Base() {} // expected-error {{member initializer 'Base' does not 
name a non-static data member or base class}}
+};
+
+template class Wrong3;
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -4308,11 +4308,21 @@
   }
 
   if (getLangOpts().MSVCCompat && !getLangOpts().CPlusPlus20) {
-auto UnqualifiedBase = R.getAsSingle();
-if (UnqualifiedBase) {
-  Diag(IdLoc, diag::ext_unqualified_base_class)
-  << SourceRange(IdLoc, Init->getSourceRange().getEnd());
-  BaseType = UnqualifiedBase->getInjectedClassNameSpecialization();
+if (auto UnqualifiedBase = R.getAsSingle()) {
+  auto *TempSpec = cast(
+  UnqualifiedBase->getInjectedClassNameSpecialization());
+  TemplateName TN = TempSpec->getTemplateName();
+  for (auto const &Base : ClassDecl->bases()) {
+auto BaseTemplate =
+Base.getType()->getAs();
+if (BaseTemplate && Context.hasSameTemplateName(
+BaseTemplate->getTemplateName(), TN)) {
+  Diag(IdLoc, diag::ext_unqualified_base_class)
+  << SourceRange(IdLoc, Init->getSourceRange().getEnd());
+  BaseType = Base.getType();
+  break;
+}
+  }
 }
   }
 


Index: clang/test/SemaTemplate/ms-unqualified-base-class.cpp
===
--- clang/test/SemaTemplate/ms-unqualified-base-class.cpp
+++ clang/test/SemaTemplate/ms-unqualified-base-class.cpp
@@ -83,3 +83,37 @@
 
   return I;
 }
+
+template  class Vec {}; // expected-note {{template is declared here}}
+
+template  class Index : public Vec {
+  // after-error@+1 {{member initializer 'Vec' does not name a non-static data member or base class}}
+  Index() : Vec() {} // before-warning {{unqualified base initializer of class templates is a Microsoft extension}}
+};
+
+template class Index<0>;
+
+template  class Array : public Vec {
+  // after-error@+1 {{member initializer 'Vec' does not name a non-static data member or base class}}
+  Array() : Vec() {} // before-warning {{unqualified base initializer of class templates is a Microsoft extension}}
+};
+
+template class Array;
+
+template  class Wrong : public Vec {
+  Wrong() : NonExistent() {} // expected-error {{member initializer 'NonExistent' does not name a non-static data member or base class}}
+};
+
+template class Wrong;
+
+template  class Wrong2 : public Vec {
+  Wrong2() : Vec() {} // expected-error {{too few template arguments for class template 'Vec'}}
+};
+
+template class Wrong2;
+
+template  class Wrong3 : public Vec {
+  Wrong3() : Base() {} // expected-error {{member initializer 'Base' does not name a non-static data member or base class}}
+};
+
+template class Wrong3;
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -4308,11 +4308,21 @@
   }
 
   if (getLangOpts().MSVCCompat && !getLangOpt

[PATCH] D130750: [Clang] Do not check for underscores in isAllowedInitiallyIDChar

2022-07-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin created this revision.
Herald added a project: All.
cor3ntin requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

isAllowedInitiallyIDChar is only used with non-ASCII codepoints,
which are handled by isAsciiIdentifierStart.
To make that clearer, remove the check for _ from
isAllowedInitiallyIDChar, and assert on ASCII - to ensure neither
_ or $ are passed to this function.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130750

Files:
  clang/lib/Lex/Lexer.cpp


Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -1483,13 +1483,13 @@
 }
 
 static bool isAllowedInitiallyIDChar(uint32_t C, const LangOptions &LangOpts) {
+  assert(C > 0x7F && "isAllowedInitiallyIDChar called with a non-ASCII 
codepoint");
   if (LangOpts.AsmPreprocessor) {
 return false;
   }
   if (LangOpts.CPlusPlus || LangOpts.C2x) {
 static const llvm::sys::UnicodeCharSet XIDStartChars(XIDStartRanges);
-// '_' doesn't have the XID_Start property but is allowed in C++.
-return C == '_' || XIDStartChars.contains(C);
+return XIDStartChars.contains(C);
   }
   if (!isAllowedIDChar(C, LangOpts))
 return false;


Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -1483,13 +1483,13 @@
 }
 
 static bool isAllowedInitiallyIDChar(uint32_t C, const LangOptions &LangOpts) {
+  assert(C > 0x7F && "isAllowedInitiallyIDChar called with a non-ASCII codepoint");
   if (LangOpts.AsmPreprocessor) {
 return false;
   }
   if (LangOpts.CPlusPlus || LangOpts.C2x) {
 static const llvm::sys::UnicodeCharSet XIDStartChars(XIDStartRanges);
-// '_' doesn't have the XID_Start property but is allowed in C++.
-return C == '_' || XIDStartChars.contains(C);
+return XIDStartChars.contains(C);
   }
   if (!isAllowedIDChar(C, LangOpts))
 return false;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130754: [X86] Support ``-mindirect-branch-cs-prefix`` for call and jmp to indirect thunk

2022-07-29 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei created this revision.
pengfei added a reviewer: nickdesaulniers.
Herald added a subscriber: hiraditya.
Herald added a project: All.
pengfei requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, MaskRay.
Herald added projects: clang, LLVM.

This is to address feature request from 
https://github.com/ClangBuiltLinux/linux/issues/1665


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130754

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/X86/indirect-branch-cs-prefix.c
  llvm/lib/Target/X86/X86MCInstLower.cpp
  llvm/lib/Target/X86/X86ReturnThunks.cpp
  llvm/test/CodeGen/X86/attr-function-return.ll
  llvm/test/CodeGen/X86/lvi-hardening-indirectbr.ll

Index: llvm/test/CodeGen/X86/lvi-hardening-indirectbr.ll
===
--- llvm/test/CodeGen/X86/lvi-hardening-indirectbr.ll
+++ llvm/test/CodeGen/X86/lvi-hardening-indirectbr.ll
@@ -22,18 +22,22 @@
 ; X64:   callq bar
 ; X64-DAG:   movl %[[x]], %edi
 ; X64-DAG:   movq %[[fp]], %r11
-; X64:   callq __llvm_lvi_thunk_r11
+; X64:   cs
+; X64-NEXT:  callq __llvm_lvi_thunk_r11
 ; X64:   movl %[[x]], %edi
 ; X64:   callq bar
 ; X64-DAG:   movl %[[x]], %edi
 ; X64-DAG:   movq %[[fp]], %r11
-; X64:   jmp __llvm_lvi_thunk_r11 # TAILCALL
+; X64:   cs
+; X64-NEXT:  jmp __llvm_lvi_thunk_r11 # TAILCALL
 
 ; X64FAST-LABEL: icall_reg:
 ; X64FAST:   callq bar
-; X64FAST:   callq __llvm_lvi_thunk_r11
+; X64FAST:   cs
+; X64FAST-NEXT:  callq __llvm_lvi_thunk_r11
 ; X64FAST:   callq bar
-; X64FAST:   jmp __llvm_lvi_thunk_r11 # TAILCALL
+; X64FAST:   cs
+; X64FAST-NEXT:  jmp __llvm_lvi_thunk_r11 # TAILCALL
 
 
 @global_fp = external dso_local global ptr
@@ -50,16 +54,20 @@
 ; X64-LABEL: icall_global_fp:
 ; X64-DAG:   movl %edi, %[[x:[^ ]*]]
 ; X64-DAG:   movq global_fp(%rip), %r11
-; X64:   callq __llvm_lvi_thunk_r11
+; X64:   cs
+; X64-NEXT:  callq __llvm_lvi_thunk_r11
 ; X64-DAG:   movl %[[x]], %edi
 ; X64-DAG:   movq global_fp(%rip), %r11
-; X64:   jmp __llvm_lvi_thunk_r11 # TAILCALL
+; X64:   cs
+; X64-NEXT:  jmp __llvm_lvi_thunk_r11 # TAILCALL
 
 ; X64FAST-LABEL: icall_global_fp:
 ; X64FAST:   movq global_fp(%rip), %r11
-; X64FAST:   callq __llvm_lvi_thunk_r11
+; X64FAST:   cs
+; X64FAST-NEXT:  callq __llvm_lvi_thunk_r11
 ; X64FAST:   movq global_fp(%rip), %r11
-; X64FAST:   jmp __llvm_lvi_thunk_r11 # TAILCALL
+; X64FAST:   cs
+; X64FAST-NEXT:  jmp __llvm_lvi_thunk_r11 # TAILCALL
 
 
 %struct.Foo = type { ptr }
@@ -79,14 +87,18 @@
 ; X64:   movq (%rdi), %[[vptr:[^ ]*]]
 ; X64:   movq 8(%[[vptr]]), %[[fp:[^ ]*]]
 ; X64:   movq %[[fp]], %r11
-; X64:   callq __llvm_lvi_thunk_r11
+; X64:   cs
+; X64-NEXT:  callq __llvm_lvi_thunk_r11
 ; X64-DAG:   movq %[[obj]], %rdi
 ; X64-DAG:   movq %[[fp]], %r11
-; X64:   jmp __llvm_lvi_thunk_r11 # TAILCALL
+; X64:   cs
+; X64-NEXT:  jmp __llvm_lvi_thunk_r11 # TAILCALL
 
 ; X64FAST-LABEL: vcall:
-; X64FAST:   callq __llvm_lvi_thunk_r11
-; X64FAST:   jmp __llvm_lvi_thunk_r11 # TAILCALL
+; X64FAST:   cs
+; X64FAST-NEXT:  callq __llvm_lvi_thunk_r11
+; X64FAST:   cs
+; X64FAST-NEXT:  jmp __llvm_lvi_thunk_r11 # TAILCALL
 
 
 declare dso_local void @direct_callee()
@@ -113,14 +125,18 @@
 ; X64-LABEL: nonlazybind_caller:
 ; X64:   movq nonlazybind_callee@GOTPCREL(%rip), %[[REG:.*]]
 ; X64:   movq %[[REG]], %r11
-; X64:   callq __llvm_lvi_thunk_r11
+; X64:   cs
+; X64-NEXT:  callq __llvm_lvi_thunk_r11
 ; X64:   movq %[[REG]], %r11
-; X64:   jmp __llvm_lvi_thunk_r11 # TAILCALL
+; X64:   cs
+; X64-NEXT:  jmp __llvm_lvi_thunk_r11 # TAILCALL
 ; X64FAST-LABEL: nonlazybind_caller:
 ; X64FAST:   movq nonlazybind_callee@GOTPCREL(%rip), %r11
-; X64FAST:   callq __llvm_lvi_thunk_r11
+; X64FAST:   cs
+; X64FAST-NEXT:  callq __llvm_lvi_thunk_r11
 ; X64FAST:   movq nonlazybind_callee@GOTPCREL(%rip), %r11
-; X64FAST:   jmp __llvm_lvi_thunk_r11 # TAILCALL
+; X64FAST:   cs
+; X64FAST-NEXT:  jmp __llvm_lvi_thunk_r11 # TAILCALL
 
 
 ; Check that a switch gets lowered using a jump table
@@ -278,3 +294,7 @@
 ; X64-NEXT:  jmpq *%r11
 
 attributes #1 = { nonlazybind }
+
+!llvm.module.flags = !{!0}
+
+!0 = !{i32 4, !"indirect_branch_cs_prefix", i32 1}
Index: llvm/test/CodeGen/X86/attr-function-return.ll
===
--- llvm/test/CodeGen/X86/attr-function-return.ll
+++ llvm/test/CodeGen/X86/attr-function-return.ll
@@ -6,6 +6,11 @@
 define void @x() fn_ret_thunk_extern {
 ; CHECK-LABEL: x:
 ; CHECK:   # %bb.0:
+; CHECK-NEXT:cs
 ; CHECK-NEXT:jmp __x86_return_thunk
   ret void
 }
+
+!llvm.module.flags = !{!0}
+
+!0 = !{i32 4, !"indirect_branch_cs_prefix", i

[PATCH] D130108: git-clang-format: format index not worktree when using --staged

2022-07-29 Thread Mészáros Gergely via Phabricator via cfe-commits
Maetveis updated this revision to Diff 448563.
Maetveis added a comment.

Updated to add missing comma after 'git ls-tree'. It broke normal (non staged) 
operation.


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

https://reviews.llvm.org/D130108

Files:
  clang/tools/clang-format/git-clang-format

Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -184,8 +184,12 @@
  binary=opts.binary,
  style=opts.style)
   else:
-old_tree = create_tree_from_workdir(changed_lines)
+if opts.staged:
+  old_tree = create_tree_from_index(changed_lines)
+else:
+  old_tree = create_tree_from_workdir(changed_lines)
 new_tree = run_clang_format_and_save_to_tree(changed_lines,
+ revision="" if opts.staged else None,
  binary=opts.binary,
  style=opts.style)
   if opts.verbose >= 1:
@@ -393,12 +397,27 @@
   Returns the object ID (SHA-1) of the created tree."""
   return create_tree(filenames, '--stdin')
 
+def create_tree_from_index(filenames):
+  # Copy the environment, because the files have to be read from the original index
+  env = os.environ.copy()
+  def index_contents_generator():
+for filename in filenames:
+  git_ls_files_cmd = ['git', 'ls-files', '--stage', '-z', '--', filename]
+  git_ls_files = subprocess.Popen(git_ls_files_cmd, env=env, stdin=subprocess.PIPE,
+  stdout=subprocess.PIPE)
+  stdout = git_ls_files.communicate()[0]
+  yield convert_string(stdout.split(b'\0')[0])
+  return create_tree(index_contents_generator(), '--index-info')
+
 
 def run_clang_format_and_save_to_tree(changed_lines, revision=None,
   binary='clang-format', style=None):
   """Run clang-format on each file and save the result to a git tree.
 
   Returns the object ID (SHA-1) of the created tree."""
+  # Copy the environment when formatting the files in the index, because the files
+  # have to be read from the original index
+  env = os.environ.copy() if revision == '' else None
   def iteritems(container):
   try:
   return container.iteritems() # Python 2
@@ -406,11 +425,14 @@
   return container.items() # Python 3
   def index_info_generator():
 for filename, line_ranges in iteritems(changed_lines):
-  if revision:
-git_metadata_cmd = ['git', 'ls-tree',
-'%s:%s' % (revision, os.path.dirname(filename)),
-os.path.basename(filename)]
-git_metadata = subprocess.Popen(git_metadata_cmd, stdin=subprocess.PIPE,
+  if revision is not None:
+if len(revision) > 0:
+  git_metadata_cmd = ['git', 'ls-tree',
+  '%s:%s' % (revision, os.path.dirname(filename)),
+  os.path.basename(filename)]
+else:
+  git_metadata_cmd = ['git', 'ls-files', '--stage', '--', filename]
+git_metadata = subprocess.Popen(git_metadata_cmd, env=env, stdin=subprocess.PIPE,
 stdout=subprocess.PIPE)
 stdout = git_metadata.communicate()[0]
 mode = oct(int(stdout.split()[0], 8))
@@ -422,7 +444,8 @@
   blob_id = clang_format_to_blob(filename, line_ranges,
  revision=revision,
  binary=binary,
- style=style)
+ style=style,
+ env=env)
   yield '%s %s\t%s' % (mode, blob_id, filename)
   return create_tree(index_info_generator(), '--index-info')
 
@@ -448,11 +471,12 @@
 
 
 def clang_format_to_blob(filename, line_ranges, revision=None,
- binary='clang-format', style=None):
+ binary='clang-format', style=None, env=None):
   """Run clang-format on the given file and save the result to a git blob.
 
   Runs on the file in `revision` if not None, or on the file in the working
-  directory if `revision` is None.
+  directory if `revision` is None. Revision can be set to an empty string to run
+  clang-format on the file in the index.
 
   Returns the object ID (SHA-1) of the created blob."""
   clang_format_cmd = [binary]
@@ -461,10 +485,10 @@
   clang_format_cmd.extend([
   '-lines=%s:%s' % (start_line, start_line+line_count-1)
   for start_line, line_count in line_ranges])
-  if revision:
+  if revision is not None:
 clang_format_cmd.extend(['-assume-filename='+filename])
 git_show_cmd = ['git', 'cat-file', 'blob', '%s:%s' % (revision, filename)]
-git_show = su

[PATCH] D128861: [clang-tidy] add cppcoreguidelines-symmetric-binary-operator

2022-07-29 Thread Julian Schmidt via Phabricator via cfe-commits
5chmidti added a comment.

Gentle Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128861

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


[PATCH] D126676: [clang] Disallow differences in defines used for creating and using PCH

2022-07-29 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

Ping @vsapsai @Bigcheese @akyrtzi @benlangmuir @arphaman


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126676

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


[PATCH] D130690: [clangd][NFCI] Store TUPath inside ParsedAST

2022-07-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet marked 2 inline comments as done.
kadircet added a comment.

as discussed offline, this patch stores the filepath provided by the client 
(e.g. vscode) which is usually the filepath seen by the user, inside the 
ParsedAST and later on uses that when a hint is needed for translating 
filepaths coming from sourcemanager into uris.
this gets rid of the extra canonicalization needed for the main file path 
(which could fail when we don't have a current working directory set, i.e. in 
tests) and also does always the "right" thing as all the files should be 
relative to the workspace of the main file path seen by the user, not the 
version clangd derives somehow.




Comment at: clang-tools-extra/clangd/ParsedAST.cpp:763
 
-ParsedAST::ParsedAST(llvm::StringRef Version,
+ParsedAST::ParsedAST(PathRef TUPath, llvm::StringRef Version,
  std::shared_ptr Preamble,

ilya-biryukov wrote:
> NIT: use `Path`.
>  this allows the callers to avoid an extra allocation, e.g. if they already 
> allocated a `std::string` and they can `std::move` into the constructor.
this is a private constructor and public interface also receives a stringref 
and none of the production callers actually have an extra copy of the filename 
lying around. so i'd rather keep it as is.



Comment at: clang-tools-extra/clangd/ParsedAST.h:112
 
+  /// Returns the path passed by the caller when building this AST.
+  PathRef tuPath() const { return TUPath; }

ilya-biryukov wrote:
> NIT: could you add a comment how this is used, e.g. `this path is used as a 
> hint when canonicalize the path`.
> Also useful to document that we expect this to be absolute/"canonical".
i'd rather not complicate the wording here.  i think mentioning the fact that 
this is the filepath as provided by the caller is enough. being used as a hint 
for canonicalization of other paths is something specific to the application 
(and is a result of being the path provided by caller anyway.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130690

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


[PATCH] D130131: [HLSL] CodeGen hlsl cbuffer/tbuffer.

2022-07-29 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/lib/CodeGen/CGHLSLRuntime.cpp:61
+
+GlobalVariable *replaceCBuffer(CGHLSLRuntime::CBuffer &CB) {
+  const unsigned CBufferAddressSpace = 4;

python3kgae wrote:
> Anastasia wrote:
> > I don't think I understand the intent of this function along with 
> > `CGHLSLRuntime::addConstant` that populates this collection.
> It is translating
> 
> ```
>  cbuffer A {
>float a;
>float b;
> }
> float foo() {
>   return a + b;
> }
> ```
> into
> 
> ```
> struct cb.A.Ty {
>   float a;
>   float b;
> };
> 
> cbuffer A {
>   cb.A.Ty CBA;
> }
> float foo() {
>   return CBA.a + CBA.b;
> }
> ```
> 
> Both a and b are in the global scope and will get a GlobalVariable in clang 
> codeGen.
> By doing the translation, we can ensure each buffer map to one GlobalVariable 
> and save cbuffer layout in the value type of that GlobalVariable.
Ok, I see, so if we are to translate it to C it would be something similar to:


```
struct A {
   float a;
   float b;
} cbuffer_A __attribute__((address_space(256)));

float foo() {
  return cbuffer_A.a + cbuffer_A.b;
}
```
Maybe you can add some comments to explain the intent of this code at a higher 
level... not sure if the generation can reuse or be made a bit close to the 
regular C structs + address spaces...




Comment at: clang/lib/CodeGen/CGHLSLRuntime.cpp:119
+void CGHLSLRuntime::addConstant(VarDecl *D, Buffer &CB) {
+  if (D->getStorageClass() == SC_Static) {
+// For static inside cbuffer, take as global static.

btw is this covered in the test?



Comment at: clang/lib/CodeGen/CGHLSLRuntime.cpp:152
+  // as it only refers to globally scoped declarations.
+  CGM.EmitTopLevelDecl(it);
+} else if (NamespaceDecl *ND = dyn_cast(it)) {

Ok I think you don't have this in the tests too and the one below?




Comment at: clang/lib/CodeGen/CGHLSLRuntime.cpp:183
+  const unsigned CBufferAddressSpace =
+  ASMap[(unsigned)clang::LangAS::hlsl_cbuffer];
+  const unsigned TBufferAddressSpace =

I think it's better to use `getTargetAddressSpace` from `ASTContext`.



Comment at: clang/test/CodeGenHLSL/nest_cbuf.hlsl:8
+  // CHECK: @[[TB:.+]] = external addrspace(5) constant { float, i32, double }
+  tbuffer A : register(t2, space1) {
+float c;

is this generated as nested structs?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130131

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


[clang-tools-extra] 3b8fb47 - [clangd][NFCI] Store TUPath inside ParsedAST

2022-07-29 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2022-07-29T13:23:42+02:00
New Revision: 3b8fb471cbbd704e3066b3cb7dddb755cad11b8b

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

LOG: [clangd][NFCI] Store TUPath inside ParsedAST

Lots of features built on top of ASTs require getting back to the path
of the TU and they used lossy conversion from file ids using sourcemanager.
This patch preserves the file path passed by the caller inside ParsedAST for
later use.

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

Added: 


Modified: 
clang-tools-extra/clangd/Hover.cpp
clang-tools-extra/clangd/ParsedAST.cpp
clang-tools-extra/clangd/ParsedAST.h
clang-tools-extra/clangd/XRefs.cpp
clang-tools-extra/clangd/XRefs.h
clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Hover.cpp 
b/clang-tools-extra/clangd/Hover.cpp
index 26eb2574195d3..f599f067d6ee3 100644
--- a/clang-tools-extra/clangd/Hover.cpp
+++ b/clang-tools-extra/clangd/Hover.cpp
@@ -975,19 +975,16 @@ llvm::Optional getHover(ParsedAST &AST, 
Position Pos,
 return llvm::None;
 
   // Show full header file path if cursor is on include directive.
-  if (const auto MainFilePath =
-  getCanonicalPath(SM.getFileEntryForID(SM.getMainFileID()), SM)) {
-for (const auto &Inc : AST.getIncludeStructure().MainFileIncludes) {
-  if (Inc.Resolved.empty() || Inc.HashLine != Pos.line)
-continue;
-  HoverInfo HI;
-  HI.Name = std::string(llvm::sys::path::filename(Inc.Resolved));
-  // FIXME: We don't have a fitting value for Kind.
-  HI.Definition =
-  URIForFile::canonicalize(Inc.Resolved, *MainFilePath).file().str();
-  HI.DefinitionLanguage = "";
-  return HI;
-}
+  for (const auto &Inc : AST.getIncludeStructure().MainFileIncludes) {
+if (Inc.Resolved.empty() || Inc.HashLine != Pos.line)
+  continue;
+HoverInfo HI;
+HI.Name = std::string(llvm::sys::path::filename(Inc.Resolved));
+// FIXME: We don't have a fitting value for Kind.
+HI.Definition =
+URIForFile::canonicalize(Inc.Resolved, AST.tuPath()).file().str();
+HI.DefinitionLanguage = "";
+return HI;
   }
 
   // To be used as a backup for highlighting the selected token, we use back as

diff  --git a/clang-tools-extra/clangd/ParsedAST.cpp 
b/clang-tools-extra/clangd/ParsedAST.cpp
index 8bb426d78f367..cf4c57e6e871b 100644
--- a/clang-tools-extra/clangd/ParsedAST.cpp
+++ b/clang-tools-extra/clangd/ParsedAST.cpp
@@ -665,10 +665,11 @@ ParsedAST::build(llvm::StringRef Filename, const 
ParseInputs &Inputs,
   Diags->insert(Diags->end(), D.begin(), D.end());
 }
   }
-  ParsedAST Result(Inputs.Version, std::move(Preamble), std::move(Clang),
-   std::move(Action), std::move(Tokens), std::move(Macros),
-   std::move(Marks), std::move(ParsedDecls), std::move(Diags),
-   std::move(Includes), std::move(CanonIncludes));
+  ParsedAST Result(Filename, Inputs.Version, std::move(Preamble),
+   std::move(Clang), std::move(Action), std::move(Tokens),
+   std::move(Macros), std::move(Marks), std::move(ParsedDecls),
+   std::move(Diags), std::move(Includes),
+   std::move(CanonIncludes));
   if (Result.Diags) {
 auto UnusedHeadersDiags =
 issueUnusedIncludesDiagnostics(Result, Inputs.Contents);
@@ -759,7 +760,7 @@ const CanonicalIncludes &ParsedAST::getCanonicalIncludes() 
const {
   return CanonIncludes;
 }
 
-ParsedAST::ParsedAST(llvm::StringRef Version,
+ParsedAST::ParsedAST(PathRef TUPath, llvm::StringRef Version,
  std::shared_ptr Preamble,
  std::unique_ptr Clang,
  std::unique_ptr Action,
@@ -768,10 +769,10 @@ ParsedAST::ParsedAST(llvm::StringRef Version,
  std::vector LocalTopLevelDecls,
  llvm::Optional> Diags,
  IncludeStructure Includes, CanonicalIncludes 
CanonIncludes)
-: Version(Version), Preamble(std::move(Preamble)), Clang(std::move(Clang)),
-  Action(std::move(Action)), Tokens(std::move(Tokens)),
-  Macros(std::move(Macros)), Marks(std::move(Marks)),
-  Diags(std::move(Diags)),
+: TUPath(TUPath), Version(Version), Preamble(std::move(Preamble)),
+  Clang(std::move(Clang)), Action(std::move(Action)),
+  Tokens(std::move(Tokens)), Macros(std::move(Macros)),
+  Marks(std::move(Marks)), Diags(std::move(Diags)),
   LocalTopLevelDecls(std::move(LocalTopLevelDecls)),
   Includes(std::move(Includes)), CanonIncludes(std::move(CanonIncludes)) {
   Resolver = std::make_unique(getASTContext());

diff  --git a/clang-tools-extra/clangd/ParsedAST.h 
b/clang

[PATCH] D130690: [clangd][NFCI] Store TUPath inside ParsedAST

2022-07-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
kadircet marked 2 inline comments as done.
Closed by commit rG3b8fb471cbbd: [clangd][NFCI] Store TUPath inside ParsedAST 
(authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130690

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/ParsedAST.h
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/XRefs.h
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp

Index: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
@@ -408,12 +408,7 @@
 
   Expected apply(const Selection &Sel) override {
 const SourceManager &SM = Sel.AST->getSourceManager();
-auto MainFileName =
-getCanonicalPath(SM.getFileEntryForID(SM.getMainFileID()), SM);
-if (!MainFileName)
-  return error("Couldn't get absolute path for main file.");
-
-auto CCFile = getSourceFile(*MainFileName, Sel);
+auto CCFile = getSourceFile(Sel.AST->tuPath(), Sel);
 
 if (!CCFile)
   return error("Couldn't find a suitable implementation file.");
Index: clang-tools-extra/clangd/XRefs.h
===
--- clang-tools-extra/clangd/XRefs.h
+++ clang-tools-extra/clangd/XRefs.h
@@ -20,6 +20,7 @@
 #include "support/Path.h"
 #include "clang/AST/ASTTypeTraits.h"
 #include "llvm/ADT/Optional.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
 
@@ -59,10 +60,11 @@
 // AST-based resolution does not work, such as comments, strings, and PP
 // disabled regions.
 // (This is for internal use by locateSymbolAt, and is exposed for testing).
-std::vector
-locateSymbolTextually(const SpelledWord &Word, ParsedAST &AST,
-  const SymbolIndex *Index, const std::string &MainFilePath,
-  ASTNodeKind NodeKind);
+std::vector locateSymbolTextually(const SpelledWord &Word,
+ ParsedAST &AST,
+ const SymbolIndex *Index,
+ llvm::StringRef MainFilePath,
+ ASTNodeKind NodeKind);
 
 // Try to find a proximate occurrence of `Word` as an identifier, which can be
 // used to resolve it.
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -484,12 +484,7 @@
 std::vector locateSymbolForType(const ParsedAST &AST,
const QualType &Type) {
   const auto &SM = AST.getSourceManager();
-  auto MainFilePath =
-  getCanonicalPath(SM.getFileEntryForID(SM.getMainFileID()), SM);
-  if (!MainFilePath) {
-elog("Failed to get a path for the main file, so no symbol.");
-return {};
-  }
+  auto MainFilePath = AST.tuPath();
 
   // FIXME: this sends unique_ptr to unique_ptr.
   // Likely it would be better to send it to Foo (heuristically) or to both.
@@ -505,7 +500,7 @@
   for (const NamedDecl *D : Decls) {
 D = getPreferredDecl(D);
 
-auto Loc = makeLocation(ASTContext, nameLocation(*D, SM), *MainFilePath);
+auto Loc = makeLocation(ASTContext, nameLocation(*D, SM), MainFilePath);
 if (!Loc)
   continue;
 
@@ -515,7 +510,7 @@
 Results.back().ID = getSymbolID(D);
 if (const NamedDecl *Def = getDefinition(D))
   Results.back().Definition =
-  makeLocation(ASTContext, nameLocation(*Def, SM), *MainFilePath);
+  makeLocation(ASTContext, nameLocation(*Def, SM), MainFilePath);
   }
 
   return Results;
@@ -546,10 +541,11 @@
 
 } // namespace
 
-std::vector
-locateSymbolTextually(const SpelledWord &Word, ParsedAST &AST,
-  const SymbolIndex *Index, const std::string &MainFilePath,
-  ASTNodeKind NodeKind) {
+std::vector locateSymbolTextually(const SpelledWord &Word,
+ ParsedAST &AST,
+ const SymbolIndex *Index,
+ llvm::StringRef MainFilePath,
+ ASTNodeKind NodeKind) {
   // Don't use heuristics if this is a real identifier, or not an
   // identifier.
   // Exception: dependent names, because those may have useful textual
@@ -567,7 +563,7 @@
   // Look up the selected word in the index.
   FuzzyFindRequest Req;
   Req.Query = Word.Text.str();
-  Req.ProximityPaths = {MainFilePath};
+  Req.ProximityPaths = {MainFilePath.str()};
   // Find the namespace

[PATCH] D122768: [Clang][C++20] Support capturing structured bindings in lambdas

2022-07-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/lib/Analysis/AnalysisDeclContext.cpp:173
+ValueDecl *VD = LC.getCapturedVar();
+if (isSelfDecl(dyn_cast(VD)))
   return dyn_cast(VD);

erichkeane wrote:
> aaron.ballman wrote:
> > This looks dangerous -- `isSelfDecl()` uses the pointer variable in ways 
> > that would be Bad News for null pointers.
> Yep, `isSelfDecl` seems to do:
> 
> `return isa(VD) && VD->getName() == "self";`
> 
> `isa` isn't nullptr safe, we have `isa_and_nonnull` for that (if we want to 
> update `isSelfDecl`).
Using `isa_and_nonnull` looks like the best solution here



Comment at: clang/lib/Sema/SemaDecl.cpp:14594-14596
+  ValueDecl *VD = C.getCapturedVar();
+  if (VarDecl *Var = dyn_cast(VD)) {
+if (Var->isInitCapture())

erichkeane wrote:
> 
I'm not sure I understood your suggestion.
The reason there is a local `ValueDecl` in addition of the `VarDecl` is because 
we use it Line 14660 just below.
But that was reworked when lifting isInitCapture in ValueDecl anyway.



Comment at: clang/lib/Sema/SemaExpr.cpp:16393
 
-VarDecl *Var = Cap.getVariable();
+VarDecl *Var = cast(Cap.getVariable());
 Expr *CopyExpr = nullptr;

aaron.ballman wrote:
> Is `cast<>` safe here?
Yes, I added a comment to make that clear



Comment at: clang/lib/Sema/SemaExpr.cpp:18324
+
+  assert((isa(Var) || isa(Var)) &&
+ "Only variables and structured bindings can be captured");

aaron.ballman wrote:
> 
Fancy. The parentheses are still needed though, because C macros are amazing 
like that :)



Comment at: clang/lib/Sema/SemaExpr.cpp:18531
+  } else if ((BD = dyn_cast(Var))) {
+ME = dyn_cast_or_null(BD->getBinding());
+  }

aaron.ballman wrote:
> Can this return nullptr?
I think so 
```
/// Get the expression to which this declaration is bound. This may be null
/// in two different cases: while parsing the initializer for the
/// decomposition declaration, and when the initializer is type-dependent.
Expr *getBinding() const { return Binding; }
```

The initializer could be type dependant here, and so it could be null



Comment at: clang/lib/Sema/SemaExpr.cpp:18539
+   !S.isOpenMPCapturedDecl(Var))) {
+FieldDecl *FD = dyn_cast_or_null(ME->getMemberDecl());
+if (FD &&

aaron.ballman wrote:
> Can this return nullptr?
Yes, same thing as above



Comment at: clang/lib/Sema/SemaLambda.cpp:1208-1209
+if (isa(Var)) {
+  Underlying = dyn_cast_or_null(
+  cast(Var)->getDecomposedDecl());
+} else

aaron.ballman wrote:
> Does `getDecomposedDecl()` ever actually return nullptr?
I don't think that's necessary indeed, nice catch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122768

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


[PATCH] D130750: [Clang] Do not check for underscores in isAllowedInitiallyIDChar

2022-07-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

The change is fine by me, but you should put NFC in the patch title so it's 
more clear that this is simplifying code in a way that won't change behavior 
(and doesn't need tests).




Comment at: clang/lib/Lex/Lexer.cpp:1486
 static bool isAllowedInitiallyIDChar(uint32_t C, const LangOptions &LangOpts) {
+  assert(C > 0x7F && "isAllowedInitiallyIDChar called with a non-ASCII 
codepoint");
   if (LangOpts.AsmPreprocessor) {

nit: 80-col limit

Also, shouldn't this say it was called with an ASCII codepoint?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130750

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


[PATCH] D130750: [Clang] Do not check for underscores in isAllowedInitiallyIDChar

2022-07-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 448581.
cor3ntin added a comment.

Fix asser message


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130750

Files:
  clang/lib/Lex/Lexer.cpp


Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -1483,13 +1483,13 @@
 }
 
 static bool isAllowedInitiallyIDChar(uint32_t C, const LangOptions &LangOpts) {
+  assert(C > 0x7F && "isAllowedInitiallyIDChar called with an ASCII 
codepoint");
   if (LangOpts.AsmPreprocessor) {
 return false;
   }
   if (LangOpts.CPlusPlus || LangOpts.C2x) {
 static const llvm::sys::UnicodeCharSet XIDStartChars(XIDStartRanges);
-// '_' doesn't have the XID_Start property but is allowed in C++.
-return C == '_' || XIDStartChars.contains(C);
+return XIDStartChars.contains(C);
   }
   if (!isAllowedIDChar(C, LangOpts))
 return false;


Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -1483,13 +1483,13 @@
 }
 
 static bool isAllowedInitiallyIDChar(uint32_t C, const LangOptions &LangOpts) {
+  assert(C > 0x7F && "isAllowedInitiallyIDChar called with an ASCII codepoint");
   if (LangOpts.AsmPreprocessor) {
 return false;
   }
   if (LangOpts.CPlusPlus || LangOpts.C2x) {
 static const llvm::sys::UnicodeCharSet XIDStartChars(XIDStartRanges);
-// '_' doesn't have the XID_Start property but is allowed in C++.
-return C == '_' || XIDStartChars.contains(C);
+return XIDStartChars.contains(C);
   }
   if (!isAllowedIDChar(C, LangOpts))
 return false;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130750: [Clang] Do not check for underscores in isAllowedInitiallyIDChar

2022-07-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/lib/Lex/Lexer.cpp:1486
 static bool isAllowedInitiallyIDChar(uint32_t C, const LangOptions &LangOpts) {
+  assert(C > 0x7F && "isAllowedInitiallyIDChar called with a non-ASCII 
codepoint");
   if (LangOpts.AsmPreprocessor) {

aaron.ballman wrote:
> nit: 80-col limit
> 
> Also, shouldn't this say it was called with an ASCII codepoint?
It should. I started with `"isAllowedInitiallyIDChar should not be called with 
a non-ASCII codepoint")` and... yeah, thanks for catching that!
It fits nicely in 80 cols too now :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130750

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


[PATCH] D130750: [Clang] Do not check for underscores in isAllowedInitiallyIDChar

2022-07-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM assuming @tahonermann doesn't spot concerns.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130750

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


[PATCH] D129242: [clang-repl] Add host exception support check utility flag.

2022-07-29 Thread Sunho Kim via Phabricator via cfe-commits
sunho added a comment.

In D129242#3686713 , @uabelho wrote:

> In D129242#3686610 , @sunho wrote:
>
>> @uabelho Hi, that's a typeinfo symbol of libc++ abi. It's quite weird that 
>> __cxa_throw is availble while _ZTIPKc is not. Do you have some special 
>> setting regarding libc++ in your environment?
>
> We compile with clang 8 on a RHEL7 machine, but since we then got too old 
> libs we do
>
>   
> --gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler
>
> since we have newer libs there. This is seen in the cmake command:
>
>   cmake command: CC='/proj/flexasic/app/llvm/8.0/bin/clang -march=corei7 
> --gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler'
>  CXX='/proj/flexasic/app/llvm/8.0/bin/clang++ -march=corei7 
> --gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler'
>  LDFLAGS='-Wl,-R/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1/lib64' 
> PATH=/proj/flexasic/app/ninja/1.8.2/SLED11-64/bin:$PATH  
> /app/vbuild/RHEL7-x86_64/cmake/3.16.4/bin/cmake 
> /repo/uabelho/main-github/llvm --debug-trycompile -G Ninja 
> -DCMAKE_MAKE_PROGRAM=/proj/flexasic/app/ninja/1.8.2/SLED11-64/bin/ninja 
> -DCMAKE_BUILD_TYPE=Release 
> -DCMAKE_C_FLAGS='-Wno-error=unused-command-line-argument' 
> -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_INSTALL_PREFIX=/compiler-clang 
> -DLLVM_APPEND_VC_REV=OFF -DLLVM_CCACHE_DIR=/repo/uabelho/.ccache/ 
> -DLLVM_CCACHE_BUILD=ON 
> -DLLVM_CCACHE_PROGRAM=/app/vbuild/RHEL7-x86_64/ccache/3.2.2/bin/ccache 
> -DLLVM_CCACHE_NOHASHDIR=ON -DLLVM_CCACHE_BASEDIR=/repo 
> -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_WERROR=ON 
> -DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld' 
> -DLLVM_ENABLE_Z3_SOLVER=ON 
> -DLLVM_Z3_INSTALL_DIR=/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1 
> -DLLVM_ENABLE_LIBPFM=OFF -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_TERMINFO=OFF 
> -DLLVM_ENABLE_LIBEDIT=OFF -DLLVM_STATIC_LINK_CXX_STDLIB=ON 
> -DCLANG_ENABLE_ARCMT=OFF -DCLANG_TOOLING_BUILD_AST_INTROSPECTION=OFF
>
> Could it be something like that there is a mismatch somewhere so the support 
> checks will use some libs but then the actual libs used when 
> compiling/running is something else?

Thanks for the detailed information. I'm thining it's because of 
LLVM_STATIC_LINK_CXX_STDLIB=ON. The default method used by ORC for finding 
external symbol on linux is look up the symbols defined by the current process 
and dynamic libraries loaded so far using dlsym. Since libstdc++ was statically 
linked, some of the libstdc++ symbols might not be visible in symbol table. 
It's still weird that it has successfully found `__cxa_throw` though. (the log 
you showed says it has found `__cxa_throw`)

I'll try to reproduce the issue by tweaking LLVM_STATIC_LINK_CXX_STDLIB on my 
local machine and report back.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129242

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


[PATCH] D130363: [clang] Give priority to Class context while parsing declarations

2022-07-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

Can you also add a test, preferably in clang/test/CodeCompletion/overrides.cpp ?




Comment at: clang/lib/Parse/ParseDecl.cpp:3269
 
-  if (getCurScope()->getFnParent() || getCurScope()->getBlockParent())
-CCC = Sema::PCC_LocalDeclarationSpecifiers;
-  else if (TemplateInfo.Kind != ParsedTemplateInfo::NonTemplate)
+  if (TemplateInfo.Kind != ParsedTemplateInfo::NonTemplate)
 CCC = DSContext == DeclSpecContext::DSC_class ? 
Sema::PCC_MemberTemplate

i think the importance of ordering requires a comment here, maybe something 
like:
`Class context can appear inside a function/block, so prioritise that. `


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130363

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


[PATCH] D130566: [Driver] Default to DWARF 4 on Linux/sparc64

2022-07-29 Thread Rainer Orth via Phabricator via cfe-commits
ro abandoned this revision.
ro added a comment.

Nick Clifton just commited a fix both to the binutils 2.39 branch and master.  
So the workaround certainly isn't necessary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130566

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


[clang] fbe022f - [Libcalls] Add tests with maytrap & non-errno for math libcalls.

2022-07-29 Thread Florian Hahn via cfe-commits

Author: Florian Hahn
Date: 2022-07-29T13:45:34+01:00
New Revision: fbe022f18961bb2523072cf9d2649db81b0592c0

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

LOG: [Libcalls] Add tests with maytrap & non-errno for math libcalls.

Added: 


Modified: 
clang/test/CodeGen/math-libcalls.c

Removed: 




diff  --git a/clang/test/CodeGen/math-libcalls.c 
b/clang/test/CodeGen/math-libcalls.c
index bf259d7e783be..d1af31631bb22 100644
--- a/clang/test/CodeGen/math-libcalls.c
+++ b/clang/test/CodeGen/math-libcalls.c
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-unknown 
-Wno-implicit-function-declaration -w -S -o - -emit-llvm  %s | 
FileCheck %s --check-prefix=NO__ERRNO
 // RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-unknown 
-Wno-implicit-function-declaration -w -S -o - -emit-llvm -fmath-errno %s | 
FileCheck %s --check-prefix=HAS_ERRNO
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-unknown 
-Wno-implicit-function-declaration -w -S -o - -emit-llvm 
-ffp-exception-behavior=maytrap %s | FileCheck %s --check-prefix=HAS_MAYTRAP
 // RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-unknown-gnu 
-Wno-implicit-function-declaration -w -S -o - -emit-llvm -fmath-errno %s | 
FileCheck %s --check-prefix=HAS_ERRNO_GNU
 // RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-windows-msvc 
-Wno-implicit-function-declaration -w -S -o - -emit-llvm -fmath-errno %s | 
FileCheck %s --check-prefix=HAS_ERRNO_WIN
 
@@ -8,66 +9,87 @@
 void foo(double *d, float f, float *fp, long double *l, int *i, const char *c) 
{
   f = fmod(f,f); f = fmodf(f,f);f = fmodl(f,f);
 
-// NO__ERRNO: frem double
-// NO__ERRNO: frem float
-// NO__ERRNO: frem x86_fp80
-// HAS_ERRNO: declare double @fmod(double noundef, double noundef) 
[[NOT_READNONE:#[0-9]+]]
-// HAS_ERRNO: declare float @fmodf(float noundef, float noundef) 
[[NOT_READNONE]]
-// HAS_ERRNO: declare x86_fp80 @fmodl(x86_fp80 noundef, x86_fp80 noundef) 
[[NOT_READNONE]]
+  // NO__ERRNO: frem double
+  // NO__ERRNO: frem float
+  // NO__ERRNO: frem x86_fp80
+  // HAS_ERRNO: declare double @fmod(double noundef, double noundef) 
[[NOT_READNONE:#[0-9]+]]
+  // HAS_ERRNO: declare float @fmodf(float noundef, float noundef) 
[[NOT_READNONE]]
+  // HAS_ERRNO: declare x86_fp80 @fmodl(x86_fp80 noundef, x86_fp80 noundef) 
[[NOT_READNONE]]
+  // HAS_MAYTRAP: declare double @llvm.experimental.constrained.frem.f64(
+  // HAS_MAYTRAP: declare float @llvm.experimental.constrained.frem.f32(
+  // HAS_MAYTRAP: declare x86_fp80 @llvm.experimental.constrained.frem.f80(
 
   atan2(f,f);atan2f(f,f) ;  atan2l(f, f);
 
-// NO__ERRNO: declare double @atan2(double noundef, double noundef) 
[[READNONE:#[0-9]+]]
-// NO__ERRNO: declare float @atan2f(float noundef, float noundef) [[READNONE]]
-// NO__ERRNO: declare x86_fp80 @atan2l(x86_fp80 noundef, x86_fp80 noundef) 
[[READNONE]]
-// HAS_ERRNO: declare double @atan2(double noundef, double noundef) 
[[NOT_READNONE]]
-// HAS_ERRNO: declare float @atan2f(float noundef, float noundef) 
[[NOT_READNONE]]
-// HAS_ERRNO: declare x86_fp80 @atan2l(x86_fp80 noundef, x86_fp80 noundef) 
[[NOT_READNONE]]
+  // NO__ERRNO: declare double @atan2(double noundef, double noundef) 
[[READNONE:#[0-9]+]]
+  // NO__ERRNO: declare float @atan2f(float noundef, float noundef) 
[[READNONE]]
+  // NO__ERRNO: declare x86_fp80 @atan2l(x86_fp80 noundef, x86_fp80 noundef) 
[[READNONE]]
+  // HAS_ERRNO: declare double @atan2(double noundef, double noundef) 
[[NOT_READNONE]]
+  // HAS_ERRNO: declare float @atan2f(float noundef, float noundef) 
[[NOT_READNONE]]
+  // HAS_ERRNO: declare x86_fp80 @atan2l(x86_fp80 noundef, x86_fp80 noundef) 
[[NOT_READNONE]]
+  // HAS_MAYTRAP: declare double @atan2(double noundef, double noundef) 
[[READNONE:#[0-9]+]]
+  // HAS_MAYTRAP: declare float @atan2f(float noundef, float noundef) 
[[READNONE]]
+  // HAS_MAYTRAP: declare x86_fp80 @atan2l(x86_fp80 noundef, x86_fp80 noundef) 
[[READNONE]]
 
   copysign(f,f); copysignf(f,f);copysignl(f,f);
 
-// NO__ERRNO: declare double @llvm.copysign.f64(double, double) 
[[READNONE_INTRINSIC:#[0-9]+]]
-// NO__ERRNO: declare float @llvm.copysign.f32(float, float) 
[[READNONE_INTRINSIC]]
-// NO__ERRNO: declare x86_fp80 @llvm.copysign.f80(x86_fp80, x86_fp80) 
[[READNONE_INTRINSIC]]
-// HAS_ERRNO: declare double @llvm.copysign.f64(double, double) 
[[READNONE_INTRINSIC:#[0-9]+]]
-// HAS_ERRNO: declare float @llvm.copysign.f32(float, float) 
[[READNONE_INTRINSIC]]
-// HAS_ERRNO: declare x86_fp80 @llvm.copysign.f80(x86_fp80, x86_fp80) 
[[READNONE_INTRINSIC]]
+  // NO__ERRNO: declare double @llvm.copysign.f64(double, double) 
[[READNONE_INTRINSIC:#[0-9]+]]
+  // NO__ERRNO: declare float @llvm.copysign.f32(float, float) 

[PATCH] D126676: [clang] Disallow differences in defines used for creating and using PCH

2022-07-29 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

I haven’t reviewed the details of the patch and won’t have time to do so (at 
least for a while), but the description of the intended (more narrow) scope 
SGTM. With the scope limited to GCC directories this should be fine.

There are cases where it’s safe to have mismatched defines (e.g., if a define 
can be proven during a cheap dependency scan not to matter for a given PCH, 
it’s better to canonicalize away the define and share the artifact more 
broadly) but if I understand correctly this patch won’t preclude compiler 
smarts like that.

If I’m right, then I think this can go in once @rnk is happy. (If I’m wrong, 
maybe better to wait for one of the people I pinged.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126676

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


[PATCH] D130766: [SPIR-V] Disable opaque pointers in relese 15

2022-07-29 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia created this revision.
Anastasia added reviewers: svenvh, iliya-diyachkov.
Herald added a subscriber: ebevhan.
Herald added a project: All.
Anastasia requested review of this revision.
Herald added a subscriber: MaskRay.

As discussed on RFC mapping into SPIR-V requires pointer being preserved in 
some cases: 
https://discourse.llvm.org/t/rfc-better-support-for-typed-pointers-in-an-opaque-pointer-world/63339/23?u=anastasiastulova

As the work is still unfinished the best approach is to continue using pointer 
types.

Note that this change is only planned to be committed in release 15 branch.

This fixing PR56660.


https://reviews.llvm.org/D130766

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/spirv-toolchain.cl


Index: clang/test/Driver/spirv-toolchain.cl
===
--- clang/test/Driver/spirv-toolchain.cl
+++ clang/test/Driver/spirv-toolchain.cl
@@ -6,6 +6,7 @@
 // RUN: %clang -### --target=spirv64 -x c -c %s 2>&1 | FileCheck 
--check-prefix=SPV64 %s
 
 // SPV64: "-cc1" "-triple" "spirv64"
+// SPV64-SAME: "-no-opaque-pointers"
 // SPV64-SAME: "-o" [[BC:".*bc"]]
 // SPV64: {{llvm-spirv.*"}} [[BC]] "-o" {{".*o"}}
 
@@ -16,6 +17,7 @@
 // RUN: %clang -### --target=spirv32 -x c -c %s 2>&1 | FileCheck 
--check-prefix=SPV32 %s
 
 // SPV32: "-cc1" "-triple" "spirv32"
+// SPV32-SAME: "-no-opaque-pointers"
 // SPV32-SAME: "-o" [[BC:".*bc"]]
 // SPV32: {{llvm-spirv.*"}} [[BC]] "-o" {{".*o"}}
 
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4630,8 +4630,13 @@
   TC.addClangWarningOptions(CmdArgs);
 
   // FIXME: Subclass ToolChain for SPIR and move this to 
addClangWarningOptions.
-  if (Triple.isSPIR() || Triple.isSPIRV())
+  if (Triple.isSPIR() || Triple.isSPIRV()) {
 CmdArgs.push_back("-Wspir-compat");
+// SPIR-V support still needs pointer types in some cases as recovering
+// type from pointer uses is not always possible e.g. for extern functions
+// (see PR56660).
+CmdArgs.push_back("-no-opaque-pointers");
+  }
 
   // Select the appropriate action.
   RewriteKind rewriteKind = RK_None;


Index: clang/test/Driver/spirv-toolchain.cl
===
--- clang/test/Driver/spirv-toolchain.cl
+++ clang/test/Driver/spirv-toolchain.cl
@@ -6,6 +6,7 @@
 // RUN: %clang -### --target=spirv64 -x c -c %s 2>&1 | FileCheck --check-prefix=SPV64 %s
 
 // SPV64: "-cc1" "-triple" "spirv64"
+// SPV64-SAME: "-no-opaque-pointers"
 // SPV64-SAME: "-o" [[BC:".*bc"]]
 // SPV64: {{llvm-spirv.*"}} [[BC]] "-o" {{".*o"}}
 
@@ -16,6 +17,7 @@
 // RUN: %clang -### --target=spirv32 -x c -c %s 2>&1 | FileCheck --check-prefix=SPV32 %s
 
 // SPV32: "-cc1" "-triple" "spirv32"
+// SPV32-SAME: "-no-opaque-pointers"
 // SPV32-SAME: "-o" [[BC:".*bc"]]
 // SPV32: {{llvm-spirv.*"}} [[BC]] "-o" {{".*o"}}
 
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4630,8 +4630,13 @@
   TC.addClangWarningOptions(CmdArgs);
 
   // FIXME: Subclass ToolChain for SPIR and move this to addClangWarningOptions.
-  if (Triple.isSPIR() || Triple.isSPIRV())
+  if (Triple.isSPIR() || Triple.isSPIRV()) {
 CmdArgs.push_back("-Wspir-compat");
+// SPIR-V support still needs pointer types in some cases as recovering
+// type from pointer uses is not always possible e.g. for extern functions
+// (see PR56660).
+CmdArgs.push_back("-no-opaque-pointers");
+  }
 
   // Select the appropriate action.
   RewriteKind rewriteKind = RK_None;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130766: [SPIR-V] Disable opaque pointers in relese 15

2022-07-29 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a subscriber: linjamaki.
Anastasia added a comment.

CC to @linjamaki in case there is anything else/different needed for HIP.


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

https://reviews.llvm.org/D130766

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


[clang] b259027 - [NFCI] Propagate MLTAL through more concepts in prep of deferred inst.

2022-07-29 Thread Erich Keane via cfe-commits

Author: Erich Keane
Date: 2022-07-29T05:54:04-07:00
New Revision: b25902736c2e330429278e1929cc5afd2201fb77

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

LOG: [NFCI] Propagate MLTAL through more concepts in prep of deferred inst.

In preperation of the deferred instantation progress, this patch
propagates the multi-level template argument lists further through the
API to reduce the size of that patch.

Added: 


Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaConcept.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/lib/Sema/SemaTemplateDeduction.cpp

Removed: 




diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 62023fe42a218..b84ad1283173d 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -7153,7 +7153,7 @@ class Sema final {
   /// false otherwise.
   bool CheckConstraintSatisfaction(
   const NamedDecl *Template, ArrayRef ConstraintExprs,
-  ArrayRef TemplateArgs,
+  const MultiLevelTemplateArgumentList &TemplateArgLists,
   SourceRange TemplateIDRange, ConstraintSatisfaction &Satisfaction);
 
   /// \brief Check whether the given non-dependent constraint expression is
@@ -7189,9 +7189,10 @@ class Sema final {
   ///
   /// \returns true if the constrains are not satisfied or could not be checked
   /// for satisfaction, false if the constraints are satisfied.
-  bool EnsureTemplateArgumentListConstraints(TemplateDecl *Template,
-   ArrayRef TemplateArgs,
- SourceRange TemplateIDRange);
+  bool EnsureTemplateArgumentListConstraints(
+  TemplateDecl *Template,
+  const MultiLevelTemplateArgumentList &TemplateArgs,
+  SourceRange TemplateIDRange);
 
   /// \brief Emit diagnostics explaining why a constraint expression was deemed
   /// unsatisfied.

diff  --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index 239e5dc4394c3..f0ccc0710cfb4 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -199,9 +199,9 @@ calculateConstraintSatisfaction(Sema &S, const Expr 
*ConstraintExpr,
 }
 
 static bool calculateConstraintSatisfaction(
-Sema &S, const NamedDecl *Template, ArrayRef 
TemplateArgs,
-SourceLocation TemplateNameLoc, MultiLevelTemplateArgumentList &MLTAL,
-const Expr *ConstraintExpr, ConstraintSatisfaction &Satisfaction) {
+Sema &S, const NamedDecl *Template, SourceLocation TemplateNameLoc,
+const MultiLevelTemplateArgumentList &MLTAL, const Expr *ConstraintExpr,
+ConstraintSatisfaction &Satisfaction) {
   return calculateConstraintSatisfaction(
   S, ConstraintExpr, Satisfaction, [&](const Expr *AtomicExpr) {
 EnterExpressionEvaluationContext ConstantEvaluated(
@@ -268,36 +268,35 @@ static bool calculateConstraintSatisfaction(
   });
 }
 
-static bool CheckConstraintSatisfaction(Sema &S, const NamedDecl *Template,
-ArrayRef ConstraintExprs,
-ArrayRef 
TemplateArgs,
-SourceRange TemplateIDRange,
-ConstraintSatisfaction &Satisfaction) {
+static bool CheckConstraintSatisfaction(
+Sema &S, const NamedDecl *Template, ArrayRef ConstraintExprs,
+const MultiLevelTemplateArgumentList &TemplateArgsLists,
+SourceRange TemplateIDRange, ConstraintSatisfaction &Satisfaction) {
   if (ConstraintExprs.empty()) {
 Satisfaction.IsSatisfied = true;
 return false;
   }
 
-  for (auto& Arg : TemplateArgs)
-if (Arg.isInstantiationDependent()) {
-  // No need to check satisfaction for dependent constraint expressions.
-  Satisfaction.IsSatisfied = true;
-  return false;
-}
+  if (TemplateArgsLists.isAnyArgInstantiationDependent()) {
+// No need to check satisfaction for dependent constraint expressions.
+Satisfaction.IsSatisfied = true;
+return false;
+  }
 
+  ArrayRef TemplateArgs =
+  TemplateArgsLists.getNumSubstitutedLevels() > 0
+  ? TemplateArgsLists.getOutermost()
+  : ArrayRef {};
   Sema::InstantiatingTemplate Inst(S, TemplateIDRange.getBegin(),
   Sema::InstantiatingTemplate::ConstraintsCheck{},
   const_cast(Template), TemplateArgs, TemplateIDRange);
   if (Inst.isInvalid())
 return true;
 
-  MultiLevelTemplateArgumentList MLTAL;
-  MLTAL.addOuterTemplateArguments(TemplateArgs);
-
   for (const Expr *ConstraintExpr : ConstraintExprs) {
-if (calculateConstraintSatisfaction(S, Template, TemplateArgs,
-TemplateIDRange.getBegin(), MLTAL,
-ConstraintExpr, Satisfaction))
+if

[PATCH] D130768: [OpenCL][SPIR-V] Add test for extern functions with a pointer

2022-07-29 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia created this revision.
Anastasia added reviewers: svenvh, iliya-diyachkov.
Herald added subscribers: ebevhan, yaxunl.
Herald added a project: All.
Anastasia requested review of this revision.

I would like to add this test case that enhances coverage of opaque pointers 
particularly for the problematic case with `extern` functions for which there 
is no solution found yet.


https://reviews.llvm.org/D130768

Files:
  clang/test/CodeGenOpenCL/opaque-ptr-spirv.cl


Index: clang/test/CodeGenOpenCL/opaque-ptr-spirv.cl
===
--- /dev/null
+++ clang/test/CodeGenOpenCL/opaque-ptr-spirv.cl
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -no-opaque-pointers -emit-llvm -o - -triple spirv64 %s | 
FileCheck %s
+
+// Check that we have a way to recover pointer
+// types for extern function prototypes (see PR56660).
+extern void foo(global int * ptr);
+kernel void k(global int * ptr) {
+  foo(ptr);
+}
+//CHECK: define spir_kernel void @k(i32 {{.*}}*
+//CHECK: declare spir_func void @foo(i32 {{.*}}*


Index: clang/test/CodeGenOpenCL/opaque-ptr-spirv.cl
===
--- /dev/null
+++ clang/test/CodeGenOpenCL/opaque-ptr-spirv.cl
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -no-opaque-pointers -emit-llvm -o - -triple spirv64 %s | FileCheck %s
+
+// Check that we have a way to recover pointer
+// types for extern function prototypes (see PR56660).
+extern void foo(global int * ptr);
+kernel void k(global int * ptr) {
+  foo(ptr);
+}
+//CHECK: define spir_kernel void @k(i32 {{.*}}*
+//CHECK: declare spir_func void @foo(i32 {{.*}}*
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130766: [SPIR-V] Disable opaque pointers in relese 15

2022-07-29 Thread Nikita Popov via Phabricator via cfe-commits
nikic added reviewers: jcranmer-intel, opaque-pointers.
nikic added a comment.

LG from my side, as a temporary workaround.


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

https://reviews.llvm.org/D130766

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


[PATCH] D125291: Introduce @llvm.threadlocal.address intrinsic to access TLS variable

2022-07-29 Thread Nikita Popov via Phabricator via cfe-commits
nikic accepted this revision.
nikic added a comment.
This revision is now accepted and ready to land.

LG. Now that LLVM 15 has branched, I think it is safe to land this, and there 
will be enough time before LLVM 16 to convert it to the token variant.




Comment at: llvm/docs/LangRef.rst:24546
+
+The first argument is a pointer, which refers to a thread local variable.
+

I'd replace variable -> global here.


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

https://reviews.llvm.org/D125291

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


[PATCH] D122768: [Clang][C++20] Support capturing structured bindings in lambdas

2022-07-29 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

CodeGen tests is still not testing what we intend I believe (sorry if I missed 
the response to this!), plus I would like a quick explanation as to what is 
going on in 1 place, otherwise I think this is about right.  Hopefully 
Aaron/Shafik can take a quick look through to confirm as well.




Comment at: clang/lib/AST/ExprCXX.cpp:1214-1216
+  return (C->capturesVariable() && isa(C->getCapturedVar()) &&
+  cast(C->getCapturedVar())->isInitCapture() &&
   (getCallOperator() == C->getCapturedVar()->getDeclContext()));

erichkeane wrote:
> aaron.ballman wrote:
> > I think early returns help make this a bit more clear.
> I might suggest making that:
> 
> ```
> if (const auto *VD = dyn_castgetCapturedVar())
>return VD->...
> return false;
> ```
> 
> But otherwise agree with the suggestion.
FWIW, this seems nicer now without the casts.  I'm OK with this form, it is 
exactly what there was before minus some strange formatting/parens.



Comment at: clang/lib/Sema/SemaExpr.cpp:18399
+  if (Diagnose)
+diagnoseUncapturableValueReferenceOrBinding(S, Loc, Var);
+  return false;

first, why are we checking for !CPlusPlus... aren't BindingDecl's C++ only?  Or 
is there some ObjC thing for them?

second, can you clarify what the two diagnostic cases are doing?  it isn't 
completely clear to me the purpose of the first call here.



Comment at: clang/test/CodeGenCXX/cxx20-decomposition.cpp:26
+// CHECK: %{{.*}} = load ptr, {{.*}}
+// CHECK: %{{.*}} = load i32, {{.*}}
+// CHECK: %{{.*}} = getelementptr {{.*}}, i32 0, i32 0

cor3ntin wrote:
> erichkeane wrote:
> > Which is the important lines here?  You might want to use the 
> > `[[NAME:.whatever]]`  (then on the 'other' side: `[[NAME]]`)syntax in here 
> > to make sure that the check-lines don't find something else.
> > 
> > You also likely want to use `.+` to make sure there is actually a character 
> > in there.
> > 
> > 
> I'm trying to show i is captured by value and j isn't
Hmm... I don't think it is testing what you think you're testing, particularly 
with so many unnamed checks.  If you send me the IR that this produces and 
highlight which are the 'important' lines, I can help write this for you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122768

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


[PATCH] D130224: [Clang][Attribute] Introduce maybe_undef attribute for function arguments which accepts undef values

2022-07-29 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D130224#3686756 , @nlopes wrote:

> Would it be possible to implement this by dropping the `noundef` attribute 
> rather than emitting a freeze? Seems like a much better option to me.

See @nhaehnle's post here 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130224

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


[PATCH] D130726: [clang][dataflow] Handle multiple context-sensitive calls to the same function

2022-07-29 Thread Sam Estep via Phabricator via cfe-commits
samestep added inline comments.



Comment at: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp:3963
 
+TEST(TransferTest, ContextSensitiveSetBothTrueAndFalse) {
+  std::string Code = R"(

ymandel wrote:
> ymandel wrote:
> > samestep wrote:
> > > ymandel wrote:
> > > > Are there more scenarios testable at this point? e.g
> > > > 1. 2 layers of callees
> > > > 2. more than one line of code inside the body?
> > > > 3. one than one CFG block in the body?
> > > > 
> > > > If so, please add tests for those that are supported.
> > > 1. This currently isn't supported.
> > > 2. This should work.
> > > 3. This should work.
> > > 
> > > For (2) and (3), should I add those tests now, or do that in a followup 
> > > patch?
> > > 1. This currently isn't supported.
> > What's limiting us here? Just curious, not asking you to update the 
> > comments, etc.
> > 
> > > 2. This should work.
> > > 3. This should work.
> > > 
> > > For (2) and (3), should I add those tests now, or do that in a followup 
> > > patch?
> > 
> > may as well add them now. thx
> > 1. This currently isn't supported.
> > 2. This should work.
> > 3. This should work.
> > 
> > For (2) and (3), should I add those tests now, or do that in a followup 
> > patch?
> 
> 
> What's limiting us here? Just curious, not asking you to update the comments, 
> etc.

Nothing's really limiting us; all I meant was that currently we don't turn on 
context-sensitivity for the sub-analysis when we analyze the callee, and I 
don't want to turn that on until I've added support both for limiting the depth 
and for selecting the set of symbols to analyze using an allowlist.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130726

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


[PATCH] D130224: [Clang][Attribute] Introduce maybe_undef attribute for function arguments which accepts undef values

2022-07-29 Thread Nuno Lopes via Phabricator via cfe-commits
nlopes added a comment.

In D130224#3687351 , @arsenm wrote:

> In D130224#3686756 , @nlopes wrote:
>
>> Would it be possible to implement this by dropping the `noundef` attribute 
>> rather than emitting a freeze? Seems like a much better option to me.
>
> See @nhaehnle's post here 
> 

Thank you for the reference!
Seems like a big hammer, but I don't know the semantics of the GPU languages to 
comment further.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130224

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


[PATCH] D130224: [Clang][Attribute] Introduce maybe_undef attribute for function arguments which accepts undef values

2022-07-29 Thread Mubariz Afzal via Phabricator via cfe-commits
mubarizafzal added a comment.

Hi, the test cases that this patch introduces are failing on some ppc64le 
(Linux on Power) buildbots:
https://lab.llvm.org/buildbot/#/builders/57
https://lab.llvm.org/buildbot/#/builders/230

Would you mind taking a look please?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130224

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


[PATCH] D126676: [clang] Disallow differences in defines used for creating and using PCH

2022-07-29 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In D126676#3687227 , @dexonsmith 
wrote:

> I haven’t reviewed the details of the patch and won’t have time to do so (at 
> least for a while), but the description of the intended (more narrow) scope 
> SGTM. With the scope limited to GCC directories this should be fine.
>
> There are cases where it’s safe to have mismatched defines (e.g., if a define 
> can be proven during a cheap dependency scan not to matter for a given PCH, 
> it’s better to canonicalize away the define and share the artifact more 
> broadly) but if I understand correctly this patch won’t preclude compiler 
> smarts like that.

Yup. Any implementation of such logic hasn’t materialized during the 10 years 
since todos hinting that we should implement that, but it doesn’t seem to be a 
big practical issue either, outside of false positive matches with gcc PCH 
directories - so I guess it’s not a high priority in practice.

> If I’m right, then I think this can go in once @rnk is happy. (If I’m wrong, 
> maybe better to wait for one of the people I pinged.)

Yeah, I’d be happy to add a validation level enum to make things a bit clearer 
- I’ll try to revise the patch soon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126676

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


[PATCH] D130777: Enable embedded lto for XCOFF.

2022-07-29 Thread Sean Fertile via Phabricator via cfe-commits
sfertile created this revision.
sfertile added reviewers: hubert.reinterpretcast, DiggerLin, nemanjai, MaskRay, 
tejohnson, mehdi_amini, phosek, arda.
Herald added subscribers: ormris, StephenFan, steven_wu, kbarton, hiraditya, 
inglorion, mgorny.
Herald added a project: All.
sfertile requested review of this revision.
Herald added projects: clang, LLVM.
Herald added a subscriber: cfe-commits.

The traditional system compiler (xlc) on AIX uses a 'fat' object format for LTO 
by default, embedding the intermediate representation into a special '.ipa' 
section in native XCOFF object files. Then at link time depending on command 
line options either a native link or an ipa link can be performed. This patch 
adds support for embedding the pre-link IR into the module which is then 
codegened to a native XCOFF object with the bitcode emebededed in the .info 
section. The .info section representation starts with a magic number, followed 
by an 8-byte size, an identifier string and a 4-byte unsigned difference, 
finally followed by the payload. The magic number and identifier string indcate 
to the linker that the embedded metadata is bitcode and it is appropriate for 
use in LTO.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130777

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/PowerPC/aix-embedded-bitcode.c
  clang/test/CodeGen/embed-lto-metadata.c
  clang/test/Driver/embedded-lto.c
  llvm/include/llvm/Bitcode/EmbedBitcodePass.h
  llvm/include/llvm/MC/MCStreamer.h
  llvm/include/llvm/MC/MCXCOFFStreamer.h
  llvm/lib/Bitcode/Writer/CMakeLists.txt
  llvm/lib/Bitcode/Writer/EmbedBitcodePass.cpp
  llvm/lib/MC/MCAsmStreamer.cpp
  llvm/lib/MC/MCStreamer.cpp
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Passes/PassRegistry.def
  llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
  llvm/test/Bitcode/embed-multiple.ll
  llvm/test/Bitcode/embed-unsupported-object-format.ll
  llvm/test/Bitcode/embed.ll
  llvm/test/CodeGen/PowerPC/aix-embeded-bitcode.ll
  llvm/test/CodeGen/PowerPC/aix-embeded-module-padding.ll
  llvm/test/Transforms/Util/embeded-lto-TLI-mappings.ll

Index: llvm/test/Transforms/Util/embeded-lto-TLI-mappings.ll
===
--- /dev/null
+++ llvm/test/Transforms/Util/embeded-lto-TLI-mappings.ll
@@ -0,0 +1,20 @@
+; RUN: opt -vector-library=MASSV  -passes='function(inject-tli-mappings),embed-bitcode' -S < %s | FileCheck %s
+
+target triple = "powerpc-unknown-aix"
+
+; CHECK: @llvm.compiler.used = appending global [3 x ptr] [ptr @__sind2, ptr @__log10f4, ptr @llvm.embedded.module], section "llvm.metadata"
+
+define double @sin_f64(double %in) {
+  %call = tail call double @sin(double %in)
+  ret double %call
+}
+
+declare double @sin(double) #0
+
+define float @call_llvm.log10.f32(float %in) {
+  %call = tail call float @llvm.log10.f32(float %in)
+  ret float %call
+}
+
+declare float @llvm.log10.f32(float) #0
+attributes #0 = { nounwind readnone }
Index: llvm/test/CodeGen/PowerPC/aix-embeded-module-padding.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/aix-embeded-module-padding.ll
@@ -0,0 +1,20 @@
+; RUN: llc -mtriple powerpc-ibm-aix-xcoff < %s | \
+; RUN: FileCheck %s
+; RUN: llc -mtriple powerpc64-ibm-aix-xcoff < %s | \
+; RUN: FileCheck %s
+
+target datalayout = "E-m:a-p:32:32-i64:64-n32"
+target triple = "powerpc-ibm-aix7.2.0.0"
+
+@c = local_unnamed_addr global i8 -85, align 1
+@llvm.embedded.module = private constant [1647 x i8] c"BC\C0\DE5\14\00\00\05\00\00\00b\0C0$MY\BEf\9D\FB\B4O\1B\C8$D\012\05\00!\0C\00\00_\01\00\00\0B\02!\00\02\00\00\00\16\00\00\00\07\81#\91A\C8\04I\06\1029\92\01\84\0C%\05\08\19\1E\04\8Bb\80\0CE\02B\92\0BBd\102\148\08\18K\0A22\88Hp\C4!#D\12\87\8C\10A\92\02d\C8\08\B1\14 CF\88 \C9\0122\84\18*(*\901|\B0\\\91 \C3\C8\00\00\00\89 \00\00\0B\00\00\002\22\C8\08 bF\00!+$\98\0C!%$\98\0C\19'\0C\85\A4\90`2d\\ $c\82\80\98#@\08\03\01s\04`\00\00\13,xx\87{(\07y\80\87qh\83t\10\87vh\83pH\07|\B8\037\90\037\80\037\80\83\0DX)\B4A;\E8A8\B4\01<\E8\C1\1C\C8\81\1E\CC\81\1C\B4A:\D8\01\1D\E8\81\1D\D0A\1B\B8\C3\1C\C8\81\D2\03B\84\04\90!#EB\00\8D\10\86}$\A41\16\E27\16'\00\16_\D8!\01\01 \08@\00\00\80\00\00\00\00\04\80\C4\06\81\C2d\01\00\00Y \00\00\00\07\00\00\002\1E\98\0C\19\11L\90\8C\09&G\C6\04CB\AD\06\D0J\A0\08\CAa\04\00\00\00\B1\18\00\00\9B\00\00\003\08\80\1C\C4\E1\1Cf\14\01=\88C8\84\C3\8CB\80\07yx\07s\98q\0C\E6\00\0F\ED\10\0E\F4\80\0E3\0CB\1E\C2\C1\1D\CE\A1\1Cf0\05=\88C8\84\83\1B\CC\03=\C8C=\8C\03=\CCx\8Ctp\07{\08\07yH\87pp\07zp\03vx\87p \87\19\CC\11\0E\EC\90\0E\E10\0Fn0\0F\E3\F0\0E\F0P\0E3\10\C4\1D\DE!\1C\D8!\1D\C2a\1Ef0\89;\BC\83;\D0C9\B4\03<\BC\83<\84\03;\CC\F0\14v`\07{h\077h\87rh\077\80\87p\90\87p`\07v(\07v\F8\05vx\87w\80\87_\08\87q\18\87r\98\87y\98\81,\EE\F0\0E\EE\E0\0E\F5\C0\0E\EC0\03b\C8\A1\1C\E4\A1\1

[PATCH] D127812: [AArch64] Function multiversioning support added.

2022-07-29 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss requested changes to this revision.
danielkiss added a comment.
This revision now requires changes to proceed.

Please find the thread on the GCC mailing list here: 
https://gcc.gnu.org/pipermail/gcc/2022-July/239134.html 
Feedback there sounds positive to me.
All received feedback added to this PR.
https://github.com/ARM-software/acle/pull/211

@ilinpv Could you please update the patch accordingly?

(I'm on vacation until September, please expect slow responses.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127812

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


[PATCH] D129231: [Builtins] Do not claim all libfuncs are readnone with trapping math.

2022-07-29 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 448628.
fhahn added a comment.



In D129231#3638946 , @john.brawn 
wrote:

> Looking at the descriptions of maths functions in C99 (and I expect C11 will 
> be the same) it looks like there are three kinds:
>
> - Those that can report error by errno and floating-point exeption, and may 
> also raise the inexact exception
> - Those that don't set errno, but may raise the inexact exception
> - Those that neither set errno or raise an exception
>
> Looking at this patch and the attributes of the various function intrinsics 
> it looks like you have:
>
> - Marked "e": Can set errno, can't raise exception
> - Marked "eg": Can set errno and raise exception
> - Marked "cg": Can't set errno, can raise an exception
> - Marked "c": Can't set errno or raise an exception
>
> Given that the functions that set errno also raise exceptions I think it 
> would make sense to have the "e" attribute cover both errno and exceptions, 
> and have "g" just for those that can only raise exceptions. Also "cg" looks 
> like it's probably wrong and should be "g" (given that "c" means "always 
> const" and "g" means "const only when we don't have exceptions", and that's 
> also how "e" is used in that we don't have functions with "cg").

Thanks you very much for taking a look! I updated the patch to redefine "e" to 
mean const if no errno and no exceptions. Now the only markings are either "e" 
or "g". The functions originally marked "cg" were indeed a mistake.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129231

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/Builtins.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CodeGen/math-libcalls.c

Index: clang/test/CodeGen/math-libcalls.c
===
--- clang/test/CodeGen/math-libcalls.c
+++ clang/test/CodeGen/math-libcalls.c
@@ -27,9 +27,9 @@
   // HAS_ERRNO: declare double @atan2(double noundef, double noundef) [[NOT_READNONE]]
   // HAS_ERRNO: declare float @atan2f(float noundef, float noundef) [[NOT_READNONE]]
   // HAS_ERRNO: declare x86_fp80 @atan2l(x86_fp80 noundef, x86_fp80 noundef) [[NOT_READNONE]]
-  // HAS_MAYTRAP: declare double @atan2(double noundef, double noundef) [[READNONE:#[0-9]+]]
-  // HAS_MAYTRAP: declare float @atan2f(float noundef, float noundef) [[READNONE]]
-  // HAS_MAYTRAP: declare x86_fp80 @atan2l(x86_fp80 noundef, x86_fp80 noundef) [[READNONE]]
+  // HAS_MAYTRAP: declare double @atan2(double noundef, double noundef) [[NOT_READNONE:#[0-9]+]]
+  // HAS_MAYTRAP: declare float @atan2f(float noundef, float noundef) [[NOT_READNONE]]
+  // HAS_MAYTRAP: declare x86_fp80 @atan2l(x86_fp80 noundef, x86_fp80 noundef) [[NOT_READNONE]]
 
   copysign(f,f); copysignf(f,f);copysignl(f,f);
 
@@ -63,7 +63,7 @@
   // HAS_ERRNO: declare double @frexp(double noundef, i32* noundef) [[NOT_READNONE]]
   // HAS_ERRNO: declare float @frexpf(float noundef, i32* noundef) [[NOT_READNONE]]
   // HAS_ERRNO: declare x86_fp80 @frexpl(x86_fp80 noundef, i32* noundef) [[NOT_READNONE]]
-  // HAS_MAYTRAP: declare double @frexp(double noundef, i32* noundef) [[NOT_READNONE:#[0-9]+]]
+  // HAS_MAYTRAP: declare double @frexp(double noundef, i32* noundef) [[NOT_READNONE]]
   // HAS_MAYTRAP: declare float @frexpf(float noundef, i32* noundef) [[NOT_READNONE]]
   // HAS_MAYTRAP: declare x86_fp80 @frexpl(x86_fp80 noundef, i32* noundef) [[NOT_READNONE]]
 
@@ -75,9 +75,9 @@
   // HAS_ERRNO: declare double @ldexp(double noundef, i32 noundef) [[NOT_READNONE]]
   // HAS_ERRNO: declare float @ldexpf(float noundef, i32 noundef) [[NOT_READNONE]]
   // HAS_ERRNO: declare x86_fp80 @ldexpl(x86_fp80 noundef, i32 noundef) [[NOT_READNONE]]
-  // HAS_MAYTRAP: declare double @ldexp(double noundef, i32 noundef) [[READNONE]]
-  // HAS_MAYTRAP: declare float @ldexpf(float noundef, i32 noundef) [[READNONE]]
-  // HAS_MAYTRAP: declare x86_fp80 @ldexpl(x86_fp80 noundef, i32 noundef) [[READNONE]]
+  // HAS_MAYTRAP: declare double @ldexp(double noundef, i32 noundef) [[NOT_READNONE]]
+  // HAS_MAYTRAP: declare float @ldexpf(float noundef, i32 noundef) [[NOT_READNONE]]
+  // HAS_MAYTRAP: declare x86_fp80 @ldexpl(x86_fp80 noundef, i32 noundef) [[NOT_READNONE]]
 
   modf(f,d);   modff(f,fp);  modfl(f,l);
 
@@ -125,9 +125,9 @@
 // HAS_ERRNO: declare double @acos(double noundef) [[NOT_READNONE]]
 // HAS_ERRNO: declare float @acosf(float noundef) [[NOT_READNONE]]
 // HAS_ERRNO: declare x86_fp80 @acosl(x86_fp80 noundef) [[NOT_READNONE]]
-// HAS_MAYTRAP: declare double @acos(double noundef) [[READNONE]]
-// HAS_MAYTRAP: declare float @acosf(float noundef) [[READNONE]]
-// HAS_MAYTRAP: declare x86_fp80 @acosl(x86_fp80 noundef) [[READNONE]]
+// HAS_MAYTRAP: declare double @acos(double noundef) [[NOT_READNONE]]
+// HAS_MAYTRAP: declare float @acosf(float noun

[PATCH] D122768: [Clang][C++20] Support capturing structured bindings in lambdas

2022-07-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:18399
+  if (Diagnose)
+diagnoseUncapturableValueReferenceOrBinding(S, Loc, Var);
+  return false;

erichkeane wrote:
> first, why are we checking for !CPlusPlus... aren't BindingDecl's C++ only?  
> Or is there some ObjC thing for them?
> 
> second, can you clarify what the two diagnostic cases are doing?  it isn't 
> completely clear to me the purpose of the first call here.
The first diagnostic is where we diagnose usages outside of C++ lambdas.
And below are just the C++ extension warnings



Comment at: clang/test/CodeGenCXX/cxx20-decomposition.cpp:26
+// CHECK: %{{.*}} = load ptr, {{.*}}
+// CHECK: %{{.*}} = load i32, {{.*}}
+// CHECK: %{{.*}} = getelementptr {{.*}}, i32 0, i32 0

erichkeane wrote:
> cor3ntin wrote:
> > erichkeane wrote:
> > > Which is the important lines here?  You might want to use the 
> > > `[[NAME:.whatever]]`  (then on the 'other' side: `[[NAME]]`)syntax in 
> > > here to make sure that the check-lines don't find something else.
> > > 
> > > You also likely want to use `.+` to make sure there is actually a 
> > > character in there.
> > > 
> > > 
> > I'm trying to show i is captured by value and j isn't
> Hmm... I don't think it is testing what you think you're testing, 
> particularly with so many unnamed checks.  If you send me the IR that this 
> produces and highlight which are the 'important' lines, I can help write this 
> for you.
To be perfectly honest, I'm neither confident about which lines are important, 
nor whether the test case is as meaningful as it can be.
I'm happy to mail you the IR if you have time to look at it :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122768

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


[PATCH] D122768: [Clang][C++20] Support capturing structured bindings in lambdas

2022-07-29 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/test/CodeGenCXX/cxx20-decomposition.cpp:26
+// CHECK: %{{.*}} = load ptr, {{.*}}
+// CHECK: %{{.*}} = load i32, {{.*}}
+// CHECK: %{{.*}} = getelementptr {{.*}}, i32 0, i32 0

cor3ntin wrote:
> erichkeane wrote:
> > cor3ntin wrote:
> > > erichkeane wrote:
> > > > Which is the important lines here?  You might want to use the 
> > > > `[[NAME:.whatever]]`  (then on the 'other' side: `[[NAME]]`)syntax in 
> > > > here to make sure that the check-lines don't find something else.
> > > > 
> > > > You also likely want to use `.+` to make sure there is actually a 
> > > > character in there.
> > > > 
> > > > 
> > > I'm trying to show i is captured by value and j isn't
> > Hmm... I don't think it is testing what you think you're testing, 
> > particularly with so many unnamed checks.  If you send me the IR that this 
> > produces and highlight which are the 'important' lines, I can help write 
> > this for you.
> To be perfectly honest, I'm neither confident about which lines are 
> important, nor whether the test case is as meaningful as it can be.
> I'm happy to mail you the IR if you have time to look at it :)
Yep, feel free, I'll take a look when I get a chance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122768

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


[PATCH] D130750: [Clang] Do not check for underscores in isAllowedInitiallyIDChar

2022-07-29 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann accepted this revision.
tahonermann added a comment.

LGTM, thanks Corentin.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130750

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


[clang] ad16268 - [Clang] Do not check for underscores in isAllowedInitiallyIDChar

2022-07-29 Thread Corentin Jabot via cfe-commits

Author: Corentin Jabot
Date: 2022-07-29T17:46:38+02:00
New Revision: ad16268f135001bd21a805ae8acf8d8243793984

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

LOG: [Clang] Do not check for underscores in isAllowedInitiallyIDChar

isAllowedInitiallyIDChar is only used with non-ASCII codepoints,
which are handled by isAsciiIdentifierStart.
To make that clearer, remove the check for _ from
isAllowedInitiallyIDChar, and assert on ASCII - to ensure neither
_ or $ are passed to this function.

Reviewed By: tahonermann, aaron.ballman

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

Added: 


Modified: 
clang/lib/Lex/Lexer.cpp

Removed: 




diff  --git a/clang/lib/Lex/Lexer.cpp b/clang/lib/Lex/Lexer.cpp
index a4cff403e739c..6c1c55fc703fc 100644
--- a/clang/lib/Lex/Lexer.cpp
+++ b/clang/lib/Lex/Lexer.cpp
@@ -1483,13 +1483,13 @@ static bool isAllowedIDChar(uint32_t C, const 
LangOptions &LangOpts) {
 }
 
 static bool isAllowedInitiallyIDChar(uint32_t C, const LangOptions &LangOpts) {
+  assert(C > 0x7F && "isAllowedInitiallyIDChar called with an ASCII 
codepoint");
   if (LangOpts.AsmPreprocessor) {
 return false;
   }
   if (LangOpts.CPlusPlus || LangOpts.C2x) {
 static const llvm::sys::UnicodeCharSet XIDStartChars(XIDStartRanges);
-// '_' doesn't have the XID_Start property but is allowed in C++.
-return C == '_' || XIDStartChars.contains(C);
+return XIDStartChars.contains(C);
   }
   if (!isAllowedIDChar(C, LangOpts))
 return false;



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


[PATCH] D130750: [Clang] Do not check for underscores in isAllowedInitiallyIDChar

2022-07-29 Thread Corentin Jabot via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGad16268f1350: [Clang] Do not check for underscores in 
isAllowedInitiallyIDChar (authored by cor3ntin).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130750

Files:
  clang/lib/Lex/Lexer.cpp


Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -1483,13 +1483,13 @@
 }
 
 static bool isAllowedInitiallyIDChar(uint32_t C, const LangOptions &LangOpts) {
+  assert(C > 0x7F && "isAllowedInitiallyIDChar called with an ASCII 
codepoint");
   if (LangOpts.AsmPreprocessor) {
 return false;
   }
   if (LangOpts.CPlusPlus || LangOpts.C2x) {
 static const llvm::sys::UnicodeCharSet XIDStartChars(XIDStartRanges);
-// '_' doesn't have the XID_Start property but is allowed in C++.
-return C == '_' || XIDStartChars.contains(C);
+return XIDStartChars.contains(C);
   }
   if (!isAllowedIDChar(C, LangOpts))
 return false;


Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -1483,13 +1483,13 @@
 }
 
 static bool isAllowedInitiallyIDChar(uint32_t C, const LangOptions &LangOpts) {
+  assert(C > 0x7F && "isAllowedInitiallyIDChar called with an ASCII codepoint");
   if (LangOpts.AsmPreprocessor) {
 return false;
   }
   if (LangOpts.CPlusPlus || LangOpts.C2x) {
 static const llvm::sys::UnicodeCharSet XIDStartChars(XIDStartRanges);
-// '_' doesn't have the XID_Start property but is allowed in C++.
-return C == '_' || XIDStartChars.contains(C);
+return XIDStartChars.contains(C);
   }
   if (!isAllowedIDChar(C, LangOpts))
 return false;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130735: [Clang][LLD][cmake] Drop deprecated support for `llvm-config`-based build

2022-07-29 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd accepted this revision.
compnerd added a comment.
This revision is now accepted and ready to land.

Since it has been deprecated for 2 releases, it seems reasonable to cleanup.  
This seems good to me from the build side, please do wait a bit for anyone else 
to chime in on this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130735

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


[PATCH] D130750: [Clang] Do not check for underscores in isAllowedInitiallyIDChar

2022-07-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added a comment.

Thank you both!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130750

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


[PATCH] D130058: [Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values

2022-07-29 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Hello, this breaks a bunch of existing code over here (and I imagine elsewhere).

Can we make this a warning that's mapped to an error by default, so that people 
can turn it off for a while while they fix their code?


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

https://reviews.llvm.org/D130058

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


[PATCH] D130058: [Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values

2022-07-29 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:55-57
+- Clang will now correctly diagnose as ill-formed a constant expression where 
an
+  enum without a fixed underlying type is set to a value outside the range of
+  of the enumerations values. Fixes

Nit: "of of" and need for possessive quote; "enumeration's values".


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

https://reviews.llvm.org/D130058

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


[PATCH] D127403: [clangd] Implement semantic token modifier "definition"

2022-07-29 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler updated this revision to Diff 448655.
ckandeler added a comment.

Addressed remaining Objective-C issues


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127403

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/test/semantic-tokens.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
  clang-tools-extra/clangd/unittests/tweaks/AnnotateHighlightingsTests.cpp

Index: clang-tools-extra/clangd/unittests/tweaks/AnnotateHighlightingsTests.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/AnnotateHighlightingsTests.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/AnnotateHighlightingsTests.cpp
@@ -18,18 +18,18 @@
 TEST_F(AnnotateHighlightingsTest, Test) {
   EXPECT_AVAILABLE("^vo^id^ ^f(^) {^}^"); // available everywhere.
   EXPECT_AVAILABLE("[[int a; int b;]]");
-  EXPECT_EQ("void /* Function [decl] [globalScope] */f() {}",
+  EXPECT_EQ("void /* Function [decl] [def] [globalScope] */f() {}",
 apply("void ^f() {}"));
 
   EXPECT_EQ(apply("[[int f1(); const int x = f1();]]"),
 "int /* Function [decl] [globalScope] */f1(); "
-"const int /* Variable [decl] [readonly] [fileScope] */x = "
+"const int /* Variable [decl] [def] [readonly] [fileScope] */x = "
 "/* Function [globalScope] */f1();");
 
   // Only the targeted range is annotated.
   EXPECT_EQ(apply("void f1(); void f2() {^}"),
 "void f1(); "
-"void /* Function [decl] [globalScope] */f2() {}");
+"void /* Function [decl] [def] [globalScope] */f2() {}");
 }
 
 } // namespace
Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -97,52 +97,52 @@
 TEST(SemanticHighlighting, GetsCorrectTokens) {
   const char *TestCases[] = {
   R"cpp(
-  struct $Class_decl[[AS]] {
+  struct $Class_decl_def[[AS]] {
 double $Field_decl[[SomeMember]];
   };
   struct {
-  } $Variable_decl[[S]];
-  void $Function_decl[[foo]](int $Parameter_decl[[A]], $Class[[AS]] $Parameter_decl[[As]]) {
-$Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_decl[[VeryLongVariableName]] = 12312;
-$Class[[AS]] $LocalVariable_decl[[AA]];
-$Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_decl[[L]] = $LocalVariable[[AA]].$Field[[SomeMember]] + $Parameter[[A]];
-auto $LocalVariable_decl[[FN]] = [ $LocalVariable[[AA]]](int $Parameter_decl[[A]]) -> void {};
+  } $Variable_decl_def[[S]];
+  void $Function_decl_def[[foo]](int $Parameter_decl[[A]], $Class[[AS]] $Parameter_decl[[As]]) {
+$Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_decl_def[[VeryLongVariableName]] = 12312;
+$Class[[AS]] $LocalVariable_decl_def[[AA]];
+$Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_decl_def[[L]] = $LocalVariable[[AA]].$Field[[SomeMember]] + $Parameter[[A]];
+auto $LocalVariable_decl_def[[FN]] = [ $LocalVariable[[AA]]](int $Parameter_decl[[A]]) -> void {};
 $LocalVariable[[FN]](12312);
   }
 )cpp",
   R"cpp(
   void $Function_decl[[foo]](int);
   void $Function_decl[[Gah]]();
-  void $Function_decl[[foo]]() {
-auto $LocalVariable_decl[[Bou]] = $Function[[Gah]];
+  void $Function_decl_def[[foo]]() {
+auto $LocalVariable_decl_def[[Bou]] = $Function[[Gah]];
   }
-  struct $Class_decl[[A]] {
+  struct $Class_decl_def[[A]] {
 void $Method_decl[[abc]]();
   };
 )cpp",
   R"cpp(
   namespace $Namespace_decl[[abc]] {
 template
-struct $Class_decl[[A]] {
+struct $Class_decl_def[[A]] {
   $TemplateParameter[[T]] $Field_decl[[t]];
 };
   }
   template
-  struct $Class_decl[[C]] : $Namespace[[abc]]::$Class[[A]]<$TemplateParameter[[T]]> {
+  struct $Class_decl_def[[C]] : $Namespace[[abc]]::$Class[[A]]<$TemplateParameter[[T]]> {
 typename $TemplateParameter[[T]]::$Type_dependentName[[A]]* $Field_decl[[D]];
   };
-  $Namespace[[abc]]::$Class[[A]] $Variable_decl[[AA]];
+  $Namespace[[abc]]::$Class[[A]] $Variable_decl_def[[AA]];
   typedef $Namespace[[abc]]::$Class[[A]] $Class_decl[[AAA]];
-  struct $Class_decl[[B]] {
+  struct $Class_decl_def[[B]] {
 $Class_decl[[B]]();
 ~$Class[[B]](); // FIXME: inconsistent with constructor
 void operator<<($Class[[B]]);
 $Class[[AAA]] $Field_decl[[AA]];
   };
-  $Class[[B]]::$Class_decl[[B]]() {}
+  $Class[[B]]::

[PATCH] D130726: [clang][dataflow] Handle multiple context-sensitive calls to the same function

2022-07-29 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun accepted this revision.
xazax.hun added a comment.
This revision is now accepted and ready to land.

I'd love to see some comments in the source code to make sure one will not sue 
these facilities for other purposes that this was not designed to do. 
Alternatively, `ContextSensitive` option could be renamed to 
`NonRecursiveContextSensitive`.




Comment at: clang/lib/Analysis/FlowSensitive/Transfer.cpp:512-513
   // have the callee body available in the translation unit.
   if (!Options.ContextSensitive || F->getBody() == nullptr)
 return;
 

Since we do not support recursion (and only do inlining with the depth of one), 
I think we should have a check here to avoid a inlining recursive call. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130726

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


[PATCH] D54943: [clang-tidy] implement new check 'misc-const-correctness' to add 'const' to unmodified variables

2022-07-29 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added a comment.

In D54943#3681527 , @sammccall wrote:

> This check is enabled by default in LLVM (`Checks: misc-*` in 
> `llvm-project/.clang-tidy`)
>
> The warning on mutable non-ref local variables is pretty noisy: a *lot* of 
> existing code does not do this, for defensible reasons (some of us think that 
> the ratio of extra safety to extra syntactic noise for locals is too low). 
> The LLVM style guide doesn't take a position on this.
>
> Should this check
>
> - be disabled for LLVM? (i.e. this is opt-in for codebases with strong 
> const-correctness rules, LLVM does not, it was unintentionally enabled by 
> `misc-*`)
> - be configured only to warn on references? (i.e. we expect that is de-facto 
> LLVM style and so uncontroversial)

IMHO just enable for references in LLVM, thats still enough warnings to take a 
while to process and the guide is clear on that.
If the community wants it for values as well, that can be done later anyway.

Do you think the defaults for this check should change? Originally, it was 
"default on" because `cppcoreguidelines` state so.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D54943

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


[PATCH] D130224: [Clang][Attribute] Introduce maybe_undef attribute for function arguments which accepts undef values

2022-07-29 Thread Amy Kwan via Phabricator via cfe-commits
amyk added a comment.

In D130224#3687487 , @mubarizafzal 
wrote:

> Hi, the test cases that this patch introduces are failing on some ppc64le 
> (Linux on Power) buildbots:
> https://lab.llvm.org/buildbot/#/builders/57
> https://lab.llvm.org/buildbot/#/builders/230
>
> Would you mind taking a look please?

Thanks for pinging this patch. It appears it's affecting both little endian PPC:
https://lab.llvm.org/buildbot/#/builders/230/builds/1079
https://lab.llvm.org/buildbot/#/builders/121/builds/21978
https://lab.llvm.org/buildbot/#/builders/57/builds/20484
https://lab.llvm.org/buildbot/#/builders/36/builds/23702

And big endian PPC bots:
https://lab.llvm.org/buildbot/#/builders/231/builds/842
https://lab.llvm.org/buildbot/#/builders/93/builds/10270


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130224

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


[PATCH] D130058: [Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values

2022-07-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D130058#3687680 , @thakis wrote:

> Hello, this breaks a bunch of existing code over here (and I imagine 
> elsewhere).

Do you have an idea on how much a bunch is and whether the fixes are 
particularly involved or not? Did it break a system header?

> Can we make this a warning that's mapped to an error by default, so that 
> people can turn it off for a while while they fix their code?

It might be possible to do that, but I'd like to better understand the 
situation before we make a decision. This was fixing an accepts-invalid bug in 
Clang and we usually don't turn that into a warning-as-error unless there's a 
significant amount of code to be fixed in the ecosystem (like implicit int 
being accepted for a decade+ even when it was "wrong" for compilers to do so). 
However, Clang is the first compiler to actually get this particular behavior 
right, so I am sympathetic to turning it into a warning that defaults to an 
error.


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

https://reviews.llvm.org/D130058

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


[clang] d8352ab - Diagnose use of _Noreturn on a struct/union field

2022-07-29 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2022-07-29T13:18:44-04:00
New Revision: d8352abd3a4f411828dbe46c7dfd3e935ab4dd4a

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

LOG: Diagnose use of _Noreturn on a struct/union field

C99 6.7.4p2 clarifies that a function specifier can only be used in the
declaration of a function. _Noreturn is a function specifier, so it is
a constraint violation to write it on a structure or union field, but
we missed that case.

Fixes #56800

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Parse/ParseDecl.cpp
clang/test/Parser/c11-noreturn.c

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 871c434d67ee3..3d72bf8f6521c 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -52,7 +52,9 @@ Bug Fixes
 - ``-Wtautological-compare`` missed warnings for tautological comparisons
   involving a negative integer literal. This fixes
   `Issue 42918 `_.
-
+- Fixes an accepts-invalid bug in C when using a ``_Noreturn`` function
+  specifier on something other than a function declaration. This fixes
+  `Issue 56800 `_.
 
 Improvements to Clang's diagnostics
 ^^^

diff  --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index aef9909a7c971..fa19c6a0cbfa4 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -2599,6 +2599,8 @@ void Parser::ParseSpecifierQualifierList(DeclSpec &DS, 
AccessSpecifier AS,
   Diag(DS.getVirtualSpecLoc(), diag::err_typename_invalid_functionspec);
 if (DS.hasExplicitSpecifier())
   Diag(DS.getExplicitSpecLoc(), diag::err_typename_invalid_functionspec);
+if (DS.isNoreturnSpecified())
+  Diag(DS.getNoreturnSpecLoc(), diag::err_typename_invalid_functionspec);
 DS.ClearFunctionSpecs();
   }
 

diff  --git a/clang/test/Parser/c11-noreturn.c 
b/clang/test/Parser/c11-noreturn.c
index 0ce883ea43e36..5562a9412b5a7 100644
--- a/clang/test/Parser/c11-noreturn.c
+++ b/clang/test/Parser/c11-noreturn.c
@@ -15,4 +15,15 @@ _Noreturn int; // expected-error {{'_Noreturn' can only 
appear on functions}} ex
 _Noreturn struct S; // expected-error {{'_Noreturn' can only appear on 
functions}}
 _Noreturn enum E { e }; // expected-error {{'_Noreturn' can only appear on 
functions}}
 
+struct GH56800 {
+  _Noreturn int f1; // expected-error {{type name does not allow function 
specifier to be specified}}
+};
+
+_Noreturn int AlsoBad; // expected-error {{'_Noreturn' can only appear on 
functions}}
+void func(_Noreturn int ThisToo) { // expected-error {{'_Noreturn' can only 
appear on functions}}
+  for (_Noreturn int i = 0; i < 10; ++i) // expected-error {{'_Noreturn' can 
only appear on functions}}
+;
+}
+
+
 // CHECK-EXT: '_Noreturn' is a C11 extension



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


[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

2022-07-29 Thread Jeff Niu via Phabricator via cfe-commits
Mogball accepted this revision.
Mogball added a comment.
This revision is now accepted and ready to land.

Got a few small nits but otherwise LGTM. Thanks for all the hard work! This 
looks really solid now. I haven't thought too hard about the performance of 
that while loop but it seems good enough to land for now.




Comment at: mlir/lib/Transforms/Utils/CommutativityUtils.cpp:246
+// `constCommOperandA`'s "key" is smaller.
+auto CommutativeOperandComparator =
+[](const std::unique_ptr &constCommOperandA,





Comment at: mlir/lib/Transforms/Utils/CommutativityUtils.cpp:252
+
+  std::unique_ptr &commOperandA =
+  const_cast &>(





Comment at: mlir/lib/Transforms/Utils/CommutativityUtils.cpp:255
+  constCommOperandA);
+  std::unique_ptr &commOperandB =
+  const_cast &>(




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

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


[clang] 4191d66 - [clang-repl] Disable execution unittests on unsupported platforms.

2022-07-29 Thread Sunho Kim via cfe-commits

Author: Sunho Kim
Date: 2022-07-30T02:28:03+09:00
New Revision: 4191d661c74622c6fa72c1643e4567f45e6c9e1b

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

LOG: [clang-repl] Disable execution unittests on unsupported platforms.

After the intoduction of global destructor support, there is a possiblity to 
run invalid instructions in the destructor of Interpreter class. Completely 
disable tests in platforms with failing test cases.

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

Added: 


Modified: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
clang/unittests/Interpreter/InterpreterTest.cpp

Removed: 




diff  --git 
a/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp 
b/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
index 7a5f07e25bc6f..d827c915e070f 100644
--- a/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ b/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -46,6 +46,7 @@ createInterpreter(const Args &ExtraArgs = {},
 }
 
 TEST(InterpreterTest, CatchException) {
+  llvm::llvm_shutdown_obj Y; // Call llvm_shutdown() on exit.
   llvm::InitializeNativeTarget();
   llvm::InitializeNativeTargetAsmPrinter();
 
@@ -130,8 +131,6 @@ extern "C" int throw_exception() {
   EXPECT_ANY_THROW(ThrowException());
   std::string CapturedStdOut = testing::internal::GetCapturedStdout();
   EXPECT_EQ(CapturedStdOut, "Caught: 'To be caught in JIT'\n");
-
-  llvm::llvm_shutdown();
 }
 
 } // end anonymous namespace

diff  --git a/clang/unittests/Interpreter/InterpreterTest.cpp 
b/clang/unittests/Interpreter/InterpreterTest.cpp
index 745e36071936a..d266dd0c0c768 100644
--- a/clang/unittests/Interpreter/InterpreterTest.cpp
+++ b/clang/unittests/Interpreter/InterpreterTest.cpp
@@ -28,6 +28,12 @@
 
 using namespace clang;
 
+#if defined(_AIX) || defined(__hexagon__) ||   
\
+(defined(_WIN32) &&
\
+ (defined(__aarch64__) || defined(_M_ARM64) || defined(__arm__)))
+#define CLANG_INTERPRETER_NO_SUPPORT_EXEC
+#endif
+
 namespace {
 using Args = std::vector;
 static std::unique_ptr
@@ -191,7 +197,7 @@ struct LLVMInitRAII {
   ~LLVMInitRAII() { llvm::llvm_shutdown(); }
 } LLVMInit;
 
-#ifdef _AIX
+#ifdef CLANG_INTERPRETER_NO_SUPPORT_EXEC
 TEST(IncrementalProcessing, DISABLED_FindMangledNameSymbol) {
 #else
 TEST(IncrementalProcessing, FindMangledNameSymbol) {
@@ -253,7 +259,7 @@ static NamedDecl *LookupSingleName(Interpreter &Interp, 
const char *Name) {
   return R.getFoundDecl();
 }
 
-#ifdef _AIX
+#ifdef CLANG_INTERPRETER_NO_SUPPORT_EXEC
 TEST(IncrementalProcessing, DISABLED_InstantiateTemplate) {
 #else
 TEST(IncrementalProcessing, InstantiateTemplate) {



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


[PATCH] D130786: [clang-repl] Disable execution unittests on unsupported platforms.

2022-07-29 Thread Sunho Kim via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4191d661c746: [clang-repl] Disable execution unittests on 
unsupported platforms. (authored by sunho).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130786

Files:
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp


Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -28,6 +28,12 @@
 
 using namespace clang;
 
+#if defined(_AIX) || defined(__hexagon__) ||   
\
+(defined(_WIN32) &&
\
+ (defined(__aarch64__) || defined(_M_ARM64) || defined(__arm__)))
+#define CLANG_INTERPRETER_NO_SUPPORT_EXEC
+#endif
+
 namespace {
 using Args = std::vector;
 static std::unique_ptr
@@ -191,7 +197,7 @@
   ~LLVMInitRAII() { llvm::llvm_shutdown(); }
 } LLVMInit;
 
-#ifdef _AIX
+#ifdef CLANG_INTERPRETER_NO_SUPPORT_EXEC
 TEST(IncrementalProcessing, DISABLED_FindMangledNameSymbol) {
 #else
 TEST(IncrementalProcessing, FindMangledNameSymbol) {
@@ -253,7 +259,7 @@
   return R.getFoundDecl();
 }
 
-#ifdef _AIX
+#ifdef CLANG_INTERPRETER_NO_SUPPORT_EXEC
 TEST(IncrementalProcessing, DISABLED_InstantiateTemplate) {
 #else
 TEST(IncrementalProcessing, InstantiateTemplate) {
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -46,6 +46,7 @@
 }
 
 TEST(InterpreterTest, CatchException) {
+  llvm::llvm_shutdown_obj Y; // Call llvm_shutdown() on exit.
   llvm::InitializeNativeTarget();
   llvm::InitializeNativeTargetAsmPrinter();
 
@@ -130,8 +131,6 @@
   EXPECT_ANY_THROW(ThrowException());
   std::string CapturedStdOut = testing::internal::GetCapturedStdout();
   EXPECT_EQ(CapturedStdOut, "Caught: 'To be caught in JIT'\n");
-
-  llvm::llvm_shutdown();
 }
 
 } // end anonymous namespace


Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -28,6 +28,12 @@
 
 using namespace clang;
 
+#if defined(_AIX) || defined(__hexagon__) ||   \
+(defined(_WIN32) &&\
+ (defined(__aarch64__) || defined(_M_ARM64) || defined(__arm__)))
+#define CLANG_INTERPRETER_NO_SUPPORT_EXEC
+#endif
+
 namespace {
 using Args = std::vector;
 static std::unique_ptr
@@ -191,7 +197,7 @@
   ~LLVMInitRAII() { llvm::llvm_shutdown(); }
 } LLVMInit;
 
-#ifdef _AIX
+#ifdef CLANG_INTERPRETER_NO_SUPPORT_EXEC
 TEST(IncrementalProcessing, DISABLED_FindMangledNameSymbol) {
 #else
 TEST(IncrementalProcessing, FindMangledNameSymbol) {
@@ -253,7 +259,7 @@
   return R.getFoundDecl();
 }
 
-#ifdef _AIX
+#ifdef CLANG_INTERPRETER_NO_SUPPORT_EXEC
 TEST(IncrementalProcessing, DISABLED_InstantiateTemplate) {
 #else
 TEST(IncrementalProcessing, InstantiateTemplate) {
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -46,6 +46,7 @@
 }
 
 TEST(InterpreterTest, CatchException) {
+  llvm::llvm_shutdown_obj Y; // Call llvm_shutdown() on exit.
   llvm::InitializeNativeTarget();
   llvm::InitializeNativeTargetAsmPrinter();
 
@@ -130,8 +131,6 @@
   EXPECT_ANY_THROW(ThrowException());
   std::string CapturedStdOut = testing::internal::GetCapturedStdout();
   EXPECT_EQ(CapturedStdOut, "Caught: 'To be caught in JIT'\n");
-
-  llvm::llvm_shutdown();
 }
 
 } // end anonymous namespace
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130224: [Clang][Attribute] Introduce maybe_undef attribute for function arguments which accepts undef values

2022-07-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D130224#3687860 , @amyk wrote:

> In D130224#3687487 , @mubarizafzal 
> wrote:
>
>> Hi, the test cases that this patch introduces are failing on some ppc64le 
>> (Linux on Power) buildbots:
>> https://lab.llvm.org/buildbot/#/builders/57
>> https://lab.llvm.org/buildbot/#/builders/230
>>
>> Would you mind taking a look please?
>
> Thanks for pinging this patch. It appears it's affecting both little endian 
> PPC:
> https://lab.llvm.org/buildbot/#/builders/230/builds/1079
> https://lab.llvm.org/buildbot/#/builders/121/builds/21978
> https://lab.llvm.org/buildbot/#/builders/57/builds/20484
> https://lab.llvm.org/buildbot/#/builders/36/builds/23702
>
> And big endian PPC bots:
> https://lab.llvm.org/buildbot/#/builders/231/builds/842
> https://lab.llvm.org/buildbot/#/builders/93/builds/10270

If we don't hear from @skc7 in the next ~hour with a fix, feel free to revert 
to get the bots back to green.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130224

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


[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

2022-07-29 Thread Mehdi AMINI via Phabricator via cfe-commits
mehdi_amini added a comment.

> . I haven't thought too hard about the performance of that while loop but it 
> seems good enough to land for now.

What's the finality of it? That is: outside of canonicalization what is its 
purpose?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

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


[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

2022-07-29 Thread Jeff Niu via Phabricator via cfe-commits
Mogball added a comment.

I'm referring to the nitty gritty details of the while loop inside the 
comparator. It looks pretty tight to me right now. If the operands are already 
sorted, worst-case each operand is compared against only its neighbours. 
Unfortunately, without extra bookkeeping, BFS will still need to iterate when 
necessary


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

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


[PATCH] D129242: [clang-repl] Add host exception support check utility flag.

2022-07-29 Thread Sunho Kim via Phabricator via cfe-commits
sunho added a comment.

@uabelho The thing is we have to statically link libstdc++ in JIT stack, but 
this is not possible at the moment in many platforms. It's actually possible 
with a new generation linker called JITLink, but it has limited platform 
support. For now, I just sumbitted a patch disabling clang-repl build when 
LLVM_STATIC_LINK_CXX_STDLIB is turned on. This should resolve the build failure 
on your side. If you want to use clang-repl on your environment, it's actually 
possible to statically link libstdc++ on JIT side as JITLink is available on 
x86 linux. Please let me if you want me to dig into it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129242

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


[PATCH] D129242: [clang-repl] Add host exception support check utility flag.

2022-07-29 Thread Sunho Kim via Phabricator via cfe-commits
sunho added a comment.

https://reviews.llvm.org/D130788 this is the patch fyi.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129242

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


[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

2022-07-29 Thread Srishti Srivastava via Phabricator via cfe-commits
srishti-pm updated this revision to Diff 448682.
srishti-pm marked 3 inline comments as done.
srishti-pm added a comment.

Addressed the final NITs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

Files:
  mlir/include/mlir/Transforms/CommutativityUtils.h
  mlir/lib/Transforms/Utils/CMakeLists.txt
  mlir/lib/Transforms/Utils/CommutativityUtils.cpp
  mlir/test/Transforms/test-commutativity-utils.mlir
  mlir/test/lib/Dialect/Test/TestOps.td
  mlir/test/lib/Transforms/CMakeLists.txt
  mlir/test/lib/Transforms/TestCommutativityUtils.cpp
  mlir/tools/mlir-opt/mlir-opt.cpp

Index: mlir/tools/mlir-opt/mlir-opt.cpp
===
--- mlir/tools/mlir-opt/mlir-opt.cpp
+++ mlir/tools/mlir-opt/mlir-opt.cpp
@@ -57,6 +57,7 @@
 void registerVectorizerTestPass();
 
 namespace test {
+void registerCommutativityUtils();
 void registerConvertCallOpPass();
 void registerInliner();
 void registerMemRefBoundCheck();
@@ -149,6 +150,7 @@
   registerVectorizerTestPass();
   registerTosaTestQuantUtilAPIPass();
 
+  mlir::test::registerCommutativityUtils();
   mlir::test::registerConvertCallOpPass();
   mlir::test::registerInliner();
   mlir::test::registerMemRefBoundCheck();
Index: mlir/test/lib/Transforms/TestCommutativityUtils.cpp
===
--- /dev/null
+++ mlir/test/lib/Transforms/TestCommutativityUtils.cpp
@@ -0,0 +1,48 @@
+//===- TestCommutativityUtils.cpp - Pass to test the commutativity utility-===//
+//
+// 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
+//
+//===--===//
+//
+// This pass tests the functionality of the commutativity utility pattern.
+//
+//===--===//
+
+#include "mlir/Transforms/CommutativityUtils.h"
+
+#include "TestDialect.h"
+#include "mlir/Pass/Pass.h"
+#include "mlir/Transforms/GreedyPatternRewriteDriver.h"
+
+using namespace mlir;
+
+namespace {
+
+struct CommutativityUtils
+: public PassWrapper> {
+  MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID(CommutativityUtils)
+
+  StringRef getArgument() const final { return "test-commutativity-utils"; }
+  StringRef getDescription() const final {
+return "Test the functionality of the commutativity utility";
+  }
+
+  void runOnOperation() override {
+auto func = getOperation();
+auto *context = &getContext();
+
+RewritePatternSet patterns(context);
+populateCommutativityUtilsPatterns(patterns);
+
+(void)applyPatternsAndFoldGreedily(func, std::move(patterns));
+  }
+};
+} // namespace
+
+namespace mlir {
+namespace test {
+void registerCommutativityUtils() { PassRegistration(); }
+} // namespace test
+} // namespace mlir
Index: mlir/test/lib/Transforms/CMakeLists.txt
===
--- mlir/test/lib/Transforms/CMakeLists.txt
+++ mlir/test/lib/Transforms/CMakeLists.txt
@@ -1,5 +1,6 @@
 # Exclude tests from libMLIR.so
 add_mlir_library(MLIRTestTransforms
+  TestCommutativityUtils.cpp
   TestConstantFold.cpp
   TestControlFlowSink.cpp
   TestInlining.cpp
Index: mlir/test/lib/Dialect/Test/TestOps.td
===
--- mlir/test/lib/Dialect/Test/TestOps.td
+++ mlir/test/lib/Dialect/Test/TestOps.td
@@ -1186,11 +1186,21 @@
   let hasFolder = 1;
 }
 
+def TestAddIOp : TEST_Op<"addi"> {
+  let arguments = (ins I32:$op1, I32:$op2);
+  let results = (outs I32);
+}
+
 def TestCommutativeOp : TEST_Op<"op_commutative", [Commutative]> {
   let arguments = (ins I32:$op1, I32:$op2, I32:$op3, I32:$op4);
   let results = (outs I32);
 }
 
+def TestLargeCommutativeOp : TEST_Op<"op_large_commutative", [Commutative]> {
+  let arguments = (ins I32:$op1, I32:$op2, I32:$op3, I32:$op4, I32:$op5, I32:$op6, I32:$op7);
+  let results = (outs I32);
+}
+
 def TestCommutative2Op : TEST_Op<"op_commutative2", [Commutative]> {
   let arguments = (ins I32:$op1, I32:$op2);
   let results = (outs I32);
Index: mlir/test/Transforms/test-commutativity-utils.mlir
===
--- /dev/null
+++ mlir/test/Transforms/test-commutativity-utils.mlir
@@ -0,0 +1,116 @@
+// RUN: mlir-opt %s -test-commutativity-utils | FileCheck %s
+
+// CHECK-LABEL: @test_small_pattern_1
+func.func @test_small_pattern_1(%arg0 : i32) -> i32 {
+  // CHECK-NEXT: %[[ARITH_CONST:.*]] = arith.constant
+  %0 = arith.constant 45 : i32
+
+  // CHECK-NEXT: %[[TEST_ADD:.*]] = "test.addi"
+  %1 = "test.addi"(%arg0, %arg0): (i32, i32) -> i32
+
+  // CHECK-NEXT: %[[ARITH_ADD:.*]] = arith.addi
+  %2 = arith.addi %arg0, %arg0 : i32
+
+  // CHECK-NEXT: %[[ARITH_MUL:.*]] = ar

[PATCH] D93138: Add initial support for multilibs in Baremetal toolchain.

2022-07-29 Thread Hafiz Abid Qadeer via Phabricator via cfe-commits
abidh added inline comments.



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:177
   if (!getDriver().SysRoot.empty())
-return getDriver().SysRoot;
+return getDriver().SysRoot + SelectedMultilib.osSuffix();
 

zixuan-wu wrote:
> I think the multilib osSuffix added here will make every multilib contain 
> include dir, and those include dirs are the same. For lib, there should be 
> different multilib dir. 
> 
> So it's better to add osSuffix at construction function like following I 
> think instead of be part of sysroot.
> 
> ```
> if (!SysRoot.empty()) {
> llvm::sys::path::append(SysRoot, "lib", SelectedMultilib.osSuffix());
> getFilePaths().push_back(std::string(SysRoot));
>   }
> ```
> 
> @abidh 
The multilib include directories are not necessarily the same.  In my opinion, 
having a separate include and lib directory for every multilib is much cleaner 
then having all multilib share an include directory and then you put multilib 
specific directories inside that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93138

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


[PATCH] D130786: [clang-repl] Disable execution unittests on unsupported platforms.

2022-07-29 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

If you're going to post a patch for review, you really should wait for someone 
to review it before you land it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130786

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


[PATCH] D130790: Fix failing tests for "[Clang][Attribute] Introduce maybe_undef attribute for function arguments which accepts undef values"

2022-07-29 Thread krishna chaitanya sankisa via Phabricator via cfe-commits
skc7 created this revision.
skc7 added reviewers: aaron.ballman, ronlieb, arsenm.
Herald added a subscriber: pengfei.
Herald added a project: All.
skc7 requested review of this revision.
Herald added subscribers: cfe-commits, wdng.
Herald added a project: clang.

Add target triple x86_64-gnu-linux for tests failing due to D130224 



Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130790

Files:
  clang/test/CodeGen/attr-maybeundef-template.cpp
  clang/test/CodeGen/attr-maybeundef.c


Index: clang/test/CodeGen/attr-maybeundef.c
===
--- clang/test/CodeGen/attr-maybeundef.c
+++ clang/test/CodeGen/attr-maybeundef.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -no-opaque-pointers -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-gnu-linux -emit-llvm %s 
-o - | FileCheck %s
 
 #define __maybe_undef __attribute__((maybe_undef))
 
Index: clang/test/CodeGen/attr-maybeundef-template.cpp
===
--- clang/test/CodeGen/attr-maybeundef-template.cpp
+++ clang/test/CodeGen/attr-maybeundef-template.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -no-opaque-pointers -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-gnu-linux -emit-llvm %s 
-o - | FileCheck %s
 
 // CHECK-LABEL: define{{.*}} void @{{.*}}test4{{.*}}(float
 // CHECK-NEXT:  entry:


Index: clang/test/CodeGen/attr-maybeundef.c
===
--- clang/test/CodeGen/attr-maybeundef.c
+++ clang/test/CodeGen/attr-maybeundef.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -no-opaque-pointers -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-gnu-linux -emit-llvm %s -o - | FileCheck %s
 
 #define __maybe_undef __attribute__((maybe_undef))
 
Index: clang/test/CodeGen/attr-maybeundef-template.cpp
===
--- clang/test/CodeGen/attr-maybeundef-template.cpp
+++ clang/test/CodeGen/attr-maybeundef-template.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -no-opaque-pointers -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-gnu-linux -emit-llvm %s -o - | FileCheck %s
 
 // CHECK-LABEL: define{{.*}} void @{{.*}}test4{{.*}}(float
 // CHECK-NEXT:  entry:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130786: [clang-repl] Disable execution unittests on unsupported platforms.

2022-07-29 Thread Sunho Kim via Phabricator via cfe-commits
sunho added a comment.

In D130786#3688019 , @probinson wrote:

> If you're going to post a patch for review, you really should wait for 
> someone to review it before you land it.

I rushed as bots were breaking on the upstream. Sorry about that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130786

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


[PATCH] D130224: [Clang][Attribute] Introduce maybe_undef attribute for function arguments which accepts undef values

2022-07-29 Thread krishna chaitanya sankisa via Phabricator via cfe-commits
skc7 added a comment.

In D130224#3687907 , @aaron.ballman 
wrote:

> In D130224#3687860 , @amyk wrote:
>
>> In D130224#3687487 , @mubarizafzal 
>> wrote:
>>
>>> Hi, the test cases that this patch introduces are failing on some ppc64le 
>>> (Linux on Power) buildbots:
>>> https://lab.llvm.org/buildbot/#/builders/57
>>> https://lab.llvm.org/buildbot/#/builders/230
>>>
>>> Would you mind taking a look please?
>>
>> Thanks for pinging this patch. It appears it's affecting both little endian 
>> PPC:
>> https://lab.llvm.org/buildbot/#/builders/230/builds/1079
>> https://lab.llvm.org/buildbot/#/builders/121/builds/21978
>> https://lab.llvm.org/buildbot/#/builders/57/builds/20484
>> https://lab.llvm.org/buildbot/#/builders/36/builds/23702
>>
>> And big endian PPC bots:
>> https://lab.llvm.org/buildbot/#/builders/231/builds/842
>> https://lab.llvm.org/buildbot/#/builders/93/builds/10270
>
> If we don't hear from @skc7 in the next ~hour with a fix, feel free to revert 
> to get the bots back to green.

Issue is with missing target triple in the tests. Submitted D130790 
 for review, which should fix the tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130224

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


[clang] 4e1fe96 - Revert "[Clang][Attribute] Introduce maybe_undef attribute for function arguments which accepts undef values"

2022-07-29 Thread Amy Kwan via cfe-commits

Author: Amy Kwan
Date: 2022-07-29T13:28:48-05:00
New Revision: 4e1fe968c9de73507a1bf0c8aa57e06be457816e

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

LOG: Revert "[Clang][Attribute] Introduce maybe_undef attribute for function 
arguments which accepts undef values"

This reverts commit a35c64ce23b7c7e4972c89b224b9363639dddea2.

Reverting this commit as it causes various failures on LE and BE PPC bots.

Added: 


Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/lib/CodeGen/CGCall.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/Misc/pragma-attribute-supported-attributes-list.test

Removed: 
clang/test/CodeGen/attr-maybeundef-template.cpp
clang/test/CodeGen/attr-maybeundef.c
clang/test/CodeGenHIP/maybe_undef-attr-verify.hip
clang/test/Sema/attr-maybeundef.c



diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index a94829698ad91..0460371d26c94 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2023,13 +2023,6 @@ def NoEscape : Attr {
   let Documentation = [NoEscapeDocs];
 }
 
-def MaybeUndef : InheritableAttr {
-  let Spellings = [Clang<"maybe_undef">];
-  let Subjects = SubjectList<[ParmVar]>;
-  let Documentation = [MaybeUndefDocs];
-  let SimpleHandler = 1;
-}
-
 def AssumeAligned : InheritableAttr {
   let Spellings = [GCC<"assume_aligned">];
   let Subjects = SubjectList<[ObjCMethod, Function]>;

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index f61a5a8d5b523..5c84e2fc5b77d 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -257,28 +257,6 @@ applies to copies of the block. For example:
   }];
 }
 
-def MaybeUndefDocs : Documentation {
-  let Category = DocCatVariable;
-  let Content = [{
-The ``maybe_undef`` attribute can be placed on a function parameter. It 
indicates
-that the parameter is allowed to use undef values. It informs the compiler
-to insert a freeze LLVM IR instruction on the function parameter.
-Please note that this is an attribute that is used as an internal
-implementation detail and not intended to be used by external users.
-
-In languages HIP, CUDA etc., some functions have multi-threaded semantics and
-it is enough for only one or some threads to provide defined arguments.
-Depending on semantics, undef arguments in some threads don't produce
-undefined results in the function call. Since, these functions accept undefined
-arguments, ``maybe_undef`` attribute can be placed.
-
-Sample usage:
-.. code-block:: c
-
-  void maybeundeffunc(int __attribute__((maybe_undef))param);
-  }];
-}
-
 def CarriesDependencyDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{

diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index ee37e762dc759..7853695f1f0cb 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -2046,27 +2046,6 @@ static bool DetermineNoUndef(QualType QTy, CodeGenTypes 
&Types,
   return false;
 }
 
-/// Check if the argument of a function has maybe_undef attribute.
-static bool IsArgumentMaybeUndef(const Decl *TargetDecl,
- unsigned NumRequiredArgs, unsigned ArgNo) {
-  const auto *FD = dyn_cast_or_null(TargetDecl);
-  if (!FD)
-return false;
-
-  // Assume variadic arguments do not have maybe_undef attribute.
-  if (ArgNo >= NumRequiredArgs)
-return false;
-
-  // Check if argument has maybe_undef attribute.
-  if (ArgNo < FD->getNumParams()) {
-const ParmVarDecl *Param = FD->getParamDecl(ArgNo);
-if (Param && Param->hasAttr())
-  return true;
-  }
-
-  return false;
-}
-
 /// Construct the IR attribute list of a function or call.
 ///
 /// When adding an attribute, please consider where it should be handled:
@@ -4842,9 +4821,6 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo 
&CallInfo,
 unsigned FirstIRArg, NumIRArgs;
 std::tie(FirstIRArg, NumIRArgs) = IRFunctionArgs.getIRArgs(ArgNo);
 
-bool ArgHasMaybeUndefAttr =
-IsArgumentMaybeUndef(TargetDecl, CallInfo.getNumRequiredArgs(), ArgNo);
-
 switch (ArgInfo.getKind()) {
 case ABIArgInfo::InAlloca: {
   assert(NumIRArgs == 0);
@@ -4903,11 +4879,7 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo 
&CallInfo,
 // Make a temporary alloca to pass the argument.
 Address Addr = CreateMemTempWithoutCast(
 I->Ty, ArgInfo.getIndirectAlign(), "indirect-arg-temp");
-
-llvm::Value *Val = Addr.getPointer();
-if (ArgHasMaybeUndefAttr)
-  Val = Builder.CreateFreeze(Addr.getPointer());
-IRCallArgs[FirstIRArg] = Val;
+IRCallArgs[FirstIRArg] = 

[PATCH] D130058: [Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values

2022-07-29 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Here's a reduced repro of one case:

  % cat test.cc
  typedef enum VkResult {
  VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS = -1000257000,
  VK_RESULT_MAX_ENUM = 0x7FFF
  } VkResult;
  
  constexpr VkResult VK_FAKE_DEVICE_OOM_FOR_TESTING = 
static_cast(VK_RESULT_MAX_ENUM - 1);
  
  % out/gn/bin/clang -c test.cc -std=c++17
  test.cc:6:20: error: constexpr variable 'VK_FAKE_DEVICE_OOM_FOR_TESTING' must 
be initialized by a constant expression
  constexpr VkResult VK_FAKE_DEVICE_OOM_FOR_TESTING = 
static_cast(VK_RESULT_MAX_ENUM - 1);
 ^
~
  test.cc:6:53: note: integer value 2147483646 is outside the valid range of 
values [-2147483648, -2147483648) for this enumeration type
  constexpr VkResult VK_FAKE_DEVICE_OOM_FOR_TESTING = 
static_cast(VK_RESULT_MAX_ENUM - 1);
  ^
  1 error generated.

Isn't `valid range of values [-2147483648, -2147483648)` just wrong here?


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

https://reviews.llvm.org/D130058

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


[PATCH] D130224: [Clang][Attribute] Introduce maybe_undef attribute for function arguments which accepts undef values

2022-07-29 Thread Amy Kwan via Phabricator via cfe-commits
amyk added a comment.

In D130224#3687907 , @aaron.ballman 
wrote:

> In D130224#3687860 , @amyk wrote:
>
>> In D130224#3687487 , @mubarizafzal 
>> wrote:
>>
>>> Hi, the test cases that this patch introduces are failing on some ppc64le 
>>> (Linux on Power) buildbots:
>>> https://lab.llvm.org/buildbot/#/builders/57
>>> https://lab.llvm.org/buildbot/#/builders/230
>>>
>>> Would you mind taking a look please?
>>
>> Thanks for pinging this patch. It appears it's affecting both little endian 
>> PPC:
>> https://lab.llvm.org/buildbot/#/builders/230/builds/1079
>> https://lab.llvm.org/buildbot/#/builders/121/builds/21978
>> https://lab.llvm.org/buildbot/#/builders/57/builds/20484
>> https://lab.llvm.org/buildbot/#/builders/36/builds/23702
>>
>> And big endian PPC bots:
>> https://lab.llvm.org/buildbot/#/builders/231/builds/842
>> https://lab.llvm.org/buildbot/#/builders/93/builds/10270
>
> If we don't hear from @skc7 in the next ~hour with a fix, feel free to revert 
> to get the bots back to green.

Thanks @aaron.ballman. I've reverted the patch for the time being: 
https://reviews.llvm.org/rG4e1fe968c9de73507a1bf0c8aa57e06be457816e


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130224

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


[PATCH] D130224: [Clang][Attribute] Introduce maybe_undef attribute for function arguments which accepts undef values

2022-07-29 Thread Amy Kwan via Phabricator via cfe-commits
amyk added a comment.

In D130224#3688034 , @skc7 wrote:

> In D130224#3687907 , @aaron.ballman 
> wrote:
>
>> In D130224#3687860 , @amyk wrote:
>>
>>> In D130224#3687487 , 
>>> @mubarizafzal wrote:
>>>
 Hi, the test cases that this patch introduces are failing on some ppc64le 
 (Linux on Power) buildbots:
 https://lab.llvm.org/buildbot/#/builders/57
 https://lab.llvm.org/buildbot/#/builders/230

 Would you mind taking a look please?
>>>
>>> Thanks for pinging this patch. It appears it's affecting both little endian 
>>> PPC:
>>> https://lab.llvm.org/buildbot/#/builders/230/builds/1079
>>> https://lab.llvm.org/buildbot/#/builders/121/builds/21978
>>> https://lab.llvm.org/buildbot/#/builders/57/builds/20484
>>> https://lab.llvm.org/buildbot/#/builders/36/builds/23702
>>>
>>> And big endian PPC bots:
>>> https://lab.llvm.org/buildbot/#/builders/231/builds/842
>>> https://lab.llvm.org/buildbot/#/builders/93/builds/10270
>>
>> If we don't hear from @skc7 in the next ~hour with a fix, feel free to 
>> revert to get the bots back to green.
>
> Issue is with missing target triple in the tests. Submitted D130790 
>  for review, which should fix the tests.

I realized I didn't happen to see this comment in time and had already reverted 
the patch. My apologies on this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130224

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


[PATCH] D130791: [clang] Short-circuit trivial constexpr array constructors

2022-07-29 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder created this revision.
tbaeder added reviewers: aaron.ballman, rsmith.
Herald added a project: All.
tbaeder requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

As discussed in https://github.com/llvm/llvm-project/issues/56774


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130791

Files:
  clang/lib/AST/ExprConstant.cpp


Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -10833,6 +10833,9 @@
 if (FinalSize == 0)
   return true;
 
+bool HasTrivialConstructor = CheckTrivialDefaultConstructor(
+Info, E->getExprLoc(), E->getConstructor(),
+E->requiresZeroInitialization());
 LValue ArrayElt = Subobject;
 ArrayElt.addArray(Info, E, CAT);
 // We do the whole initialization in two passes, first for just one 
element,
@@ -10856,19 +10859,26 @@
 for (unsigned I = OldElts; I < N; ++I)
   Value->getArrayInitializedElt(I) = Filler;
 
-  // Initialize the elements.
-  for (unsigned I = OldElts; I < N; ++I) {
-if (!VisitCXXConstructExpr(E, ArrayElt,
-   &Value->getArrayInitializedElt(I),
-   CAT->getElementType()) ||
-!HandleLValueArrayAdjustment(Info, E, ArrayElt,
- CAT->getElementType(), 1))
-  return false;
-// When checking for const initilization any diagnostic is considered
-// an error.
-if (Info.EvalStatus.Diag && !Info.EvalStatus.Diag->empty() &&
-!Info.keepEvaluatingAfterFailure())
-  return false;
+  if (HasTrivialConstructor && N == FinalSize) {
+// If we have a trivial constructor, only evaluate it once and copy
+// the result into all the array elements.
+APValue &FirstResult = Value->getArrayInitializedElt(0);
+for (unsigned I = OldElts; I < FinalSize; ++I)
+  Value->getArrayInitializedElt(I) = FirstResult;
+  } else {
+for (unsigned I = OldElts; I < N; ++I) {
+  if (!VisitCXXConstructExpr(E, ArrayElt,
+ &Value->getArrayInitializedElt(I),
+ CAT->getElementType()) ||
+  !HandleLValueArrayAdjustment(Info, E, ArrayElt,
+   CAT->getElementType(), 1))
+return false;
+  // When checking for const initilization any diagnostic is considered
+  // an error.
+  if (Info.EvalStatus.Diag && !Info.EvalStatus.Diag->empty() &&
+  !Info.keepEvaluatingAfterFailure())
+return false;
+}
   }
 }
 


Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -10833,6 +10833,9 @@
 if (FinalSize == 0)
   return true;
 
+bool HasTrivialConstructor = CheckTrivialDefaultConstructor(
+Info, E->getExprLoc(), E->getConstructor(),
+E->requiresZeroInitialization());
 LValue ArrayElt = Subobject;
 ArrayElt.addArray(Info, E, CAT);
 // We do the whole initialization in two passes, first for just one element,
@@ -10856,19 +10859,26 @@
 for (unsigned I = OldElts; I < N; ++I)
   Value->getArrayInitializedElt(I) = Filler;
 
-  // Initialize the elements.
-  for (unsigned I = OldElts; I < N; ++I) {
-if (!VisitCXXConstructExpr(E, ArrayElt,
-   &Value->getArrayInitializedElt(I),
-   CAT->getElementType()) ||
-!HandleLValueArrayAdjustment(Info, E, ArrayElt,
- CAT->getElementType(), 1))
-  return false;
-// When checking for const initilization any diagnostic is considered
-// an error.
-if (Info.EvalStatus.Diag && !Info.EvalStatus.Diag->empty() &&
-!Info.keepEvaluatingAfterFailure())
-  return false;
+  if (HasTrivialConstructor && N == FinalSize) {
+// If we have a trivial constructor, only evaluate it once and copy
+// the result into all the array elements.
+APValue &FirstResult = Value->getArrayInitializedElt(0);
+for (unsigned I = OldElts; I < FinalSize; ++I)
+  Value->getArrayInitializedElt(I) = FirstResult;
+  } else {
+for (unsigned I = OldElts; I < N; ++I) {
+  if (!VisitCXXConstructExpr(E, ArrayElt,
+ &Value->getArrayInitializedElt(I),
+ CAT->getElementType()) ||
+  !HandleLValueArrayAdjustment(Info, E, ArrayElt,
+   CAT->getElementType(), 1))
+return false;
+  // When checking f

[PATCH] D130363: [clang] Give priority to Class context while parsing declarations

2022-07-29 Thread Furkan via Phabricator via cfe-commits
furkanusta updated this revision to Diff 448694.
furkanusta added a comment.

- [clang] Add test case for D130363 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130363

Files:
  clang/lib/Parse/ParseDecl.cpp
  clang/test/CodeCompletion/overrides.cpp


Index: clang/test/CodeCompletion/overrides.cpp
===
--- clang/test/CodeCompletion/overrides.cpp
+++ clang/test/CodeCompletion/overrides.cpp
@@ -8,6 +8,11 @@
 virtual int ttt(bool param, int x = 3) const;
 void vfunc(bool param, int p) override;
 };
+void foo() {
+  class D : public A {
+
+  };
+}
 class C : public B {
  public:
   void vfunc(bool param) override;
@@ -15,19 +20,23 @@
 };
 
 // Runs completion at ^vf
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:14:3 %s -o - | 
FileCheck -check-prefix=CHECK-CC1 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:19:3 %s -o - | 
FileCheck -check-prefix=CHECK-CC1 %s
 // CHECK-CC1: COMPLETION: Pattern : int ttt(bool param, int x = 3) const 
override{{$}}
 // CHECK-CC1: COMPLETION: Pattern : void vfunc(bool param, int p) override{{$}}
 // CHECK-CC1-NOT: COMPLETION: Pattern : void vfunc(bool param) override{{$}}
 //
 // Runs completion at vf^
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:14:5 %s -o - | 
FileCheck -check-prefix=CHECK-CC2 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:19:5 %s -o - | 
FileCheck -check-prefix=CHECK-CC2 %s
 // CHECK-CC2-NOT: COMPLETION: Pattern : int ttt(bool param, int x = 3) const 
override{{$}}
 // CHECK-CC2: COMPLETION: Pattern : void vfunc(bool param, int p) override{{$}}
 // CHECK-CC2-NOT: COMPLETION: Pattern : void vfunc(bool param) override{{$}}
 //
-// Runs completion at void ^ on line 13.
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:13:8 %s -o - | 
FileCheck -check-prefix=CHECK-CC3 %s
+// Runs completion at void ^ on line 18.
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:18:8 %s -o - | 
FileCheck -check-prefix=CHECK-CC3 %s
 // CHECK-CC3-NOT: COMPLETION: Pattern : int ttt(bool param, int x = 3) const 
override{{$}}
 // CHECK-CC3-NOT: COMPLETION: Pattern : void vfunc(bool param, int p) 
override{{$}}
 // CHECK-CC3-NOT: COMPLETION: Pattern : void vfunc(bool param) override{{$}}
+//
+// Runs completion at empty line on line 13.
+// RUN: %clang_cc1 -fsyntax-only -code-completion-patterns 
-code-completion-at=%s:13:1 %s -o - | FileCheck -check-prefix=CHECK-CC4 %s
+// CHECK-CC4: COMPLETION: Pattern : void vfunc(bool param) override{{$}}
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -3266,13 +3266,14 @@
 return;
   }
 
-  if (getCurScope()->getFnParent() || getCurScope()->getBlockParent())
-CCC = Sema::PCC_LocalDeclarationSpecifiers;
-  else if (TemplateInfo.Kind != ParsedTemplateInfo::NonTemplate)
+  // Class context can appear inside a function/block, so prioritise that.
+  if (TemplateInfo.Kind != ParsedTemplateInfo::NonTemplate)
 CCC = DSContext == DeclSpecContext::DSC_class ? 
Sema::PCC_MemberTemplate
   : Sema::PCC_Template;
   else if (DSContext == DeclSpecContext::DSC_class)
 CCC = Sema::PCC_Class;
+  else if (getCurScope()->getFnParent() || getCurScope()->getBlockParent())
+CCC = Sema::PCC_LocalDeclarationSpecifiers;
   else if (CurParsedObjCImpl)
 CCC = Sema::PCC_ObjCImplementation;
 


Index: clang/test/CodeCompletion/overrides.cpp
===
--- clang/test/CodeCompletion/overrides.cpp
+++ clang/test/CodeCompletion/overrides.cpp
@@ -8,6 +8,11 @@
 virtual int ttt(bool param, int x = 3) const;
 void vfunc(bool param, int p) override;
 };
+void foo() {
+  class D : public A {
+
+  };
+}
 class C : public B {
  public:
   void vfunc(bool param) override;
@@ -15,19 +20,23 @@
 };
 
 // Runs completion at ^vf
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:14:3 %s -o - | FileCheck -check-prefix=CHECK-CC1 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:19:3 %s -o - | FileCheck -check-prefix=CHECK-CC1 %s
 // CHECK-CC1: COMPLETION: Pattern : int ttt(bool param, int x = 3) const override{{$}}
 // CHECK-CC1: COMPLETION: Pattern : void vfunc(bool param, int p) override{{$}}
 // CHECK-CC1-NOT: COMPLETION: Pattern : void vfunc(bool param) override{{$}}
 //
 // Runs completion at vf^
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:14:5 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:19:5 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
 // CHECK-CC2-NOT: COMPLETION: Pattern : int ttt(bool param, int x = 3) const override{{$}}
 // CHECK-CC2: COMPLETI

[PATCH] D130363: [clang] Give priority to Class context while parsing declarations

2022-07-29 Thread Furkan via Phabricator via cfe-commits
furkanusta added a comment.

I've added a test case but I have a question.
This is regardless of the current issue (i.e. no function context, clang++14 
with no patches)

  struct X {
  virtual void foo();
  };
  struct Y : public X {
  over
  };

I am trying to complete override in class Y here, but I get no result.
The command I am using is:
clang++ -cc1 -xc++  -code-completion-patterns -fsyntax-only 
-code-completion-at="test.cpp:5:2" test.cpp
The only output I get is: COMPLETION: operator
If I start the completion at the first column I receive the correct result. 
Is my invocation correct or is this case handled by clangd and not clang?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130363

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


[PATCH] D130793: [clang-tidy] adjust treating of array-of-pointers when 'AnalyzePointers' is deactivated

2022-07-29 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth created this revision.
JonasToth added reviewers: njames93, aaron.ballman, alexfh.
Herald added subscribers: carlosgalvezp, xazax.hun.
Herald added a project: All.
JonasToth requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

'misc-const-correctness' previously considered arrays as 'Values' independent 
of the type of the elements.
This is inconsistent with the configuration of the check to disable treating 
pointers as values.
This patch rectifies this inconsistency.

Fixes #56749


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130793

Files:
  clang-tools-extra/clang-tidy/misc/ConstCorrectnessCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/misc/const-correctness-pointer-as-values.cpp
  clang-tools-extra/test/clang-tidy/checkers/misc/const-correctness-values.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc/const-correctness-values.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/misc/const-correctness-values.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/misc/const-correctness-values.cpp
@@ -526,18 +526,11 @@
   // CHECK-FIXES: int const p_local1[2]
   for (const int &const_ref : p_local1) {
   }
+}
 
-  int *p_local2[2] = {&np_local0[0], &np_local0[1]};
-  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: variable 'p_local2' of type 'int *[2]' can be declared 'const'
-  // CHECK-FIXES: int *const p_local2[2]
-  for (const int *con_ptr : p_local2) {
-  }
-
-  int *p_local3[2] = {nullptr, nullptr};
-  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: variable 'p_local3' of type 'int *[2]' can be declared 'const'
-  // CHECK-FIXES: int *const p_local3[2]
-  for (const auto *con_ptr : p_local3) {
-  }
+void arrays_of_pointers_are_ignored() {
+  int *np_local0[2] = {nullptr, nullptr};
+  // CHECK-NOT-FIXES: int * const np_local0[2]
 }
 
 inline void *operator new(decltype(sizeof(void *)), void *p) { return p; }
@@ -908,41 +901,6 @@
   sizeof(int[++N]);
 }
 
-template 
-struct SmallVectorBase {
-  T data[4];
-  void push_back(const T &el) {}
-  int size() const { return 4; }
-  T *begin() { return data; }
-  const T *begin() const { return data; }
-  T *end() { return data + 4; }
-  const T *end() const { return data + 4; }
-};
-
-template 
-struct SmallVector : SmallVectorBase {};
-
-template 
-void EmitProtocolMethodList(T &&Methods) {
-  // Note: If the template is uninstantiated the analysis does not figure out,
-  // that p_local0 could be const. Not sure why, but probably bails because
-  // some expressions are type-dependent.
-  SmallVector p_local0;
-  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: variable 'p_local0' of type 'SmallVector' can be declared 'const'
-  // CHECK-FIXES: SmallVector const p_local0
-  SmallVector np_local0;
-  for (const auto *I : Methods) {
-if (I == nullptr)
-  np_local0.push_back(I);
-  }
-  p_local0.size();
-}
-void instantiate() {
-  int *p_local0[4] = {nullptr, nullptr, nullptr, nullptr};
-  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: variable 'p_local0' of type 'int *[4]' can be declared 'const'
-  // CHECK-FIXES: int *const p_local0[4]
-  EmitProtocolMethodList(p_local0);
-}
 struct base {
   int member;
 };
Index: clang-tools-extra/test/clang-tidy/checkers/misc/const-correctness-pointer-as-values.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/misc/const-correctness-pointer-as-values.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/misc/const-correctness-pointer-as-values.cpp
@@ -11,3 +11,57 @@
   // CHECK-MESSAGES: [[@LINE-1]]:3: warning: variable 'p_local0' of type 'double *' can be declared 'const'
   // CHECK-FIXES: double *const p_local0
 }
+
+void range_for() {
+  int np_local0[2] = {1, 2};
+  int *p_local0[2] = {&np_local0[0], &np_local0[1]};
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: variable 'p_local0' of type 'int *[2]' can be declared 'const'
+  // CHECK-FIXES: int *const p_local0[2]
+  for (const int *p_local1 : p_local0) {
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: variable 'p_local1' of type 'const int *' can be declared 'const'
+  // CHECK-FIXES: for (const int *const p_local1 : p_local0)
+  }
+
+  int *p_local2[2] = {nullptr, nullptr};
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: variable 'p_local2' of type 'int *[2]' can be declared 'const'
+  // CHECK-FIXES: int *const p_local2[2]
+  for (const auto *con_ptr : p_local2) {
+  }
+
+}
+
+template 
+struct SmallVectorBase {
+  T data[4];
+  void push_back(const T &el) {}
+  int size() const { return 4; }
+  T *begin() { return data; }
+  const T *begin() const { return data; }
+  T *end() { return data + 4; }
+  const T *end() const { return data + 4; }
+};
+
+template 
+struct SmallVector : SmallVectorBase {};
+
+template 
+void EmitProtocolMethodList(T &&Methods) {
+  // Note: If the template is uninstantiated the analysis does not figure out,
+  

  1   2   >