[PATCH] D143664: [SanitizerBinaryMetadata] Support ignore list

2023-02-10 Thread Marco Elver via Phabricator via cfe-commits
melver marked an inline comment as done.
melver added inline comments.



Comment at: clang/test/Driver/fsanitize-metadata-ignorelist.c:6
+// RUN: %clang -target aarch64-linux-gnu -fexperimental-sanitize-metadata=all 
-fexperimental-sanitize-metadata-ignorelist=%t.good 
-fexperimental-sanitize-metadata-ignorelist=%t.second %s -### 2>&1 | FileCheck 
%s
+// CHECK: -fexperimental-sanitize-metadata-ignorelist={{.*}}.good" 
"-fexperimental-sanitize-metadata-ignorelist={{.*}}.second

dvyukov wrote:
> What is this test doing?
Driver test that frontend passes all the options to cc1. Every option should 
have such a test in Driver/.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143664

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


[clang] dd380f9 - [NFC] Remove the unused parameter introduced in e135476

2023-02-10 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2023-02-10T16:03:29+08:00
New Revision: dd380f9243dec95744a43ff73723e85ad77abbdb

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

LOG: [NFC] Remove the unused parameter introduced in e135476

I introduced an unused parameter due to an oversight during rebasing.
Now the patch removes the parameter.

Added: 


Modified: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
clang/tools/clang-scan-deps/ClangScanDeps.cpp

Removed: 




diff  --git 
a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h 
b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
index 4eac56ec81b4..961e383b1096 100644
--- a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
+++ b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
@@ -106,8 +106,7 @@ class DependencyScanningTool {
   llvm::Expected
   getP1689ModuleDependencyFile(
   const clang::tooling::CompileCommand &Command, StringRef CWD,
-  std::string &MakeformatOutput, std::string &MakeformatOutputPath,
-  std::optional ModuleName = std::nullopt);
+  std::string &MakeformatOutput, std::string &MakeformatOutputPath);
 
   /// Given a Clang driver command-line for a translation unit, gather the
   /// modular dependencies and return the information needed for explicit 
build.

diff  --git a/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
index b336e2f28e01..b5e336bc704c 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
@@ -92,8 +92,7 @@ llvm::Expected 
DependencyScanningTool::getDependencyFile(
 
 llvm::Expected DependencyScanningTool::getP1689ModuleDependencyFile(
 const CompileCommand &Command, StringRef CWD,
-std::string &MakeformatOutput, std::string &MakeformatOutputPath,
-std::optional ModuleName) {
+std::string &MakeformatOutput, std::string &MakeformatOutputPath) {
   class P1689ModuleDependencyPrinterConsumer
   : public MakeDependencyPrinterConsumer {
   public:

diff  --git a/clang/tools/clang-scan-deps/ClangScanDeps.cpp 
b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
index fc2ade955a57..4cfb857c5b3b 100644
--- a/clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -833,8 +833,7 @@ int main(int argc, const char **argv) {
   std::string MakeformatOutput;
 
   auto MaybeRule = WorkerTools[I]->getP1689ModuleDependencyFile(
-  *Input, CWD, MakeformatOutput, MakeformatOutputPath,
-  MaybeModuleName);
+  *Input, CWD, MakeformatOutput, MakeformatOutputPath);
   HadErrors =
   handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs);
 



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


[clang] 288f688 - [NFC] Add test to show that preprocess an import decl won't require to load it actually

2023-02-10 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2023-02-10T16:14:37+08:00
New Revision: 288f688e294a0d2ee162f99f745c06d1e95d3620

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

LOG: [NFC] Add test to show that preprocess an import decl won't require to 
load it actually

Close https://github.com/llvm/llvm-project/issues/59287

This is addressed in D137526 but I forgot to add a test for it.

Added: 
clang/test/Modules/preprocess-named-modules.cppm

Modified: 


Removed: 




diff  --git a/clang/test/Modules/preprocess-named-modules.cppm 
b/clang/test/Modules/preprocess-named-modules.cppm
new file mode 100644
index 0..67a6cc384a1c7
--- /dev/null
+++ b/clang/test/Modules/preprocess-named-modules.cppm
@@ -0,0 +1,7 @@
+// Tests tht when we preprocess a source, the compiler won't
+// require to load the named modules after import.
+//
+// RUN: %clang_cc1 -std=c++20 -E %s -o - | FileCheck %s
+import non_exist_modules;
+
+// CHECK: import non_exist_modules;



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


[PATCH] D143664: [SanitizerBinaryMetadata] Support ignore list

2023-02-10 Thread Marco Elver via Phabricator via cfe-commits
melver updated this revision to Diff 496353.
melver marked an inline comment as done.
melver added a comment.

Make Driver test check that cc1 doesn't receive flag if not required.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143664

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/CodeGen/sanitize-metadata-ignorelist.c
  clang/test/Driver/fsanitize-metadata-ignorelist.c
  llvm/include/llvm/Transforms/Instrumentation/SanitizerBinaryMetadata.h
  llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp

Index: llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
@@ -38,13 +38,16 @@
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Debug.h"
+#include "llvm/Support/SpecialCaseList.h"
 #include "llvm/Support/StringSaver.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include "llvm/TargetParser/Triple.h"
 #include "llvm/Transforms/Instrumentation.h"
 #include "llvm/Transforms/Utils/ModuleUtils.h"
 
 #include 
 #include 
+#include 
 
 using namespace llvm;
 
@@ -121,9 +124,11 @@
 
 class SanitizerBinaryMetadata {
 public:
-  SanitizerBinaryMetadata(Module &M, SanitizerBinaryMetadataOptions Opts)
+  SanitizerBinaryMetadata(Module &M, SanitizerBinaryMetadataOptions Opts,
+  std::unique_ptr Ignorelist)
   : Mod(M), Options(transformOptionsFromCl(std::move(Opts))),
-TargetTriple(M.getTargetTriple()), IRB(M.getContext()) {
+Ignorelist(std::move(Ignorelist)), TargetTriple(M.getTargetTriple()),
+IRB(M.getContext()) {
 // FIXME: Make it work with other formats.
 assert(TargetTriple.isOSBinFormatELF() && "ELF only");
   }
@@ -168,6 +173,7 @@
 
   Module &Mod;
   const SanitizerBinaryMetadataOptions Options;
+  std::unique_ptr Ignorelist;
   const Triple TargetTriple;
   IRBuilder<> IRB;
   BumpPtrAllocator Alloc;
@@ -243,6 +249,8 @@
 return;
   if (F.hasFnAttribute(Attribute::DisableSanitizerInstrumentation))
 return;
+  if (Ignorelist && Ignorelist->inSection("metadata", "fun", F.getName()))
+return;
   // Don't touch available_externally functions, their actual body is elsewhere.
   if (F.getLinkage() == GlobalValue::AvailableExternallyLinkage)
 return;
@@ -455,12 +463,20 @@
 } // namespace
 
 SanitizerBinaryMetadataPass::SanitizerBinaryMetadataPass(
-SanitizerBinaryMetadataOptions Opts)
-: Options(std::move(Opts)) {}
+SanitizerBinaryMetadataOptions Opts, ArrayRef IgnorelistFiles)
+: Options(std::move(Opts)), IgnorelistFiles(std::move(IgnorelistFiles)) {}
 
 PreservedAnalyses
 SanitizerBinaryMetadataPass::run(Module &M, AnalysisManager &AM) {
-  SanitizerBinaryMetadata Pass(M, Options);
+  std::unique_ptr Ignorelist;
+  if (!IgnorelistFiles.empty()) {
+Ignorelist = SpecialCaseList::createOrDie(IgnorelistFiles,
+  *vfs::getRealFileSystem());
+if (Ignorelist->inSection("metadata", "src", M.getSourceFileName()))
+  return PreservedAnalyses::all();
+  }
+
+  SanitizerBinaryMetadata Pass(M, Options, std::move(Ignorelist));
   if (Pass.run())
 return PreservedAnalyses::none();
   return PreservedAnalyses::all();
Index: llvm/include/llvm/Transforms/Instrumentation/SanitizerBinaryMetadata.h
===
--- llvm/include/llvm/Transforms/Instrumentation/SanitizerBinaryMetadata.h
+++ llvm/include/llvm/Transforms/Instrumentation/SanitizerBinaryMetadata.h
@@ -12,6 +12,7 @@
 #ifndef LLVM_TRANSFORMS_INSTRUMENTATION_SANITIZERBINARYMETADATA_H
 #define LLVM_TRANSFORMS_INSTRUMENTATION_SANITIZERBINARYMETADATA_H
 
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/IR/Function.h"
 #include "llvm/IR/Module.h"
 #include "llvm/IR/PassManager.h"
@@ -50,12 +51,14 @@
 : public PassInfoMixin {
 public:
   explicit SanitizerBinaryMetadataPass(
-  SanitizerBinaryMetadataOptions Opts = {});
+  SanitizerBinaryMetadataOptions Opts = {},
+  ArrayRef IgnorelistFiles = {});
   PreservedAnalyses run(Module &M, ModuleAnalysisManager &AM);
   static bool isRequired() { return true; }
 
 private:
   const SanitizerBinaryMetadataOptions Options;
+  const ArrayRef IgnorelistFiles;
 };
 
 } // namespace llvm
Index: clang/test/Driver/fsanitize-metadata-ignorelist.c
===
--- /dev/null
+++ clang/test/Driver/fsanitize-metadata-ignorelist.c
@@ -0,0 +1,14 @@
+// Verify Driver passes on -fsanitize-metadata-ignorel

[clang] f4ef084 - [OPENMP][NFC] added loop bind to the support page

2023-02-10 Thread Sandeep Kosuri via cfe-commits

Author: Sandeep Kosuri
Date: 2023-02-10T02:33:44-06:00
New Revision: f4ef08433fe78c31493688f5ab608b2f9689f478

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

LOG: [OPENMP][NFC] added loop bind to the support page

Added: 


Modified: 
clang/docs/OpenMPSupport.rst

Removed: 




diff  --git a/clang/docs/OpenMPSupport.rst b/clang/docs/OpenMPSupport.rst
index 16cb50afa1a13..f1f0f85bacde6 100644
--- a/clang/docs/OpenMPSupport.rst
+++ b/clang/docs/OpenMPSupport.rst
@@ -122,6 +122,8 @@ implementation.
 
+--+--+--+---+
 | loop | #pragma omp loop (directive)  
   | :part:`worked on`| 
  |
 
+--+--+--+---+
+| loop | #pragma omp loop bind 
   | :part:`worked on`| 
  |
++--+--+--+---+
 | loop | collapse imperfectly nested loop  
   | :good:`done` | 
  |
 
+--+--+--+---+
 | loop | collapse non-rectangular nested loop  
   | :good:`done` | 
  |



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


[clang] 421215b - [SanitizerBinaryMetadata] Support ignore list

2023-02-10 Thread Marco Elver via cfe-commits

Author: Marco Elver
Date: 2023-02-10T10:25:48+01:00
New Revision: 421215b919d037a912cd4fffa73242852da41fc0

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

LOG: [SanitizerBinaryMetadata] Support ignore list

For large projects it will be required to opt out entire subdirectories.
In the absence of fine-grained control over the flags passed via the
build system, introduce -fexperimental-sanitize-metadata-ignorelist=.

The format is identical to other sanitizer ignore lists, and its effect
will be to simply not instrument either functions or entire modules
based on the rules in the ignore list file.

Reviewed By: dvyukov

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

Added: 
clang/test/CodeGen/sanitize-metadata-ignorelist.c
clang/test/Driver/fsanitize-metadata-ignorelist.c

Modified: 
clang/include/clang/Basic/CodeGenOptions.h
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/include/clang/Driver/Options.td
clang/include/clang/Driver/SanitizerArgs.h
clang/lib/CodeGen/BackendUtil.cpp
clang/lib/Driver/SanitizerArgs.cpp
llvm/include/llvm/Transforms/Instrumentation/SanitizerBinaryMetadata.h
llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/CodeGenOptions.h 
b/clang/include/clang/Basic/CodeGenOptions.h
index 4175fe3072ab8..04a516df1911e 100644
--- a/clang/include/clang/Basic/CodeGenOptions.h
+++ b/clang/include/clang/Basic/CodeGenOptions.h
@@ -417,6 +417,11 @@ class CodeGenOptions : public CodeGenOptionsBase {
   /// coverage pass should actually not be instrumented.
   std::vector SanitizeCoverageIgnorelistFiles;
 
+  /// Path to ignorelist file specifying which objects
+  /// (files, functions) listed for instrumentation by sanitizer
+  /// binary metadata pass should not be instrumented.
+  std::vector SanitizeMetadataIgnorelistFiles;
+
   /// Name of the stack usage file (i.e., .su file) if user passes
   /// -fstack-usage. If empty, it can be implied that -fstack-usage is not
   /// passed on the command line.

diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 800819779890a..8d557846c6ff0 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -215,6 +215,8 @@ def err_drv_malformed_sanitizer_coverage_allowlist : Error<
   "malformed sanitizer coverage allowlist: '%0'">;
 def err_drv_malformed_sanitizer_coverage_ignorelist : Error<
   "malformed sanitizer coverage ignorelist: '%0'">;
+def err_drv_malformed_sanitizer_metadata_ignorelist : Error<
+  "malformed sanitizer metadata ignorelist: '%0'">;
 def err_drv_unsupported_static_ubsan_darwin : Error<
   "static UndefinedBehaviorSanitizer runtime is not supported on darwin">;
 def err_drv_duplicate_config : Error<

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 9766a087eb6d9..96904518a51d7 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1756,6 +1756,10 @@ def fexperimental_sanitize_metadata_EQ : 
CommaJoined<["-"], "fexperimental-sanit
 def fno_experimental_sanitize_metadata_EQ : CommaJoined<["-"], 
"fno-experimental-sanitize-metadata=">,
   Group, Flags<[CoreOption]>,
   HelpText<"Disable emitting metadata for binary analysis sanitizers">;
+def fexperimental_sanitize_metadata_ignorelist_EQ : Joined<["-"], 
"fexperimental-sanitize-metadata-ignorelist=">,
+Group, Flags<[CoreOption]>,
+HelpText<"Disable sanitizer metadata for modules and functions that match 
the provided special case list">,
+
MarshallingInfoStringVector>;
 def fsanitize_memory_track_origins_EQ : Joined<["-"], 
"fsanitize-memory-track-origins=">,
 Group,
 HelpText<"Enable origins tracking in 
MemorySanitizer">,

diff  --git a/clang/include/clang/Driver/SanitizerArgs.h 
b/clang/include/clang/Driver/SanitizerArgs.h
index abc5271b0a811..61b7c7f809ae4 100644
--- a/clang/include/clang/Driver/SanitizerArgs.h
+++ b/clang/include/clang/Driver/SanitizerArgs.h
@@ -30,6 +30,7 @@ class SanitizerArgs {
   std::vector SystemIgnorelistFiles;
   std::vector CoverageAllowlistFiles;
   std::vector CoverageIgnorelistFiles;
+  std::vector BinaryMetadataIgnorelistFiles;
   int CoverageFeatures = 0;
   int BinaryMetadataFeatures = 0;
   int MsanTrackOrigins = 0;

diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index f38d2347c9723..b03d326dd0654 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -665,7 +665,8 @@ static void addSanitizers(const Triple &TargetTriple,

[PATCH] D143664: [SanitizerBinaryMetadata] Support ignore list

2023-02-10 Thread Marco Elver 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 rG421215b919d0: [SanitizerBinaryMetadata] Support ignore list 
(authored by melver).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143664

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/CodeGen/sanitize-metadata-ignorelist.c
  clang/test/Driver/fsanitize-metadata-ignorelist.c
  llvm/include/llvm/Transforms/Instrumentation/SanitizerBinaryMetadata.h
  llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp

Index: llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
@@ -38,13 +38,16 @@
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Debug.h"
+#include "llvm/Support/SpecialCaseList.h"
 #include "llvm/Support/StringSaver.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include "llvm/TargetParser/Triple.h"
 #include "llvm/Transforms/Instrumentation.h"
 #include "llvm/Transforms/Utils/ModuleUtils.h"
 
 #include 
 #include 
+#include 
 
 using namespace llvm;
 
@@ -121,9 +124,11 @@
 
 class SanitizerBinaryMetadata {
 public:
-  SanitizerBinaryMetadata(Module &M, SanitizerBinaryMetadataOptions Opts)
+  SanitizerBinaryMetadata(Module &M, SanitizerBinaryMetadataOptions Opts,
+  std::unique_ptr Ignorelist)
   : Mod(M), Options(transformOptionsFromCl(std::move(Opts))),
-TargetTriple(M.getTargetTriple()), IRB(M.getContext()) {
+Ignorelist(std::move(Ignorelist)), TargetTriple(M.getTargetTriple()),
+IRB(M.getContext()) {
 // FIXME: Make it work with other formats.
 assert(TargetTriple.isOSBinFormatELF() && "ELF only");
   }
@@ -168,6 +173,7 @@
 
   Module &Mod;
   const SanitizerBinaryMetadataOptions Options;
+  std::unique_ptr Ignorelist;
   const Triple TargetTriple;
   IRBuilder<> IRB;
   BumpPtrAllocator Alloc;
@@ -243,6 +249,8 @@
 return;
   if (F.hasFnAttribute(Attribute::DisableSanitizerInstrumentation))
 return;
+  if (Ignorelist && Ignorelist->inSection("metadata", "fun", F.getName()))
+return;
   // Don't touch available_externally functions, their actual body is elsewhere.
   if (F.getLinkage() == GlobalValue::AvailableExternallyLinkage)
 return;
@@ -455,12 +463,20 @@
 } // namespace
 
 SanitizerBinaryMetadataPass::SanitizerBinaryMetadataPass(
-SanitizerBinaryMetadataOptions Opts)
-: Options(std::move(Opts)) {}
+SanitizerBinaryMetadataOptions Opts, ArrayRef IgnorelistFiles)
+: Options(std::move(Opts)), IgnorelistFiles(std::move(IgnorelistFiles)) {}
 
 PreservedAnalyses
 SanitizerBinaryMetadataPass::run(Module &M, AnalysisManager &AM) {
-  SanitizerBinaryMetadata Pass(M, Options);
+  std::unique_ptr Ignorelist;
+  if (!IgnorelistFiles.empty()) {
+Ignorelist = SpecialCaseList::createOrDie(IgnorelistFiles,
+  *vfs::getRealFileSystem());
+if (Ignorelist->inSection("metadata", "src", M.getSourceFileName()))
+  return PreservedAnalyses::all();
+  }
+
+  SanitizerBinaryMetadata Pass(M, Options, std::move(Ignorelist));
   if (Pass.run())
 return PreservedAnalyses::none();
   return PreservedAnalyses::all();
Index: llvm/include/llvm/Transforms/Instrumentation/SanitizerBinaryMetadata.h
===
--- llvm/include/llvm/Transforms/Instrumentation/SanitizerBinaryMetadata.h
+++ llvm/include/llvm/Transforms/Instrumentation/SanitizerBinaryMetadata.h
@@ -12,6 +12,7 @@
 #ifndef LLVM_TRANSFORMS_INSTRUMENTATION_SANITIZERBINARYMETADATA_H
 #define LLVM_TRANSFORMS_INSTRUMENTATION_SANITIZERBINARYMETADATA_H
 
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/IR/Function.h"
 #include "llvm/IR/Module.h"
 #include "llvm/IR/PassManager.h"
@@ -50,12 +51,14 @@
 : public PassInfoMixin {
 public:
   explicit SanitizerBinaryMetadataPass(
-  SanitizerBinaryMetadataOptions Opts = {});
+  SanitizerBinaryMetadataOptions Opts = {},
+  ArrayRef IgnorelistFiles = {});
   PreservedAnalyses run(Module &M, ModuleAnalysisManager &AM);
   static bool isRequired() { return true; }
 
 private:
   const SanitizerBinaryMetadataOptions Options;
+  const ArrayRef IgnorelistFiles;
 };
 
 } // namespace llvm
Index: clang/test/Driver/fsanitize-metadata-ignorelist.c
===
--- /dev/null
+++ clang/test/Driver/fsanitize-metadata-ignorelist.c
@@ -0,0 +1,14 @@
+// V

[PATCH] D143638: [clangd] Move function body to out-of-line: unnamed class method incorrect moving

2023-02-10 Thread Denis Fatkulin via Phabricator via cfe-commits
denis-fatkulin updated this revision to Diff 496375.
denis-fatkulin added a comment.

Review fixes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143638

Files:
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp


Index: clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
@@ -84,6 +84,32 @@
 template  void fo^o() {};
 template <> void fo^o() {};
   )cpp");
+
+  // Not available on methods of unnamed classes.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {
+  struct { void b^ar() {} } Bar;
+};
+  )cpp");
+
+  // Not available on methods of named classes with unnamed parent in parents
+  // nesting.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {
+  struct {
+struct Bar { void b^ar() {} };
+  } Baz;
+};
+  )cpp");
+
+  // Not available on definitions within unnamed namespaces
+  EXPECT_UNAVAILABLE(R"cpp(
+namespace {
+  struct Foo {
+void f^oo() {}
+  };
+} // namespace
+  )cpp");
 }
 
 TEST_F(DefineOutlineTest, FailsWithoutSource) {
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
@@ -392,11 +392,20 @@
 if (Source->getTemplateSpecializationInfo())
   return false;
 
-// Bail out in templated classes, as it is hard to spell the class name, 
i.e
-// if the template parameter is unnamed.
 if (auto *MD = llvm::dyn_cast(Source)) {
+  // Bail out in templated classes, as it is hard to spell the class name,
+  // i.e if the template parameter is unnamed.
   if (MD->getParent()->isTemplated())
 return false;
+
+  // The refactoring is meaningless for unnamed classes and definitions
+  // within unnamed namespaces.
+  for (const DeclContext *DC = MD->getParent(); DC; DC = DC->getParent()) {
+if (auto *ND = llvm::dyn_cast(DC)) {
+  if (ND->getDeclName().isEmpty())
+return false;
+}
+  }
 }
 
 // Note that we don't check whether an implementation file exists or not in


Index: clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
@@ -84,6 +84,32 @@
 template  void fo^o() {};
 template <> void fo^o() {};
   )cpp");
+
+  // Not available on methods of unnamed classes.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {
+  struct { void b^ar() {} } Bar;
+};
+  )cpp");
+
+  // Not available on methods of named classes with unnamed parent in parents
+  // nesting.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {
+  struct {
+struct Bar { void b^ar() {} };
+  } Baz;
+};
+  )cpp");
+
+  // Not available on definitions within unnamed namespaces
+  EXPECT_UNAVAILABLE(R"cpp(
+namespace {
+  struct Foo {
+void f^oo() {}
+  };
+} // namespace
+  )cpp");
 }
 
 TEST_F(DefineOutlineTest, FailsWithoutSource) {
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
@@ -392,11 +392,20 @@
 if (Source->getTemplateSpecializationInfo())
   return false;
 
-// Bail out in templated classes, as it is hard to spell the class name, i.e
-// if the template parameter is unnamed.
 if (auto *MD = llvm::dyn_cast(Source)) {
+  // Bail out in templated classes, as it is hard to spell the class name,
+  // i.e if the template parameter is unnamed.
   if (MD->getParent()->isTemplated())
 return false;
+
+  // The refactoring is meaningless for unnamed classes and definitions
+  // within unnamed namespaces.
+  for (const DeclContext *DC = MD->getParent(); DC; DC = DC->getParent()) {
+if (auto *ND = llvm::dyn_cast(DC)) {
+  if (ND->getDeclName().isEmpty())
+return false;
+}
+  }
 }
 
 // Note that we don't check whether an implementation file exists or not in
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143638: [clangd] Move function body to out-of-line: unnamed class method incorrect moving

2023-02-10 Thread Denis Fatkulin via Phabricator via cfe-commits
denis-fatkulin marked 3 inline comments as done.
denis-fatkulin added inline comments.



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp:395
 
 // Bail out in templated classes, as it is hard to spell the class name, 
i.e
 // if the template parameter is unnamed.

kadircet wrote:
> could you move this comment closer to the `isTempated` if statement below?
Fixed



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp:401
+
+  // The refactoring is meaningless for unnamed classes.
+  const auto *Parent = MD->getParent();

kadircet wrote:
> not just classes, but also for cases with unnamed namespaces.
> 
> could you change this to look like:
> ```
> for(DeclContext *DC = MD->getParent(); DC; DC = DC->getParent()) {
>   if (auto *ND = llvm::dyn_cast(DC)) {
>  if(ND->getDeclName().isEmpty())
> return false;
>   }
> }
> ```
It's a useful remark. Tanks! 



Comment at: clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp:97
+  // nesting.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {

kadircet wrote:
> can you also have a test inside an unnamed namespace?
Test case added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143638

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


[PATCH] D143657: [Clang][RISCV] Guard vector float16 type correctly with semantic analysis

2023-02-10 Thread Yueh-Ting (eop) Chen via Phabricator via cfe-commits
eopXD updated this revision to Diff 496382.
eopXD added a comment.

Update code: use a more scalable way to check for RVV type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143657

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaRISCVVectorLookup.cpp
  clang/test/Sema/riscv-vector-float16-check.c
  clang/utils/TableGen/RISCVVEmitter.cpp

Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -368,14 +368,13 @@
   }
 }
   }
-  OS << "#if defined(__riscv_zvfh)\n";
+
   for (int Log2LMUL : Log2LMULs) {
 auto T = TypeCache.computeType(BasicType::Float16, Log2LMUL,
PrototypeDescriptor::Vector);
 if (T)
   printType(*T);
   }
-  OS << "#endif\n";
 
   OS << "#if (__riscv_v_elen_fp >= 32)\n";
   for (int Log2LMUL : Log2LMULs) {
Index: clang/test/Sema/riscv-vector-float16-check.c
===
--- /dev/null
+++ clang/test/Sema/riscv-vector-float16-check.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-feature +d \
+// RUN:   -target-feature +v -target-feature +zfh \
+// RUN:   -disable-O0-optnone -o - -fsyntax-only %s -verify 
+// REQUIRES: riscv-registered-target
+#include 
+
+vfloat16m1_t foo() { /* expected-error {{RISC-V type 'vfloat16m1_t' (aka '__rvv_float16m1_t') requires the 'experimental-zvfh' extension}} */
+} /* expected-warning {{non-void function does not return a value}}*/
Index: clang/lib/Sema/SemaRISCVVectorLookup.cpp
===
--- clang/lib/Sema/SemaRISCVVectorLookup.cpp
+++ clang/lib/Sema/SemaRISCVVectorLookup.cpp
@@ -171,7 +171,6 @@
   const TargetInfo &TI = Context.getTargetInfo();
   bool HasVectorFloat32 = TI.hasFeature("zve32f");
   bool HasVectorFloat64 = TI.hasFeature("zve64d");
-  bool HasZvfh = TI.hasFeature("experimental-zvfh");
   bool HasRV64 = TI.hasFeature("64bit");
   bool HasFullMultiply = TI.hasFeature("v");
 
@@ -223,9 +222,6 @@
 continue;
 
   // Check requirement.
-  if (BaseType == BasicType::Float16 && !HasZvfh)
-continue;
-
   if (BaseType == BasicType::Float32 && !HasVectorFloat32)
 continue;
 
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -2046,6 +2046,12 @@
 targetDiag(D->getLocation(), diag::note_defined_here, FD) << D;
 }
 
+if (Ty->isRVVType(/* Bitwidth */ 16, /* IsFloat */ true) &&
+!Context.getTargetInfo().hasFeature("experimental-zvfh")) {
+  Diag(Loc, diag::err_riscv_type_requires_extension, FD)
+  << Ty << "experimental-zvfh";
+}
+
 // Don't allow SVE types in functions without a SVE target.
 if (Ty->isSVESizelessBuiltinType() && FD && FD->hasBody()) {
   llvm::StringMap CallerFeatureMap;
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11738,6 +11738,9 @@
   "builtin requires%select{| at least one of the following extensions to be enabled}0: %1">;
 def err_riscv_builtin_invalid_lmul : Error<
   "LMUL argument must be in the range [0,3] or [5,7]">;
+def err_riscv_type_requires_extension : Error<
+  "RISC-V type %0 requires the '%1' extension"
+>;
 
 def err_std_source_location_impl_not_found : Error<
   "'std::source_location::__impl' was not found; it must be defined before '__builtin_source_location' is called">;
Index: clang/include/clang/AST/Type.h
===
--- clang/include/clang/AST/Type.h
+++ clang/include/clang/AST/Type.h
@@ -2279,6 +2279,8 @@
 
   bool isRVVType() const;
 
+  bool isRVVType(unsigned Bitwidth, bool IsFloat) const;
+
   /// Return the implicit lifetime for this type, which must not be dependent.
   Qualifiers::ObjCLifetime getObjCARCImplicitLifetime() const;
 
@@ -7160,6 +7162,17 @@
 false; // end of boolean or operation.
 }
 
+inline bool Type::isRVVType(unsigned Bitwidth, bool IsFloat) const {
+  bool Ret = false;
+#define RVV_TYPE(Name, Id, SingletonId)
+#define RVV_VECTOR_TYPE(Name, Id, SingletonId, NumEls, ElBits, NF, IsSigned,   \
+IsFP)  \
+  if (ElBits == Bitwidth && IsFloat == IsFP)   \
+Ret |= isSpecificBuiltinType(BuiltinType::Id);
+#include "clang/Basic/RISCVVTypes.def"
+  return Ret;
+}
+
 inline bool Type::isTemplateTypeParmType() const {
   return isa(CanonicalTy

[PATCH] D142327: [clang][RISCV] Fix ABI handling of empty structs with hard FP calling conventions in C++

2023-02-10 Thread Kito Cheng via Phabricator via cfe-commits
kito-cheng accepted this revision.
kito-cheng added a comment.

LGTM, Verified with GCC and two clang w/ and w/o this patch, clang with this 
patch is matching GCC's behavior.

Also created an PR on psABI to clarify that: 
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/365


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

https://reviews.llvm.org/D142327

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


[clang] 65f9719 - Revert "[C++20] [Modules] [ClangScanDeps] Enable to print make-style dependency file within P1689 format (4/4)"

2023-02-10 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2023-02-10T17:56:02+08:00
New Revision: 65f9719913eca9c7c72d1abf4eddab767abaebf6

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

LOG: Revert "[C++20] [Modules] [ClangScanDeps] Enable to print make-style 
dependency file within P1689 format (4/4)"

This reverts commit e1354763b6e641e45cc2371270883fcd26edf705.

There is a build failure in m68k-linux testing bot
(https://lab.llvm.org/buildbot/#/builders/192/builds/267), which is
weird. Revert this for now and look at the reasons.

Added: 


Modified: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
clang/test/ClangScanDeps/P1689.cppm
clang/tools/clang-scan-deps/ClangScanDeps.cpp

Removed: 




diff  --git 
a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h 
b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
index 961e383b10963..505137c539e6f 100644
--- a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
+++ b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
@@ -92,21 +92,9 @@ class DependencyScanningTool {
   llvm::Expected
   getDependencyFile(const std::vector &CommandLine, StringRef 
CWD);
 
-  /// Collect the module dependency in P1689 format for C++20 named modules.
-  ///
-  /// \param MakeformatOutput The output parameter for dependency information
-  /// in make format if the command line requires to generate make-format
-  /// dependency information by `-MD -MF `.
-  ///
-  /// \param MakeformatOutputPath The output parameter for the path to
-  /// \param MakeformatOutput.
-  ///
-  /// \returns A \c StringError with the diagnostic output if clang errors
-  /// occurred, P1689 dependency format rules otherwise.
   llvm::Expected
-  getP1689ModuleDependencyFile(
-  const clang::tooling::CompileCommand &Command, StringRef CWD,
-  std::string &MakeformatOutput, std::string &MakeformatOutputPath);
+  getP1689ModuleDependencyFile(const CompileCommand &Command,
+   StringRef CWD);
 
   /// Given a Clang driver command-line for a translation unit, gather the
   /// modular dependencies and return the information needed for explicit 
build.

diff  --git a/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
index b5e336bc704cb..ded5684190221 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
@@ -19,68 +19,66 @@ DependencyScanningTool::DependencyScanningTool(
 llvm::IntrusiveRefCntPtr FS)
 : Worker(Service, std::move(FS)) {}
 
-namespace {
-/// Prints out all of the gathered dependencies into a string.
-class MakeDependencyPrinterConsumer : public DependencyConsumer {
-public:
-  void handleBuildCommand(Command) override {}
-
-  void
-  handleDependencyOutputOpts(const DependencyOutputOptions &Opts) override {
-this->Opts = std::make_unique(Opts);
-  }
+llvm::Expected DependencyScanningTool::getDependencyFile(
+const std::vector &CommandLine, StringRef CWD) {
+  /// Prints out all of the gathered dependencies into a string.
+  class MakeDependencyPrinterConsumer : public DependencyConsumer {
+  public:
+void handleBuildCommand(Command) override {}
 
-  void handleFileDependency(StringRef File) override {
-Dependencies.push_back(std::string(File));
-  }
+void
+handleDependencyOutputOpts(const DependencyOutputOptions &Opts) override {
+  this->Opts = std::make_unique(Opts);
+}
 
-  void handlePrebuiltModuleDependency(PrebuiltModuleDep PMD) override {
-// Same as `handleModuleDependency`.
-  }
+void handleFileDependency(StringRef File) override {
+  Dependencies.push_back(std::string(File));
+}
 
-  void handleModuleDependency(ModuleDeps MD) override {
-// These are ignored for the make format as it can't support the full
-// set of deps, and handleFileDependency handles enough for implicitly
-// built modules to work.
-  }
+void handlePrebuiltModuleDependency(PrebuiltModuleDep PMD) override {
+  // Same as `handleModuleDependency`.
+}
 
-  void handleContextHash(std::string Hash) override {}
+void handleModuleDependency(ModuleDeps MD) override {
+  // These are ignored for the make format as it can't support the full
+  // set of deps, and handleFileDependency handles enough for implicitly
+  // built modules to work.
+}
 
-  std::string lookupModuleOutput(const ModuleID &ID,
- ModuleOutputKind Kind) override {
-llvm::report_fatal_error("unexpected call to lookupModuleOutput");
-

[clang] d768bf9 - [NFC][TargetParser] Replace uses of llvm/Support/Host.h

2023-02-10 Thread Archibald Elliott via cfe-commits

Author: Archibald Elliott
Date: 2023-02-10T09:59:46Z
New Revision: d768bf994f508d7eaf9541a568be3d71096febf5

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

LOG: [NFC][TargetParser] Replace uses of llvm/Support/Host.h

The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.

Added: 


Modified: 
clang-tools-extra/clangd/Feature.cpp
clang-tools-extra/modularize/CoverageChecker.h
clang/lib/Driver/Distro.cpp
clang/lib/Driver/Driver.cpp
clang/lib/Driver/OffloadBundler.cpp
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/lib/Driver/ToolChains/Arch/ARM.cpp
clang/lib/Driver/ToolChains/Arch/CSKY.cpp
clang/lib/Driver/ToolChains/Arch/M68k.cpp
clang/lib/Driver/ToolChains/Arch/PPC.cpp
clang/lib/Driver/ToolChains/Arch/RISCV.cpp
clang/lib/Driver/ToolChains/Arch/Sparc.cpp
clang/lib/Driver/ToolChains/Arch/SystemZ.cpp
clang/lib/Driver/ToolChains/Arch/X86.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/Cuda.cpp
clang/lib/Driver/ToolChains/MSVC.cpp
clang/lib/Frontend/CompilerInstance.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
clang/lib/Interpreter/Interpreter.cpp
clang/lib/Tooling/CompilationDatabase.cpp
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
clang/lib/Tooling/ExpandResponseFilesCompilationDatabase.cpp
clang/lib/Tooling/JSONCompilationDatabase.cpp
clang/lib/Tooling/Tooling.cpp
clang/tools/clang-import-test/clang-import-test.cpp
clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
clang/tools/clang-scan-deps/ClangScanDeps.cpp
clang/tools/driver/cc1as_main.cpp
clang/tools/driver/cc1gen_reproducer_main.cpp
clang/tools/driver/driver.cpp
clang/unittests/AST/StructuralEquivalenceTest.cpp
clang/unittests/ASTMatchers/ASTMatchersInternalTest.cpp
clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
clang/unittests/CodeGen/BufferSourceTest.cpp
clang/unittests/CodeGen/CodeGenExternalTest.cpp
clang/unittests/CodeGen/TestCompiler.h
clang/unittests/Driver/DistroTest.cpp
clang/unittests/Driver/SanitizerArgsTest.cpp
clang/unittests/Frontend/CompilerInvocationTest.cpp
clang/unittests/Interpreter/IncrementalProcessingTest.cpp
clang/unittests/Tooling/RecursiveASTVisitorTests/LambdaExpr.cpp
clang/unittests/Tooling/ToolingTest.cpp
flang/lib/Frontend/CompilerInvocation.cpp
flang/lib/Optimizer/Support/FIRContext.cpp
flang/tools/bbc/bbc.cpp
flang/tools/flang-driver/driver.cpp
flang/unittests/Frontend/FrontendActionTest.cpp
flang/unittests/Optimizer/FIRContextTest.cpp
libc/benchmarks/LibcBenchmark.cpp
lld/ELF/DriverUtils.cpp
lld/MachO/Driver.cpp
lld/MinGW/Driver.cpp
lld/tools/lld/lld.cpp
lld/wasm/Driver.cpp
lldb/source/Host/common/HostInfoBase.cpp
lldb/source/Host/freebsd/Host.cpp
lldb/source/Host/macosx/objcxx/Host.mm
lldb/source/Host/netbsd/HostNetBSD.cpp
lldb/source/Host/openbsd/Host.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.cpp
lldb/unittests/Host/HostInfoTest.cpp
lldb/utils/lit-cpuid/lit-cpuid.cpp
llvm/examples/Kaleidoscope/Chapter8/toy.cpp
llvm/examples/Kaleidoscope/Chapter9/toy.cpp
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
llvm/include/llvm/ObjectYAML/DWARFEmitter.h
llvm/include/llvm/ProfileData/InstrProf.h
llvm/include/llvm/Support/Host.h
llvm/lib/CodeGen/CommandFlags.cpp
llvm/lib/ExecutionEngine/ExecutionEngine.cpp
llvm/lib/ExecutionEngine/Orc/ExecutorProcessControl.cpp
llvm/lib/ExecutionEngine/Orc/JITTargetMachineBuilder.cpp
llvm/lib/ExecutionEngine/Orc/TargetProcess/SimpleRemoteEPCServer.cpp
llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h
llvm/lib/ExecutionEngine/TargetSelect.cpp
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/LTO/LTOModule.cpp
llvm/lib/MC/ELFObjectWriter.cpp
llvm/lib/Object/Archive.cpp
llvm/lib/Object/MachOObjectFile.cpp
llvm/lib/ObjectYAML/DWARFEmitter.cpp
llvm/lib/ObjectYAML/MachOYAML.cpp
llvm/lib/Target/BP

[clang-tools-extra] d768bf9 - [NFC][TargetParser] Replace uses of llvm/Support/Host.h

2023-02-10 Thread Archibald Elliott via cfe-commits

Author: Archibald Elliott
Date: 2023-02-10T09:59:46Z
New Revision: d768bf994f508d7eaf9541a568be3d71096febf5

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

LOG: [NFC][TargetParser] Replace uses of llvm/Support/Host.h

The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.

Added: 


Modified: 
clang-tools-extra/clangd/Feature.cpp
clang-tools-extra/modularize/CoverageChecker.h
clang/lib/Driver/Distro.cpp
clang/lib/Driver/Driver.cpp
clang/lib/Driver/OffloadBundler.cpp
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/lib/Driver/ToolChains/Arch/ARM.cpp
clang/lib/Driver/ToolChains/Arch/CSKY.cpp
clang/lib/Driver/ToolChains/Arch/M68k.cpp
clang/lib/Driver/ToolChains/Arch/PPC.cpp
clang/lib/Driver/ToolChains/Arch/RISCV.cpp
clang/lib/Driver/ToolChains/Arch/Sparc.cpp
clang/lib/Driver/ToolChains/Arch/SystemZ.cpp
clang/lib/Driver/ToolChains/Arch/X86.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/Cuda.cpp
clang/lib/Driver/ToolChains/MSVC.cpp
clang/lib/Frontend/CompilerInstance.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
clang/lib/Interpreter/Interpreter.cpp
clang/lib/Tooling/CompilationDatabase.cpp
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
clang/lib/Tooling/ExpandResponseFilesCompilationDatabase.cpp
clang/lib/Tooling/JSONCompilationDatabase.cpp
clang/lib/Tooling/Tooling.cpp
clang/tools/clang-import-test/clang-import-test.cpp
clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
clang/tools/clang-scan-deps/ClangScanDeps.cpp
clang/tools/driver/cc1as_main.cpp
clang/tools/driver/cc1gen_reproducer_main.cpp
clang/tools/driver/driver.cpp
clang/unittests/AST/StructuralEquivalenceTest.cpp
clang/unittests/ASTMatchers/ASTMatchersInternalTest.cpp
clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
clang/unittests/CodeGen/BufferSourceTest.cpp
clang/unittests/CodeGen/CodeGenExternalTest.cpp
clang/unittests/CodeGen/TestCompiler.h
clang/unittests/Driver/DistroTest.cpp
clang/unittests/Driver/SanitizerArgsTest.cpp
clang/unittests/Frontend/CompilerInvocationTest.cpp
clang/unittests/Interpreter/IncrementalProcessingTest.cpp
clang/unittests/Tooling/RecursiveASTVisitorTests/LambdaExpr.cpp
clang/unittests/Tooling/ToolingTest.cpp
flang/lib/Frontend/CompilerInvocation.cpp
flang/lib/Optimizer/Support/FIRContext.cpp
flang/tools/bbc/bbc.cpp
flang/tools/flang-driver/driver.cpp
flang/unittests/Frontend/FrontendActionTest.cpp
flang/unittests/Optimizer/FIRContextTest.cpp
libc/benchmarks/LibcBenchmark.cpp
lld/ELF/DriverUtils.cpp
lld/MachO/Driver.cpp
lld/MinGW/Driver.cpp
lld/tools/lld/lld.cpp
lld/wasm/Driver.cpp
lldb/source/Host/common/HostInfoBase.cpp
lldb/source/Host/freebsd/Host.cpp
lldb/source/Host/macosx/objcxx/Host.mm
lldb/source/Host/netbsd/HostNetBSD.cpp
lldb/source/Host/openbsd/Host.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.cpp
lldb/unittests/Host/HostInfoTest.cpp
lldb/utils/lit-cpuid/lit-cpuid.cpp
llvm/examples/Kaleidoscope/Chapter8/toy.cpp
llvm/examples/Kaleidoscope/Chapter9/toy.cpp
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
llvm/include/llvm/ObjectYAML/DWARFEmitter.h
llvm/include/llvm/ProfileData/InstrProf.h
llvm/include/llvm/Support/Host.h
llvm/lib/CodeGen/CommandFlags.cpp
llvm/lib/ExecutionEngine/ExecutionEngine.cpp
llvm/lib/ExecutionEngine/Orc/ExecutorProcessControl.cpp
llvm/lib/ExecutionEngine/Orc/JITTargetMachineBuilder.cpp
llvm/lib/ExecutionEngine/Orc/TargetProcess/SimpleRemoteEPCServer.cpp
llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h
llvm/lib/ExecutionEngine/TargetSelect.cpp
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/LTO/LTOModule.cpp
llvm/lib/MC/ELFObjectWriter.cpp
llvm/lib/Object/Archive.cpp
llvm/lib/Object/MachOObjectFile.cpp
llvm/lib/ObjectYAML/DWARFEmitter.cpp
llvm/lib/ObjectYAML/MachOYAML.cpp
llvm/lib/Target/BP

[PATCH] D137527: [C++20] [Modules] [ClangScanDeps] Add ClangScanDeps support for C++20 Named Modules in P1689 format (2/4)

2023-02-10 Thread Mikael Holmén via Phabricator via cfe-commits
uabelho added a comment.

Hi,

There seems to be something funny going on with the ClangScanDeps/P1689 
.cppm testcase added in this patch.

It fails randomly for me on top of tree (4ad8f7a189570 
).
Roughly 1 in 10 runs fail for me.
E.g. with a crash like

  Exit Code: 2
  
  Command Output (stderr):
  --
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace.
  #0 0x004ef8b8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x4ef8b8)
  #1 0x004ed5ae llvm::sys::RunSignalHandlers() 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x4ed5ae)
  #2 0x004f0096 SignalHandler(int) Signals.cpp:0:0
  #3 0x7f6518263630 __restore_rt sigaction.c:0:0
  #4 0x00474f40 P1689Deps::addSourcePathsToRequires() crtstuff.c:0:0
  #5 0x004666d1 P1689Deps::printDependencies(llvm::raw_ostream&) 
crtstuff.c:0:0
  #6 0x0046204a main 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x46204a)
  #7 0x7f6515996555 __libc_start_main (/lib64/libc.so.6+0x22555)
  #8 0x0045fcad _start 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x45fcad)
  FileCheck error: '' is empty.
  FileCheck command line:  
/repo/uabelho/main-github/llvm/build-all/bin/FileCheck 
/repo/uabelho/main-github/llvm/build-all/tools/clang/test/ClangScanDeps/Output/P1689.cppm.tmp/Checks.cpp
 
-DPREFIX=/repo/uabelho/main-github/llvm/build-all/tools/clang/test/ClangScanDeps/Output/P1689.cppm.tmp
  
  --
  
  
  
  Failed Tests (1):
Clang :: ClangScanDeps/P1689.cppm

or

  Exit Code: 2
  
  Command Output (stderr):
  --
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace.
   #0 0x004ef8b8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x4ef8b8)
   #1 0x004ed5ae llvm::sys::RunSignalHandlers() 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x4ed5ae)
   #2 0x004f0096 SignalHandler(int) Signals.cpp:0:0
   #3 0x7f422b33e630 __restore_rt sigaction.c:0:0
   #4 0x7f4228a85387 raise (/lib64/libc.so.6+0x36387)
   #5 0x7f4228a86a78 abort (/lib64/libc.so.6+0x37a78)
   #6 0x7f4228ac7f67 __libc_message (/lib64/libc.so.6+0x78f67)
   #7 0x7f4228ad0329 _int_free malloc.c:0:0
   #8 0x0047e7ef void 
std::vector>::_M_realloc_insert(__gnu_cxx::__normal_iterator>>, 
clang::tooling::dependencies::P1689Rule const&) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x47e7ef)
   #9 0x0047cea1 std::_Function_handler::_M_invoke(std::_Any_data const&) ClangScanDeps.cpp:0:0
  #10 0x0047ba3c std::_Function_handler)::'lambda'()>::_M_invoke(std::_Any_data const&) crtstuff.c:0:0
  #11 0x004b73e9 
llvm::ThreadPool::processTasks(llvm::ThreadPoolTaskGroup*) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x4b73e9)
  #12 0x004b8358 void* 
llvm::thread::ThreadProxy>(void*) 
ThreadPool.cpp:0:0
  #13 0x7f422b336ea5 start_thread pthread_create.c:0:0
  #14 0x7f4228b4db0d clone (/lib64/libc.so.6+0xfeb0d)
  FileCheck error: '' is empty.
  FileCheck command line:  
/repo/uabelho/main-github/llvm/build-all/bin/FileCheck 
/repo/uabelho/main-github/llvm/build-all/tools/clang/test/ClangScanDeps/Output/P1689.cppm.tmp/Checks.cpp
 
-DPREFIX=/repo/uabelho/main-github/llvm/build-all/tools/clang/test/ClangScanDeps/Output/P1689.cppm.tmp
  
  --
  
  
  
  Failed Tests (1):
Clang :: ClangScanDeps/P1689.cppm

but I've also seen things like

  *** Error in `/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps': 
corrupted size vs. prev_size: 0x7faf74000fc0 ***
  === Backtrace: =
  /lib64/libc.so.6(+0x7f474)[0x7fafa1ffa474]
  /lib64/libc.so.6(+0x8156b)[0x7fafa1ffc56b]
  /repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps[0x47e7ef]
  /repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps[0x47cea1]
  /repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps[0x47ba3c]
  /repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps[0x4b73e9]
  /repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps[0x4b8358]
  /lib64/libpthread.so.0(+0x7ea5)[0x7fafa4862ea5]
  /lib64/libc.so.6(clone+0x6d)[0x7fafa2079b0d]
  === Memory map: 
  0040-08ffa000 r-xp  fd:01 63551  
/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps
  08ffa000-09b44000 rw-p 08bf9000 fd:01 63551  
/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps
  09b44000-09bbf000 rw-p  00:00 0 
  0a86a000-0a8f3000 rw-p  00:00 0  
[heap]
  7f

[clang] baca3c1 - Move SIMD alignment calculation to LLVM Frontend

2023-02-10 Thread Dominik Adamski via cfe-commits

Author: Dominik Adamski
Date: 2023-02-10T04:11:54-06:00
New Revision: baca3c150733c89686287ba4927c351eec9695e2

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

LOG: Move SIMD alignment calculation to LLVM Frontend

Currently default simd alignment is defined by Clang specific TargetInfo class.
This class cannot be reused for LLVM Flang. That's why default simd alignment
calculation has been moved to OMPIRBuilder which is common for Flang and Clang.

Previous attempt: https://reviews.llvm.org/D138496 was wrong because
the default alignment depended on the number of built LLVM targets.

If we wanted to calculate the default alignment for PPC and we hadn't specified
PPC LLVM target to build, then we would get 0 as the alignment because
OMPIRBuilder couldn't create PPCTargetMachine object and it returned 0 as
the default value.

If PPC LLVM target had been built earlier, then OMPIRBuilder could have created
PPCTargetMachine object and it would have returned 128.

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

Reviewed By: jdoerfert

Added: 


Modified: 
clang/include/clang/Basic/TargetInfo.h
clang/lib/AST/ASTContext.cpp
clang/lib/AST/CMakeLists.txt
clang/lib/Basic/TargetInfo.cpp
clang/lib/Basic/Targets/PPC.h
clang/lib/Basic/Targets/WebAssembly.h
clang/lib/Basic/Targets/X86.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index 7b6daa0c36724..1bdee3f416a90 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -225,7 +225,6 @@ class TargetInfo : public virtual TransferrableTargetInfo,
   bool HasStrictFP;
 
   unsigned char MaxAtomicPromoteWidth, MaxAtomicInlineWidth;
-  unsigned short SimdDefaultAlign;
   std::string DataLayoutString;
   const char *UserLabelPrefix;
   const char *MCountName;
@@ -794,10 +793,6 @@ class TargetInfo : public virtual TransferrableTargetInfo,
 
   /// Return the maximum vector alignment supported for the given target.
   unsigned getMaxVectorAlign() const { return MaxVectorAlign; }
-  /// Return default simd alignment for the given target. Generally, this
-  /// value is type-specific, but this alignment can be used for most of the
-  /// types for the given target.
-  unsigned getSimdDefaultAlign() const { return SimdDefaultAlign; }
 
   unsigned getMaxOpenCLWorkGroupSize() const { return MaxOpenCLWorkGroupSize; }
 

diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index beb66543cac48..a188837d4144c 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -77,6 +77,7 @@
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/Frontend/OpenMP/OMPIRBuilder.h"
 #include "llvm/Support/Capacity.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/Compiler.h"
@@ -2539,7 +2540,8 @@ unsigned ASTContext::getTypeUnadjustedAlign(const Type 
*T) const {
 }
 
 unsigned ASTContext::getOpenMPDefaultSimdAlign(QualType T) const {
-  unsigned SimdAlign = getTargetInfo().getSimdDefaultAlign();
+  unsigned SimdAlign = llvm::OpenMPIRBuilder::getOpenMPDefaultSimdAlign(
+  getTargetInfo().getTriple(), Target->getTargetOpts().FeatureMap);
   return SimdAlign;
 }
 

diff  --git a/clang/lib/AST/CMakeLists.txt b/clang/lib/AST/CMakeLists.txt
index 3d8d8cc077615..0b737626a2201 100644
--- a/clang/lib/AST/CMakeLists.txt
+++ b/clang/lib/AST/CMakeLists.txt
@@ -132,4 +132,5 @@ add_clang_library(clangAST
   ClangAttrDocTable
   Opcodes
   omp_gen
+  intrinsics_gen
   )

diff  --git a/clang/lib/Basic/TargetInfo.cpp b/clang/lib/Basic/TargetInfo.cpp
index 70a15eb68f4ea..07af6c07031bd 100644
--- a/clang/lib/Basic/TargetInfo.cpp
+++ b/clang/lib/Basic/TargetInfo.cpp
@@ -119,7 +119,6 @@ TargetInfo::TargetInfo(const llvm::Triple &T) : Triple(T) {
   MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 0;
   MaxVectorAlign = 0;
   MaxTLSAlign = 0;
-  SimdDefaultAlign = 0;
   SizeType = UnsignedLong;
   PtrDiffType = SignedLong;
   IntMaxType = SignedLongLong;

diff  --git a/clang/lib/Basic/Targets/PPC.h b/clang/lib/Basic/Targets/PPC.h
index ebf0c2d0506d8..79f5d6e8c720b 100644
--- a/clang/lib/Basic/Targets/PPC.h
+++ b/clang/lib/Basic/Targets/PPC.h
@@ -87,7 +87,6 @@ class LLVM_LIBRARY_VISIBILITY PPCTargetInfo : public 
TargetInfo {
   PPCTargetInfo(const llvm::Triple &Triple, const TargetOptions &)
   : TargetInfo(Triple) {
 SuitableAlign = 128;
-SimdDefaultAlign = 128;
 LongDoubleWidth = LongDoubleAlign = 128;
 LongDoubleFormat = &llvm::APFloat::PPCD

[PATCH] D141910: [OpenMP][OMPIRBuilder]Move SIMD alignment calculation to LLVM Frontend

2023-02-10 Thread Dominik Adamski via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbaca3c150733: Move SIMD alignment calculation to LLVM 
Frontend (authored by domada).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141910

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/CMakeLists.txt
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/PPC.h
  clang/lib/Basic/Targets/WebAssembly.h
  clang/lib/Basic/Targets/X86.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp

Index: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+++ llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
@@ -3053,6 +3053,23 @@
   Builder.CreateBr(NewBlocks.front());
 }
 
+unsigned
+OpenMPIRBuilder::getOpenMPDefaultSimdAlign(const Triple &TargetTriple,
+   const StringMap &Features) {
+  if (TargetTriple.isX86()) {
+if (Features.lookup("avx512f"))
+  return 512;
+else if (Features.lookup("avx"))
+  return 256;
+return 128;
+  }
+  if (TargetTriple.isPPC())
+return 128;
+  if (TargetTriple.isWasm())
+return 128;
+  return 0;
+}
+
 void OpenMPIRBuilder::applySimd(CanonicalLoopInfo *CanonicalLoop,
 MapVector AlignedVars,
 Value *IfCond, OrderKind Order,
Index: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
===
--- llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
+++ llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
@@ -502,6 +502,13 @@
ArrayRef Loops,
InsertPointTy ComputeIP);
 
+  /// Get the default alignment value for given target
+  ///
+  /// \param TargetTriple   Target triple
+  /// \param Features   StringMap which describes extra CPU features
+  static unsigned getOpenMPDefaultSimdAlign(const Triple &TargetTriple,
+const StringMap &Features);
+
 private:
   /// Modifies the canonical loop to be a statically-scheduled workshare loop.
   ///
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -500,8 +500,6 @@
   auto target_info = TargetInfo::CreateTargetInfo(
   m_compiler->getDiagnostics(), m_compiler->getInvocation().TargetOpts);
   if (log) {
-LLDB_LOGF(log, "Using SIMD alignment: %d",
-  target_info->getSimdDefaultAlign());
 LLDB_LOGF(log, "Target datalayout string: '%s'",
   target_info->getDataLayoutString());
 LLDB_LOGF(log, "Target ABI: '%s'", target_info->getABI().str().c_str());
Index: clang/lib/Basic/Targets/X86.cpp
===
--- clang/lib/Basic/Targets/X86.cpp
+++ clang/lib/Basic/Targets/X86.cpp
@@ -400,9 +400,6 @@
 return false;
   }
 
-  SimdDefaultAlign =
-  hasFeature("avx512f") ? 512 : hasFeature("avx") ? 256 : 128;
-
   // FIXME: We should allow long double type on 32-bits to match with GCC.
   // This requires backend to be able to lower f80 without x87 first.
   if (!HasX87 && LongDoubleFormat == &llvm::APFloat::x87DoubleExtended())
Index: clang/lib/Basic/Targets/WebAssembly.h
===
--- clang/lib/Basic/Targets/WebAssembly.h
+++ clang/lib/Basic/Targets/WebAssembly.h
@@ -49,7 +49,6 @@
 SuitableAlign = 128;
 LargeArrayMinWidth = 128;
 LargeArrayAlign = 128;
-SimdDefaultAlign = 128;
 SigAtomicType = SignedLong;
 LongDoubleWidth = LongDoubleAlign = 128;
 LongDoubleFormat = &llvm::APFloat::IEEEquad();
Index: clang/lib/Basic/Targets/PPC.h
===
--- clang/lib/Basic/Targets/PPC.h
+++ clang/lib/Basic/Targets/PPC.h
@@ -87,7 +87,6 @@
   PPCTargetInfo(const llvm::Triple &Triple, const TargetOptions &)
   : TargetInfo(Triple) {
 SuitableAlign = 128;
-SimdDefaultAlign = 128;
 LongDoubleWidth = LongDoubleAlign = 128;
 LongDoubleFormat = &llvm::APFloat::PPCDoubleDouble();
 HasStrictFP = true;
Index: clang/lib/Basic/TargetInfo.cpp
===
--- clang/lib/Basic/TargetInfo.cpp
+++ clang/lib/Basic/TargetInfo.cpp
@@ -119,7 +119,6 @@
   MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 0;
   MaxVectorAlign = 0;
   MaxTLSAlign = 0;
-  SimdDefaultAlign = 0;
   SizeType = UnsignedLong;
   PtrDiffType = S

[clang] bb8bd8c - [SanitizerBinaryMetadata] Fix ignorelist test under Windows

2023-02-10 Thread Marco Elver via cfe-commits

Author: Marco Elver
Date: 2023-02-10T11:24:25+01:00
New Revision: bb8bd8c232e893441937d057a8b32760065c6e1d

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

LOG: [SanitizerBinaryMetadata] Fix ignorelist test under Windows

Windows paths confuse the regular expression. Just use the test source
name directly.

Fixes: 421215b919d0 ("[SanitizerBinaryMetadata] Support ignore list")

Added: 


Modified: 
clang/test/CodeGen/sanitize-metadata-ignorelist.c

Removed: 




diff  --git a/clang/test/CodeGen/sanitize-metadata-ignorelist.c 
b/clang/test/CodeGen/sanitize-metadata-ignorelist.c
index 9cc9215a9e43..1458b681672c 100644
--- a/clang/test/CodeGen/sanitize-metadata-ignorelist.c
+++ b/clang/test/CodeGen/sanitize-metadata-ignorelist.c
@@ -1,7 +1,7 @@
 // RUN: %clang -O -fexperimental-sanitize-metadata=all -target 
x86_64-gnu-linux -x c -S -emit-llvm %s -o - | FileCheck %s 
--check-prefixes=ALLOW
 // RUN: echo "fun:foo" > %t.fun
 // RUN: %clang -O -fexperimental-sanitize-metadata=all 
-fexperimental-sanitize-metadata-ignorelist=%t.fun -target x86_64-gnu-linux -x 
c -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=FUN
-// RUN: echo "src:%s" > %t.src
+// RUN: echo "src:*sanitize-metadata-ignorelist.c" > %t.src
 // RUN: %clang -O -fexperimental-sanitize-metadata=all 
-fexperimental-sanitize-metadata-ignorelist=%t.src -target x86_64-gnu-linux -x 
c -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=SRC
 
 int y;



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


[PATCH] D142893: [NFC] Class for building MultilibSet

2023-02-10 Thread Peter Smith via Phabricator via cfe-commits
peter.smith added a comment.

Thanks for the updates, I'm happy with the changes and don't have any more 
comments. Happy to give my implicit approval.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142893

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


[PATCH] D142905: Change multilib selection algorithm

2023-02-10 Thread Peter Smith via Phabricator via cfe-commits
peter.smith added a comment.

Thanks for the updates, I'm happy with the changes and don't have any more 
comments. Happy to give my implicit approval.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142905

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


[PATCH] D143342: [clang-tidy] Support std::format and std::print in readability-redundant-string-cstr

2023-02-10 Thread Mike Crowe via Phabricator via cfe-commits
mikecrowe added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/RedundantStringCStrCheck.cpp:188
+  callee(functionDecl(hasName("::std::format",
+hasAnyArgument(materializeTemporaryExpr(
+has(StringCStrCallExpr),

njames93 wrote:
> The limitation about only transforming the first argument can be alleviated 
> by using the `forEachArgumentWithParam` matcher
Thanks for the hint. I did try to overcome this limitation but failed to find 
`forEachArgumentWithParam`.

I think that I've managed to make `forEachArgumentWithParam` work, but only if 
I lose the `materializeTemporaryExpr`. I hope that's not essential. I've ended 
up with:

```C++
  Finder->addMatcher(   

   
traverse(TK_AsIs,   

   
 callExpr(callee(functionDecl(hasAnyName("::std::print", 
"::std::format"))), 
  
  forEachArgumentWithParam(StringCStrCallExpr, 
parmVarDecl(,   

this);  

   
```
I suspect that there's something better than the `parmVarDecl()` second 
parameter to `forEachArgumentWithParam` though.


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

https://reviews.llvm.org/D143342

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


[PATCH] D142986: Enable multilib.yaml in the BareMetal ToolChain

2023-02-10 Thread Peter Smith via Phabricator via cfe-commits
peter.smith added a comment.

Looks good to me. Some small suggestions around execute-only as I expect this 
to be a useful multilib variant.




Comment at: clang/lib/Driver/ToolChain.cpp:198
   unsigned FPUKind = llvm::ARM::FK_INVALID;
-  tools::arm::getARMTargetFeatures(D, Triple, Args, Features, false, &FPUKind);
+  tools::arm::getARMTargetFeatures(D, Triple, Args, Features, false, false,
+   &FPUKind);

Now that there are two boolean parameters, could you put a prefix comment to 
show which one is which for example:
/* ForAs */ false, /* GenExecuteOnly */ 



Comment at: clang/lib/Driver/ToolChains/Arch/ARM.cpp:779
   // This only makes sense for the compiler, not for the assembler.
-  if (!ForAS) {
+  if (!ForAS && GetExecuteOnly) {
 // Supported only on ARMv6T2 and ARMv7 and above.

I can see execute-only being used in a multilib configuration as it can impact 
code-generation significantly yet is a requirement for a system aiming to have 
all code execute-only.

Rather than a specific `GenExecuteOnly` flag, would it be better for something 
like `ForMultilib`  like `ForAS` and then we could move it to not give the 
error message when doing `ForMultilib` the name would also generalise to other 
parts.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142986

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


[PATCH] D143587: [Docs] Multilib design

2023-02-10 Thread Michael Platings via Phabricator via cfe-commits
michaelplatings updated this revision to Diff 496415.
michaelplatings marked 7 inline comments as done.
michaelplatings added a comment.

Incorporate suggestions from @peter.smith


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143587

Files:
  clang/docs/Multilib.rst
  clang/docs/index.rst

Index: clang/docs/index.rst
===
--- clang/docs/index.rst
+++ clang/docs/index.rst
@@ -100,6 +100,7 @@
CodeOwners
InternalsManual
DriverInternals
+   Multilib
OffloadingDesign
PCHInternals
ItaniumMangleAbiTags
Index: clang/docs/Multilib.rst
===
--- /dev/null
+++ clang/docs/Multilib.rst
@@ -0,0 +1,320 @@
+
+Multilib
+
+
+Introduction
+
+
+This document describes how multilib is implemented in Clang.
+
+What is multilib and why might you care?
+If you're :doc:`cross compiling` then you can't use native
+system headers and libraries. To address this, you can use a combination of
+``--sysroot``, ``-isystem`` and ``-L`` options to point clang at suitable
+directories for your target.
+However, when there are many possible directories to choose from, it's not
+necessarily obvious which one to pick.
+Multilib allows a toolchain designer to imbue the toolchain with the ability to
+pick a suitable directory automatically, based on the options the user provides
+to clang. For example, if the user specifies
+``--target=arm-none-eabi -mcpu=cortex-m4`` the toolchain can choose a directory
+containing headers and libraries suitable for Armv7E-M, because it knows that's
+a suitable architecture for Arm Cortex-M4.
+Multilib can also choose between libraries for the same architecture based on
+other options. For example if the user specifies ``-fno-exceptions`` then a
+toolchain could select libraries built without exception support, thereby
+reducing the size of the resulting binary.
+
+Design
+==
+
+Clang supports GCC's ``-print-multi-lib`` and ``-print-multi-directory``
+options. These are described in
+`GCC Developer Options `_.
+
+There are two ways to configure multilib in Clang: hard-coded or via a
+configuration file.
+
+Hard-coded Multilib
+===
+
+The available libraries can be hard-coded in clang. Typically this is done
+using the ``MultilibBuilder`` interface. There are many examples of this in
+``Gnu.cpp``.
+The remainder of this document will not focus on this type of multilib.
+
+Multilib via configuration file
+===
+
+Some clang toolchains support loading multilib configuration from a
+``multilib.yaml`` configuration file.
+
+A ``multilib.yaml`` configuration file specifies which multilib variants are
+available, their relative location, what compilation options were used to build
+them, and the criteria by which they are selected.
+
+Multilib processing
+===
+
+Clang goes through the following steps to use multilib from a configuration
+file:
+#. Convert command line arguments to flags. Clang can accept the same
+   information via different arguments - for example,
+   ``--target=arm-none-eabi -march=armv7-m`` and
+   ``--target=armv7m-none-eabi`` are equivalent. Clang can also accept many
+   independent pieces of information within a single flag - for example
+   ``-march=armv8.1m.main+fp+mve`` specifies the architecture and two
+   extensions in a single command line argument.
+   To make it easier for the multilib system, clang converts the command line
+   arguments into a standard set of simpler "flags". In many cases these flags
+   will look like a command line argument with the leading ``-`` stripped off,
+   but where a suitable form for the flag doesn't exist in command line
+   arguments then its form will be different. For example, an Arm architecture
+   extension is represented like ``march=+mve`` since there's no way to specify
+   it in isolation in a command line argument.
+   To see what flags are emitted for a given set of command line arguments, use
+   the ``-print-multi-selection-flags-experimental`` command line argument
+   along with the rest of the arguments you want to use.
+#. Load ``multilib.yaml`` from sysroot.
+#. Generate additional flags. ``multilib.yaml`` contains a ``flagMap`` section,
+   which specifies how to generate additional flags based on the flags derived
+   from command line arguments. Flags are matched using regular expressions.
+   These regular expressions shall use the POSIX extended regular expression
+   syntax.
+#. Match flags against multilib variants. If the generated flags are a superset
+   of the flags specified for a multilib variant then the variant is considered
+   a match.
+   If more than one variant matches then a toolchain may opt to either use only
+   the *las

[PATCH] D143587: [Docs] Multilib design

2023-02-10 Thread Michael Platings via Phabricator via cfe-commits
michaelplatings added a comment.

> Could be worth adding a design principles section at the end

That was a very helpful suggestion, thank you. Writing them out helped me 
examine the compatibility story more carefully. Consequently I added a 
requirement for a "minimumClangVersion" property, although I haven't 
implemented that in the other patches yet.

> May be worth a quick description of how we might model some awkward cases

Not done yet. This certainly can be modelled but I agree an example would be 
helpful to provide.




Comment at: clang/docs/Multilib.rst:105
+
+This decision is hard-coded per ToolChain subclass.
+

peter.smith wrote:
> Considering the BareMetal ToolChain is used by RISC-V, Arm and AArch64 is 
> there scope for a different choice per toolchain. I guess that we could put a 
> predicate function for the ToolChain that could change due to architecture.
For the BareMetal ToolChain the only one RISC-V multilibs can ever match a 
given set of command line options so this isn't a problem in practice.



Comment at: clang/docs/Multilib.rst:122
+``-fno-exceptions`` multilib variant need only contain C++ libraries.
+
+Stability

peter.smith wrote:
> Although it can be worked out by looking at the example, which I think is 
> your intention from the comment. It may be worth a section on Syntax that 
> extracts some of these.
> ```
> Syntax of multilib.yaml
> ===
> ```
> Some suggestions/questions:
> * Does the file have to contain both variants: and flagmap: are either of 
> them optional?
> * Do variants have to come before flagmap, or is order not important.
> * Will be worth highlighting that the order of the variants may be 
> significant depending on the toolchain.
> * Each variant is made up of dir: (path added to sysroot?), flags: [comma 
> separated list of flags] and printArgs: [comma separated list of command line 
> options for -print-multi-lib and -print-multi-directory, but not important 
> for multilib selection]
> * Each flagmap is made up of a POSIX extended syntax regex: that matches a 
> flag, and (one of?) matchFlags/noMatchFlags which either adds or removes 
> respecively a [comma separated list of flags] 
I opted to keep the spec, such as it is, in the example, but I've expanded it 
to answer your questions, unless it's implicit in it being YAML (e.g. lists 
//can// be comma separated but there are other ways to express them in YAML).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143587

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


[PATCH] D143059: [NFC] Enable selecting multiple multilibs

2023-02-10 Thread Peter Smith via Phabricator via cfe-commits
peter.smith added a comment.

A couple of small suggestions but otherwise looks good to me.




Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:233
+  std::string Result = computeBaseSysRoot(getDriver(), getTriple());
+  if (!SelectedMultilibs.empty()) {
+Result += SelectedMultilibs.back().osSuffix();

Nit: the braces can be omitted here. No strong opinion as it may be better to 
keep consistency with the rest of the file rather than LLVM as a whole.

https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements



Comment at: clang/lib/Driver/ToolChains/Fuchsia.cpp:319
+SelectedMultilibs.erase(SelectedMultilibs.begin(),
+SelectedMultilibs.end() - 1);
+

SelectedMultilibs.end() - 1 makes me a little nervous. This will work for the 
current container type (I think the standard requires it for vector and I don't 
think SmallVector would deviate from it. However in the unlikely event that the 
container changes and this isn't valid then this could break.

Perhaps use std::advance(SelectedMultilibs.end(), -1) which is more likely to 
break at compile time if this occurs.

Alternatively if this is just erasing all but the last element, maybe extract 
it, clear the container and reinsert.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143059

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


[PATCH] D143725: [llvm-objdump][ARM] support --symbolize-operands for ARM/ELF

2023-02-10 Thread Nam Cao via Phabricator via cfe-commits
covanam created this revision.
covanam added reviewers: shchenz, rlavaee, jhenderson, hoyFB, MaskRay, 
llvm-commits, cfe-commits.
Herald added subscribers: kristof.beyls, emaste.
Herald added a project: All.
covanam requested review of this revision.
Herald added a project: LLVM.

Support --symbolize-operands on ARM/Thumb architecture.
Only support ELF object files for now.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143725

Files:
  llvm/docs/CommandGuide/llvm-objdump.rst
  llvm/test/tools/llvm-objdump/ELF/ARM/symbolize-operand-arm.s
  llvm/test/tools/llvm-objdump/ELF/ARM/symbolize-operand-thumb.s
  llvm/tools/llvm-objdump/llvm-objdump.cpp

Index: llvm/tools/llvm-objdump/llvm-objdump.cpp
===
--- llvm/tools/llvm-objdump/llvm-objdump.cpp
+++ llvm/tools/llvm-objdump/llvm-objdump.cpp
@@ -1141,8 +1141,10 @@
 ArrayRef Bytes, const MCInstrAnalysis *MIA, MCDisassembler *DisAsm,
 MCInstPrinter *IP, const MCSubtargetInfo *STI, uint64_t SectionAddr,
 uint64_t Start, uint64_t End, std::unordered_map &Labels) {
-  // So far only supports PowerPC and X86.
-  if (!STI->getTargetTriple().isPPC() && !STI->getTargetTriple().isX86())
+  // So far only supports ARM/Thumb, PowerPC and X86.
+  Triple triple = STI->getTargetTriple();
+  if (!triple.isPPC() && !triple.isX86() && !triple.isARM() &&
+  !triple.isThumb())
 return;
 
   Labels.clear();
@@ -1164,11 +1166,14 @@
 if (Disassembled && MIA) {
   uint64_t Target;
   bool TargetKnown = MIA->evaluateBranch(Inst, Index, Size, Target);
-  // On PowerPC, if the address of a branch is the same as the target, it
-  // means that it's a function call. Do not mark the label for this case.
+  // On PowerPC and ARM/Thumb, if the address of a branch is the same as
+  // the target, it means that it's a function call. Do not mark the label
+  // for this case.
+  bool isFunctionCall =
+  Target == Index &&
+  (triple.isPPC() || triple.isARM() || triple.isThumb());
   if (TargetKnown && (Target >= Start && Target < End) &&
-  !Labels.count(Target) &&
-  !(STI->getTargetTriple().isPPC() && Target == Index))
+  !Labels.count(Target) && !isFunctionCall)
 Labels[Target] = ("L" + Twine(LabelCount++)).str();
 }
 Index += Size;
Index: llvm/test/tools/llvm-objdump/ELF/ARM/symbolize-operand-thumb.s
===
--- /dev/null
+++ llvm/test/tools/llvm-objdump/ELF/ARM/symbolize-operand-thumb.s
@@ -0,0 +1,37 @@
+@ RUN: llvm-mc %s -triple=thumbv7m -filetype=obj | \
+@ RUN:   llvm-objdump --symbolize-operands --no-show-raw-insn -d --triple=thumbv7m - | \
+@ RUN:   FileCheck %s
+
+.text
+foo:
+@ CHECK:   :
+
+@@ Check symbolize local branch
+  b .L0
+  beq.w .L1
+  b .L2
+.L0:
+  b .L2
+  bne .L1
+  b.w .L0
+.L2:
+  b.w .L1
+  b .L2
+.L1:
+  b.w .L0
+@ CHECK-NEXT:  0:   b	0x8  @ imm = #0x4
+@ CHECK-NEXT:  2:   beq.w 0x16 @ imm = #0x10
+@ CHECK-NEXT:  6:   b 0x10 @ imm = #0x6
+@ CHECK-NEXT: :
+@ CHECK-NEXT:  8:   b 0x10 @ imm = #0x4
+@ CHECK-NEXT:  a:   bne   0x16 @ imm = #0x8
+@ CHECK-NEXT:  c:   b.w0x8 @ imm = #-0x8
+@ CHECK-NEXT: :
+@ CHECK-NEXT: 10:   b.w   0x16 @ imm = #0x2
+@ CHECK-NEXT: 14:   b 0x10 @ imm = #-0x8
+@ CHECK-NEXT: :
+@ CHECK-NEXT: 16:   b.w0x8 @ imm = #-0x12
+
+@@ Check function calls are not symbolized
+  bl bar
+@ CHECK-NEXT: 1a:   bl 0x1a  @ imm = #-0x4
Index: llvm/test/tools/llvm-objdump/ELF/ARM/symbolize-operand-arm.s
===
--- /dev/null
+++ llvm/test/tools/llvm-objdump/ELF/ARM/symbolize-operand-arm.s
@@ -0,0 +1,38 @@
+@ RUN: llvm-mc %s -triple=armv8 -filetype=obj | \
+@ RUN:   llvm-objdump --symbolize-operands --no-show-raw-insn -d --triple=armv8 - | \
+@ RUN:   FileCheck %s
+
+.text
+foo:
+@ CHECK:   :
+
+@@ Check symbolize local branch
+  b .L0
+.L4:
+  beq .L1
+.L0:
+  b .L2
+  ble .L3
+.L2:
+  b .L3
+.L1:
+  b .L0
+.L3:
+  b .L4
+@ CHECK-NEXT:  0:   b   0x8 @ imm = #0x0
+@ CHECK-NEXT: :
+@ CHECK-NEXT:  4:   beq 0x14@ imm = #0x8
+@ CHECK-NEXT: :
+@ CHECK-NEXT:  8:   b	  0x10@ imm = #0x0
+@ CHECK-NEXT:  c:   ble	0x18@ imm = #0x4
+@ CHECK-NEXT: :
+@ CHECK-NEXT: 10:   b   0x18@ imm = #0x0
+@ CHECK-NEXT: :
+@ CHECK-NEXT: 14:   b   0x8 @ imm = #-0x14
+@ CHECK-NEXT: :
+@ CHECK-NEXT: 18:   b   0x4 @ imm = #-0x1c
+
+
+@@ Check function calls are not symbolized
+  bl bar
+@ CHECK-NEXT: 1c:   bl	0x1c  @ imm = #-0x8
Index: llvm/docs/CommandGuide/llvm-objdump.rst
===
--- llvm/docs/CommandGuide/llvm-objdump.rst
+++ llvm/docs/CommandGuide/llvm-objdump.rst
@@ -260,7 +260,7 @@
 
   When a bb-address-map section is present (i.e., the object file is built with ``-fbasic-block-s

[clang] 5cec69b - [clang] Update Clang version from 16 to 17 in scan-build.1.

2023-02-10 Thread Frederic Cambus via cfe-commits

Author: Frederic Cambus
Date: 2023-02-10T13:50:39+01:00
New Revision: 5cec69bb43bc375dabe0d26e9a7aee1c71d00d3f

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

LOG: [clang] Update Clang version from 16 to 17 in scan-build.1.

Similar to D110763.

Added: 


Modified: 
clang/tools/scan-build/man/scan-build.1

Removed: 




diff  --git a/clang/tools/scan-build/man/scan-build.1 
b/clang/tools/scan-build/man/scan-build.1
index 10593dc1cd92e..ffa3c048fdb55 100644
--- a/clang/tools/scan-build/man/scan-build.1
+++ b/clang/tools/scan-build/man/scan-build.1
@@ -2,9 +2,9 @@
 .\" See https://llvm.org/LICENSE.txt for license information.
 .\" SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 .\" $Id$
-.Dd Aug 1, 2022
+.Dd Feb 10, 2022
 .Dt SCAN-BUILD 1
-.Os "clang" "16"
+.Os "clang" "17"
 .Sh NAME
 .Nm scan-build
 .Nd Clang static analyzer



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


[PATCH] D143638: [clangd] Move function body to out-of-line: unnamed class method incorrect moving

2023-02-10 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet accepted this revision.
kadircet added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp:89
+  // Not available on methods of unnamed classes.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {

nit: i think you can group all these 3 tests.

```
// Not available if any of the parent context is unnamed, as we can't spell it.
EXPECT_UNAVAILABLE(R"cpp(
struct Foo {
  struct { 
 void b^ar() {}
 struct Baz { void b^ar() {} };
  } Bar;
};
namespace {
  struct Foo { void f^oo() {} };
}
)cpp");
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143638

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


[PATCH] D139168: [C++20] [Modules] [ClangScanDeps] Enable to print make-style dependency file within P1689 format (4/4)

2023-02-10 Thread Tom Weaver via Phabricator via cfe-commits
TWeaver added a comment.

@ChuanqiXu Hi there, the revert of this patch has caused the following buildbot 
to start failing:

https://lab.llvm.org/buildbot/#/builders/192/builds/267

It looks as though the removal of the // REQUIRES: !system-windows has caused 
the test to start running, and therefore failing, on Windows builds.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139168

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


[PATCH] D138702: support for HIP non hostcall printf

2023-02-10 Thread Vikram Hegde via Phabricator via cfe-commits
vikramRH abandoned this revision.
vikramRH added a comment.

A new implentation is under discussion


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138702

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


[PATCH] D143194: [clang][analyzer] Make messages of StdCLibraryFunctionsChecker user-friendly

2023-02-10 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

A small nit, otherwise LGTM.

In D143194#4112538 , @balazske wrote:

> Probably it is not always useful to explain why the argument is wrong. In 
> cases when we can find out that the value is exactly between two consecutive 
> valid ranges we can display a note, or when the exact value is known. 
> Otherwise it may end up in something like "the value should be between 1 and 
> 4 or between 6 and 10, but it is less than 1 or exactly 5 or greater than 10".

You're totally right. I'm not sure how to approach tricky cases like that 
either.

> The "good" cases are (when more information is available): "the value is less 
> than 1", "the value is 5", "the value is greater than 10". If two bad ranges 
> are known it may be OK too: "the value is less than 1 or it is exactly 5". 
> The explanation may be possible to implement by test assumes for the negated 
> ranges.

Maybe we can start out with the easier cases, but we should check whether there 
is a checker that solves a different problem, and should try to aim at a 
somewhat general, reusable solution.




Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:95
+QualType ArgT, BasicValueFactory &BVF,
+DescString &Out);
+  /// Append textual description of a numeric range out of [RMin,RMax] to the

Using a `raw_ostream` as a parameter sounds more elegant than a `SmallString` 
with a precise stack buffer length. Not to mention that you could call this 
function with `llvm::errs()` for easy debugging.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:100
+   QualType ArgT, BasicValueFactory &BVF,
+   DescString &Out);
 

Here as well.



Comment at: 
clang/test/Analysis/std-c-library-functions-arg-constraints-notes.cpp:51-79
+int __single_val_0(int);  // [0, 0]
 int __single_val_1(int);  // [1, 1]
 int __range_1_2(int); // [1, 2]
-int __range_1_2__4_5(int);// [1, 2], [4, 5]
-void test_range(int x) {
-__single_val_1(2); // \
-// expected-note{{The 1st argument should be within the range [1, 1]}} \
-// expected-warning{{}}
-}
-// Do more specific check against the range strings.
+int __range_m1_1(int); // [-1, 1]
+int __range_m2_m1(int); // [-2, -1]
+int __range_m10_10(int); // [-10, 10]
+int __range_m1_inf(int); // [-1, inf]

Please clang-format the changes in this test file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143194

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


[PATCH] D137526: [C++20] [Modules] [NFC] Add Preprocessor methods for named modules - for ClangScanDeps (1/4)

2023-02-10 Thread Nico Weber via Phabricator via cfe-commits
thakis added inline comments.



Comment at: clang/unittests/Lex/CMakeLists.txt:21
   clangBasic
+  clangFrontend
   clangLex

It seems strange layering-wise that the Lex unit tests would depend on 
Frontend. Is there any way to prevent that dep?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137526

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


[PATCH] D143560: clang-format.el: fix warnings

2023-02-10 Thread David Truby via Phabricator via cfe-commits
DavidTruby accepted this revision.
DavidTruby added a comment.

LGTM


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

https://reviews.llvm.org/D143560

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


[clang-tools-extra] b252824 - [clangd] fix wrong CalleeArgInfo in the hover

2023-02-10 Thread via cfe-commits

Author: v1nh1shungry
Date: 2023-02-10T22:16:16+08:00
New Revision: b252824e6e6ee0959051841e583860ba7ed1cd67

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

LOG: [clangd] fix wrong CalleeArgInfo in the hover

```
void foobar(int);
int main() {
  foobar(1 + 2);
   ^
}
```

Currently the CalleeArgInfo will be "Passed by reference", which should
be "Passed by value".

Fixes https://github.com/clangd/clangd/issues/1467

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

Added: 


Modified: 
clang-tools-extra/clangd/Hover.cpp
clang-tools-extra/clangd/unittests/HoverTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Hover.cpp 
b/clang-tools-extra/clangd/Hover.cpp
index 8649ddc9479ed..1a51614bb9d45 100644
--- a/clang-tools-extra/clangd/Hover.cpp
+++ b/clang-tools-extra/clangd/Hover.cpp
@@ -952,6 +952,15 @@ void addLayoutInfo(const NamedDecl &ND, HoverInfo &HI) {
   }
 }
 
+HoverInfo::PassType::PassMode getPassMode(QualType ParmType) {
+  if (ParmType->isReferenceType()) {
+if (ParmType->getPointeeType().isConstQualified())
+  return HoverInfo::PassType::ConstRef;
+return HoverInfo::PassType::Ref;
+  }
+  return HoverInfo::PassType::Value;
+}
+
 // If N is passed as argument to a function, fill HI.CalleeArgInfo with
 // information about that argument.
 void maybeAddCalleeArgInfo(const SelectionTree::Node *N, HoverInfo &HI,
@@ -972,14 +981,19 @@ void maybeAddCalleeArgInfo(const SelectionTree::Node *N, 
HoverInfo &HI,
   if (!FD || FD->isOverloadedOperator() || FD->isVariadic())
 return;
 
+  HoverInfo::PassType PassType;
+
   // Find argument index for N.
   for (unsigned I = 0; I < CE->getNumArgs() && I < FD->getNumParams(); ++I) {
 if (CE->getArg(I) != OuterNode.ASTNode.get())
   continue;
 
 // Extract matching argument from function declaration.
-if (const ParmVarDecl *PVD = FD->getParamDecl(I))
+if (const ParmVarDecl *PVD = FD->getParamDecl(I)) {
   HI.CalleeArgInfo.emplace(toHoverInfoParam(PVD, PP));
+  if (N == &OuterNode)
+PassType.PassBy = getPassMode(PVD->getType());
+}
 break;
   }
   if (!HI.CalleeArgInfo)
@@ -988,14 +1002,9 @@ void maybeAddCalleeArgInfo(const SelectionTree::Node *N, 
HoverInfo &HI,
   // If we found a matching argument, also figure out if it's a
   // [const-]reference. For this we need to walk up the AST from the arg itself
   // to CallExpr and check all implicit casts, constructor calls, etc.
-  HoverInfo::PassType PassType;
   if (const auto *E = N->ASTNode.get()) {
 if (E->getType().isConstQualified())
   PassType.PassBy = HoverInfo::PassType::ConstRef;
-
-// No implicit node, literal passed by value
-if (isLiteral(E) && N->Parent == OuterNode.Parent)
-  PassType.PassBy = HoverInfo::PassType::Value;
   }
 
   for (auto *CastNode = N->Parent;
@@ -1067,9 +1076,8 @@ const NamedDecl *pickDeclToUse(llvm::ArrayRef Candidates) {
   // template  void bar() { fo^o(T{}); }
   // we actually want to show the using declaration,
   // it's not clear which declaration to pick otherwise.
-  auto BaseDecls = llvm::make_filter_range(Candidates, [](const NamedDecl *D) {
-return llvm::isa(D);
-  });
+  auto BaseDecls = llvm::make_filter_range(
+  Candidates, [](const NamedDecl *D) { return llvm::isa(D); });
   if (std::distance(BaseDecls.begin(), BaseDecls.end()) == 1)
 return *BaseDecls.begin();
 

diff  --git a/clang-tools-extra/clangd/unittests/HoverTests.cpp 
b/clang-tools-extra/clangd/unittests/HoverTests.cpp
index 7fbb8858c3f45..211fd1311c98f 100644
--- a/clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ b/clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -900,6 +900,27 @@ class Foo final {})cpp";
  HI.CalleeArgInfo->Type = "int &";
  HI.CallPassType = HoverInfo::PassType{PassMode::Ref, false};
}},
+  {
+  R"cpp(
+  void foobar(const float &arg);
+  int main() {
+int a = 0;
+foobar([[^a]]);
+  }
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "a";
+HI.Kind = index::SymbolKind::Variable;
+HI.NamespaceScope = "";
+HI.Definition = "int a = 0";
+HI.LocalScope = "main::";
+HI.Value = "0";
+HI.Type = "int";
+HI.CalleeArgInfo.emplace();
+HI.CalleeArgInfo->Name = "arg";
+HI.CalleeArgInfo->Type = "const float &";
+HI.CallPassType = HoverInfo::PassType{PassMode::Value, true};
+  }},
   {// Literal passed to function call
R"cpp(
   void fun(int arg_a, const int &arg_b) {};
@@ -934,6 +955,38 @@ class Foo final {})cpp";
  HI.CalleeArgInfo->Type = "const int &";
  HI.CallPassTyp

[PATCH] D142014: [clangd] fix wrong CalleeArgInfo in the hover

2023-02-10 Thread Vincent Hong via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGb252824e6e6e: [clangd] fix wrong CalleeArgInfo in the hover 
(authored by v1nh1shungry).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142014

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp

Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -900,6 +900,27 @@
  HI.CalleeArgInfo->Type = "int &";
  HI.CallPassType = HoverInfo::PassType{PassMode::Ref, false};
}},
+  {
+  R"cpp(
+  void foobar(const float &arg);
+  int main() {
+int a = 0;
+foobar([[^a]]);
+  }
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "a";
+HI.Kind = index::SymbolKind::Variable;
+HI.NamespaceScope = "";
+HI.Definition = "int a = 0";
+HI.LocalScope = "main::";
+HI.Value = "0";
+HI.Type = "int";
+HI.CalleeArgInfo.emplace();
+HI.CalleeArgInfo->Name = "arg";
+HI.CalleeArgInfo->Type = "const float &";
+HI.CallPassType = HoverInfo::PassType{PassMode::Value, true};
+  }},
   {// Literal passed to function call
R"cpp(
   void fun(int arg_a, const int &arg_b) {};
@@ -934,6 +955,38 @@
  HI.CalleeArgInfo->Type = "const int &";
  HI.CallPassType = HoverInfo::PassType{PassMode::ConstRef, false};
}},
+  {
+  R"cpp(
+int add(int lhs, int rhs);
+int main() {
+  add(1 [[^+]] 2, 3);
+}
+)cpp",
+  [](HoverInfo &HI) {
+HI.Name = "expression";
+HI.Kind = index::SymbolKind::Unknown;
+HI.Type = "int";
+HI.Value = "3";
+HI.CalleeArgInfo.emplace();
+HI.CalleeArgInfo->Name = "lhs";
+HI.CalleeArgInfo->Type = "int";
+HI.CallPassType = HoverInfo::PassType{PassMode::Value, false};
+  }},
+  {
+  R"cpp(
+void foobar(const float &arg);
+int main() {
+  foobar([[^0]]);
+}
+)cpp",
+  [](HoverInfo &HI) {
+HI.Name = "literal";
+HI.Kind = index::SymbolKind::Unknown;
+HI.CalleeArgInfo.emplace();
+HI.CalleeArgInfo->Name = "arg";
+HI.CalleeArgInfo->Type = "const float &";
+HI.CallPassType = HoverInfo::PassType{PassMode::Value, true};
+  }},
   {// Extra info for method call.
R"cpp(
   class C {
@@ -960,6 +1013,29 @@
  HI.CalleeArgInfo->Default = "3";
  HI.CallPassType = HoverInfo::PassType{PassMode::Value, false};
}},
+  {
+  R"cpp(
+  struct Foo {
+Foo(const int &);
+  };
+  void foo(Foo);
+  void bar() {
+const int x = 0;
+foo([[^x]]);
+  }
+   )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "x";
+HI.Kind = index::SymbolKind::Variable;
+HI.NamespaceScope = "";
+HI.Definition = "const int x = 0";
+HI.LocalScope = "bar::";
+HI.Value = "0";
+HI.Type = "const int";
+HI.CalleeArgInfo.emplace();
+HI.CalleeArgInfo->Type = "Foo";
+HI.CallPassType = HoverInfo::PassType{PassMode::ConstRef, true};
+  }},
   {// Dont crash on invalid decl
R"cpp(
 // error-ok
@@ -1673,8 +1749,8 @@
   }},
   {
   R"cpp(// Function definition via using declaration
-namespace ns { 
-  void foo(); 
+namespace ns {
+  void foo();
 }
 int main() {
   using ns::foo;
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -952,6 +952,15 @@
   }
 }
 
+HoverInfo::PassType::PassMode getPassMode(QualType ParmType) {
+  if (ParmType->isReferenceType()) {
+if (ParmType->getPointeeType().isConstQualified())
+  return HoverInfo::PassType::ConstRef;
+return HoverInfo::PassType::Ref;
+  }
+  return HoverInfo::PassType::Value;
+}
+
 // If N is passed as argument to a function, fill HI.CalleeArgInfo with
 // information about that argument.
 void maybeAddCalleeArgInfo(const SelectionTree::Node *N, HoverInfo &HI,
@@ -972,14 +981,19 @@
   if (!FD || FD->isOverloadedOperator() || FD->isVariadic())
 return;
 
+  HoverInfo::PassType PassType;
+
   // Find argument index for N.
   for (unsigned I = 0; I < CE->getNumArgs(

[PATCH] D143734: [NFC][clang][Modules] Refine test checks by adding `:`

2023-02-10 Thread Mariya Podchishchaeva via Phabricator via cfe-commits
Fznamznon created this revision.
Fznamznon added reviewers: ChuanqiXu, Bigcheese.
Herald added a project: All.
Fznamznon requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The test can fail if wokring directory where the test was launched
has a `error` substring in its path.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143734

Files:
  clang/test/Modules/libstdcxx-ambiguous-internal.cpp


Index: clang/test/Modules/libstdcxx-ambiguous-internal.cpp
===
--- clang/test/Modules/libstdcxx-ambiguous-internal.cpp
+++ clang/test/Modules/libstdcxx-ambiguous-internal.cpp
@@ -2,12 +2,12 @@
 // RUN: %clang_cc1 -x c++ -std=c++11 -fmodules -emit-module -fmodule-name=std 
-fmodules-cache-path=%t %S/Inputs/libstdcxx-ambiguous-internal/module.modulemap 
-Werror
 // RUN: %clang_cc1 -x c++ -std=c++11 -fmodules -emit-module -fmodule-name=std 
-fmodules-cache-path=%t %S/Inputs/libstdcxx-ambiguous-internal/module.modulemap 
-fmodules-local-submodule-visibility -DAMBIGUOUS 2>&1| FileCheck %s
 
-// CHECK-NOT: error
+// CHECK-NOT: error:
 // CHECK: warning: ambiguous use of internal linkage declaration 'f' defined 
in multiple modules
 // CHECK: note: declared here in module 'std.C'
 // CHECK: note: declared here in module 'std.B'
-// CHECK-NOT: error
+// CHECK-NOT: error:
 // CHECK: warning: ambiguous use of internal linkage declaration 'n' defined 
in multiple modules
 // CHECK: note: declared here in module 'std.C'
 // CHECK: note: declared here in module 'std.B'
-// CHECK-NOT: error
+// CHECK-NOT: error:


Index: clang/test/Modules/libstdcxx-ambiguous-internal.cpp
===
--- clang/test/Modules/libstdcxx-ambiguous-internal.cpp
+++ clang/test/Modules/libstdcxx-ambiguous-internal.cpp
@@ -2,12 +2,12 @@
 // RUN: %clang_cc1 -x c++ -std=c++11 -fmodules -emit-module -fmodule-name=std -fmodules-cache-path=%t %S/Inputs/libstdcxx-ambiguous-internal/module.modulemap -Werror
 // RUN: %clang_cc1 -x c++ -std=c++11 -fmodules -emit-module -fmodule-name=std -fmodules-cache-path=%t %S/Inputs/libstdcxx-ambiguous-internal/module.modulemap -fmodules-local-submodule-visibility -DAMBIGUOUS 2>&1| FileCheck %s
 
-// CHECK-NOT: error
+// CHECK-NOT: error:
 // CHECK: warning: ambiguous use of internal linkage declaration 'f' defined in multiple modules
 // CHECK: note: declared here in module 'std.C'
 // CHECK: note: declared here in module 'std.B'
-// CHECK-NOT: error
+// CHECK-NOT: error:
 // CHECK: warning: ambiguous use of internal linkage declaration 'n' defined in multiple modules
 // CHECK: note: declared here in module 'std.C'
 // CHECK: note: declared here in module 'std.B'
-// CHECK-NOT: error
+// CHECK-NOT: error:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 067a5c6 - [amdgpu-arch] Fix build of amdgpu-arch with CLANG_LINK_CLANG_DYLIB

2023-02-10 Thread Joseph Huber via cfe-commits

Author: Joseph Huber
Date: 2023-02-10T08:23:49-06:00
New Revision: 067a5c68845c13d45e85ec9eaa11d2b2d829bab4

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

LOG: [amdgpu-arch] Fix build of amdgpu-arch with CLANG_LINK_CLANG_DYLIB

The function clang_target_link_libraries must only be used with real
Clang libraries; with CLANG_LINK_CLANG_DYLIB, it will instead link in
clang-cpp. We must use the standard CMake target_link_libraries for
the HSA library.

Added: 


Modified: 
clang/tools/amdgpu-arch/CMakeLists.txt

Removed: 




diff  --git a/clang/tools/amdgpu-arch/CMakeLists.txt 
b/clang/tools/amdgpu-arch/CMakeLists.txt
index f57ee216b0934..5b7ef13924b8e 100644
--- a/clang/tools/amdgpu-arch/CMakeLists.txt
+++ b/clang/tools/amdgpu-arch/CMakeLists.txt
@@ -14,7 +14,7 @@ add_clang_tool(amdgpu-arch AMDGPUArch.cpp)
 find_package(hsa-runtime64 QUIET 1.2.0 HINTS ${CMAKE_INSTALL_PREFIX} PATHS 
/opt/rocm)
 if(hsa-runtime64_FOUND AND NOT (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P 
EQUAL 4))
   set_target_properties(amdgpu-arch PROPERTIES INSTALL_RPATH_USE_LINK_PATH ON)
-  clang_target_link_libraries(amdgpu-arch PRIVATE hsa-runtime64::hsa-runtime64)
+  target_link_libraries(amdgpu-arch PRIVATE hsa-runtime64::hsa-runtime64)
 else()
   target_compile_definitions(amdgpu-arch PRIVATE "DYNAMIC_HSA")
 endif()



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


[PATCH] D137527: [C++20] [Modules] [ClangScanDeps] Add ClangScanDeps support for C++20 Named Modules in P1689 format (2/4)

2023-02-10 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Either this or D139168  is breaking tests on 
Windows: http://45.33.8.238/win/74780/step_7.txt

Please take a look and revert for now if it takes a while to fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137527

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


[PATCH] D143638: [clangd] Move function body to out-of-line: unnamed class method incorrect moving

2023-02-10 Thread Denis Fatkulin via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
denis-fatkulin marked 3 inline comments as done.
Closed by commit rG04f4c4cc59db: [clangd] Move function body to out-of-line: 
unnamed class method incorrect… (authored by denis-fatkulin).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143638

Files:
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp


Index: clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
@@ -84,6 +84,32 @@
 template  void fo^o() {};
 template <> void fo^o() {};
   )cpp");
+
+  // Not available on methods of unnamed classes.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {
+  struct { void b^ar() {} } Bar;
+};
+  )cpp");
+
+  // Not available on methods of named classes with unnamed parent in parents
+  // nesting.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {
+  struct {
+struct Bar { void b^ar() {} };
+  } Baz;
+};
+  )cpp");
+
+  // Not available on definitions within unnamed namespaces
+  EXPECT_UNAVAILABLE(R"cpp(
+namespace {
+  struct Foo {
+void f^oo() {}
+  };
+} // namespace
+  )cpp");
 }
 
 TEST_F(DefineOutlineTest, FailsWithoutSource) {
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
@@ -392,11 +392,20 @@
 if (Source->getTemplateSpecializationInfo())
   return false;
 
-// Bail out in templated classes, as it is hard to spell the class name, 
i.e
-// if the template parameter is unnamed.
 if (auto *MD = llvm::dyn_cast(Source)) {
+  // Bail out in templated classes, as it is hard to spell the class name,
+  // i.e if the template parameter is unnamed.
   if (MD->getParent()->isTemplated())
 return false;
+
+  // The refactoring is meaningless for unnamed classes and definitions
+  // within unnamed namespaces.
+  for (const DeclContext *DC = MD->getParent(); DC; DC = DC->getParent()) {
+if (auto *ND = llvm::dyn_cast(DC)) {
+  if (ND->getDeclName().isEmpty())
+return false;
+}
+  }
 }
 
 // Note that we don't check whether an implementation file exists or not in


Index: clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
@@ -84,6 +84,32 @@
 template  void fo^o() {};
 template <> void fo^o() {};
   )cpp");
+
+  // Not available on methods of unnamed classes.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {
+  struct { void b^ar() {} } Bar;
+};
+  )cpp");
+
+  // Not available on methods of named classes with unnamed parent in parents
+  // nesting.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {
+  struct {
+struct Bar { void b^ar() {} };
+  } Baz;
+};
+  )cpp");
+
+  // Not available on definitions within unnamed namespaces
+  EXPECT_UNAVAILABLE(R"cpp(
+namespace {
+  struct Foo {
+void f^oo() {}
+  };
+} // namespace
+  )cpp");
 }
 
 TEST_F(DefineOutlineTest, FailsWithoutSource) {
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
@@ -392,11 +392,20 @@
 if (Source->getTemplateSpecializationInfo())
   return false;
 
-// Bail out in templated classes, as it is hard to spell the class name, i.e
-// if the template parameter is unnamed.
 if (auto *MD = llvm::dyn_cast(Source)) {
+  // Bail out in templated classes, as it is hard to spell the class name,
+  // i.e if the template parameter is unnamed.
   if (MD->getParent()->isTemplated())
 return false;
+
+  // The refactoring is meaningless for unnamed classes and definitions
+  // within unnamed namespaces.
+  for (const DeclContext *DC = MD->getParent(); DC; DC = DC->getParent()) {
+if (auto *ND = llvm::dyn_cast(DC)) {
+  if (ND->getDeclName().isEmpty())
+return false;
+}
+  }
 }
 
 // Note that we don't check whether an implementation file exists or not in
___
cfe-commits mailing list
cfe-co

[clang-tools-extra] 04f4c4c - [clangd] Move function body to out-of-line: unnamed class method incorrect moving

2023-02-10 Thread Denis Fatkulin via cfe-commits

Author: Denis Fatkulin
Date: 2023-02-10T17:40:21+03:00
New Revision: 04f4c4cc59db0f4db9cddcc5846d98491d4b65f5

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

LOG: [clangd] Move function body to out-of-line: unnamed class method incorrect 
moving

The refactoring !!Move function body to out-of-line!! produces incorrect code 
for methods of unnamed classes.
For this simple example
  // foo.h
  struct Foo {
struct {
  void f^oo() {}
} Bar;
  };

the refactoring generates code:
  // foo.cpp
  void Foo::(unnamed struct at D:\test\foo.h:2:3)foo() {}

Outplace definition for methods of unnamed classes is meaningless. The patch 
disables it.

Reviewed By: kadircet

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

Added: 


Modified: 
clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp 
b/clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
index a4d60c6c11bb9..95334c49bfb6e 100644
--- a/clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
+++ b/clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
@@ -392,11 +392,20 @@ class DefineOutline : public Tweak {
 if (Source->getTemplateSpecializationInfo())
   return false;
 
-// Bail out in templated classes, as it is hard to spell the class name, 
i.e
-// if the template parameter is unnamed.
 if (auto *MD = llvm::dyn_cast(Source)) {
+  // Bail out in templated classes, as it is hard to spell the class name,
+  // i.e if the template parameter is unnamed.
   if (MD->getParent()->isTemplated())
 return false;
+
+  // The refactoring is meaningless for unnamed classes and definitions
+  // within unnamed namespaces.
+  for (const DeclContext *DC = MD->getParent(); DC; DC = DC->getParent()) {
+if (auto *ND = llvm::dyn_cast(DC)) {
+  if (ND->getDeclName().isEmpty())
+return false;
+}
+  }
 }
 
 // Note that we don't check whether an implementation file exists or not in

diff  --git a/clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp 
b/clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
index e3954e6b2faff..c6c9684ffa4fa 100644
--- a/clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
+++ b/clang-tools-extra/clangd/unittests/tweaks/DefineOutlineTests.cpp
@@ -84,6 +84,32 @@ TEST_F(DefineOutlineTest, TriggersOnFunctionDecl) {
 template  void fo^o() {};
 template <> void fo^o() {};
   )cpp");
+
+  // Not available on methods of unnamed classes.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {
+  struct { void b^ar() {} } Bar;
+};
+  )cpp");
+
+  // Not available on methods of named classes with unnamed parent in parents
+  // nesting.
+  EXPECT_UNAVAILABLE(R"cpp(
+struct Foo {
+  struct {
+struct Bar { void b^ar() {} };
+  } Baz;
+};
+  )cpp");
+
+  // Not available on definitions within unnamed namespaces
+  EXPECT_UNAVAILABLE(R"cpp(
+namespace {
+  struct Foo {
+void f^oo() {}
+  };
+} // namespace
+  )cpp");
 }
 
 TEST_F(DefineOutlineTest, FailsWithoutSource) {



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


[PATCH] D143587: [Docs] Multilib design

2023-02-10 Thread Peter Smith via Phabricator via cfe-commits
peter.smith added a comment.

Thanks for the update, one nit in the language, otherwise looks good to me. It 
is a good reflection of the implementation.




Comment at: clang/docs/Multilib.rst:250
+
+The API need only multilib selection based on only a limited set of command
+line arguments. Later LLVM versions can add support for multilib selection from

"The API need only multilib selection" doesn't look right. Perhaps "The API can 
do multilib selection"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143587

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


[PATCH] D143735: [clang][dataflow] Convert nonnull pointer parameter to a reference.

2023-02-10 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel created this revision.
ymandel added reviewers: xazax.hun, gribozavr2.
Herald added subscribers: martong, rnkovacs.
Herald added a reviewer: NoQ.
Herald added a project: All.
ymandel requested review of this revision.
Herald added a project: clang.

The parameter in question belongs to a function that is only called once. This 
patch updates the API to use a reference and changes the caller accordingly.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143735

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -374,7 +374,7 @@
 }
 
 // User-provided analysis
-AC.Analysis.transferTypeErased(&Element, State.Lattice, State.Env);
+AC.Analysis.transferTypeErased(Element, State.Lattice, State.Env);
 
 // Post processing
 if (PostVisitCFG) {
Index: clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
@@ -96,7 +96,7 @@
 
   /// Applies the analysis transfer function for a given control flow graph
   /// element and type-erased lattice element.
-  virtual void transferTypeErased(const CFGElement *, TypeErasedLattice &,
+  virtual void transferTypeErased(const CFGElement &, TypeErasedLattice &,
   Environment &) = 0;
 
   /// Applies the analysis transfer function for a given edge from a CFG block
Index: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -119,7 +119,7 @@
 return L1 == L2;
   }
 
-  void transferTypeErased(const CFGElement *Element, TypeErasedLattice &E,
+  void transferTypeErased(const CFGElement &Element, TypeErasedLattice &E,
   Environment &Env) final {
 Lattice &L = llvm::any_cast(E.Value);
 static_cast(this)->transfer(Element, L, Env);


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -374,7 +374,7 @@
 }
 
 // User-provided analysis
-AC.Analysis.transferTypeErased(&Element, State.Lattice, State.Env);
+AC.Analysis.transferTypeErased(Element, State.Lattice, State.Env);
 
 // Post processing
 if (PostVisitCFG) {
Index: clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
@@ -96,7 +96,7 @@
 
   /// Applies the analysis transfer function for a given control flow graph
   /// element and type-erased lattice element.
-  virtual void transferTypeErased(const CFGElement *, TypeErasedLattice &,
+  virtual void transferTypeErased(const CFGElement &, TypeErasedLattice &,
   Environment &) = 0;
 
   /// Applies the analysis transfer function for a given edge from a CFG block
Index: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -119,7 +119,7 @@
 return L1 == L2;
   }
 
-  void transferTypeErased(const CFGElement *Element, TypeErasedLattice &E,
+  void transferTypeErased(const CFGElement &Element, TypeErasedLattice &E,
   Environment &Env) final {
 Lattice &L = llvm::any_cast(E.Value);
 static_cast(this)->transfer(Element, L, Env);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143342: [clang-tidy] Support std::format and std::print in readability-redundant-string-cstr

2023-02-10 Thread Nathan James via Phabricator via cfe-commits
njames93 added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/RedundantStringCStrCheck.cpp:188
+  callee(functionDecl(hasName("::std::format",
+hasAnyArgument(materializeTemporaryExpr(
+has(StringCStrCallExpr),

mikecrowe wrote:
> njames93 wrote:
> > The limitation about only transforming the first argument can be alleviated 
> > by using the `forEachArgumentWithParam` matcher
> Thanks for the hint. I did try to overcome this limitation but failed to find 
> `forEachArgumentWithParam`.
> 
> I think that I've managed to make `forEachArgumentWithParam` work, but only 
> if I lose the `materializeTemporaryExpr`. I hope that's not essential. I've 
> ended up with:
> 
> ```C++
>   Finder->addMatcher( 
>   
>
> traverse(TK_AsIs, 
>   
>
>  callExpr(callee(functionDecl(hasAnyName("::std::print", 
> "::std::format"))),   
> 
>   forEachArgumentWithParam(StringCStrCallExpr, 
> parmVarDecl(, 
>   
> this);
>   
>
> ```
> I suspect that there's something better than the `parmVarDecl()` second 
> parameter to `forEachArgumentWithParam` though.
`parmVarDecl` is exactly what you need here.

My understanding of the temporary expressions isn't perfect, but from what I 
can gather, we shouldn't need temporaries when calling the `.c_str()`method for 
all but the first argument.

This does highlight an issue with your test code though.
`std::format` and `std::print` take a `std::format_string` as the first 
argument, but in your tests you have it as `const char *`
Anyway I think this means the first argument in real world code would result in 
a `materializeTemporaryExpr`
See [[ https://en.cppreference.com/w/cpp/utility/format/basic_format_string | 
here ]]


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

https://reviews.llvm.org/D143342

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


[PATCH] D143624: Inlining: Run the legacy AlwaysInliner before the regular inliner.

2023-02-10 Thread Dave Green via Phabricator via cfe-commits
dmgreen added a comment.

Hello - I had to revert this because of some large regressions we got from 
routines in CMSIS-DSP.

The llvm/test/Transforms/PhaseOrdering/ARM/arm_mult_q15.ll test shows the 
problem - that's why that test exists to ensure that any pipeline changes don't 
negatively affect these routines. Unfortunately you just changed the test as 
opposed to showing the problems that this causes.  They might be fixable with 
some other tweaks elsewhere, but the ordering of inlining seems important for 
getting the correct code that can be vectorized nicely.

There are some other cases around inlining this thing on v6m cores: 
https://github.com/ARM-software/CMSIS-DSP/blob/809202bf185280a322efc2e2c850a544747f9d79/Include/arm_math_memory.h#L76,
 but I'm not sure about the details yet. The mult examples were the really 
large regressions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143624

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


[PATCH] D143509: Move the BySpelling map to IncludeStructure.

2023-02-10 Thread Viktoriia Bakalova via Phabricator via cfe-commits
VitaNuo updated this revision to Diff 496460.
VitaNuo added a comment.

Address review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143509

Files:
  clang-tools-extra/clangd/Headers.cpp
  clang-tools-extra/clangd/Headers.h
  clang-tools-extra/clangd/IncludeCleaner.cpp

Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -85,7 +85,7 @@
 // Using templateName case is handled by the override TraverseTemplateName.
 if (TST->getTemplateName().getKind() == TemplateName::UsingTemplate)
   return true;
-add(TST->getAsCXXRecordDecl());  // Specialization
+add(TST->getAsCXXRecordDecl()); // Specialization
 return true;
   }
 
@@ -474,22 +474,18 @@
   translateToHeaderIDs(ReferencedFiles, AST.getIncludeStructure(), SM);
   return getUnused(AST, ReferencedHeaders, ReferencedFiles.SpelledUmbrellas);
 }
-std::vector computeUnusedIncludesExperimental(ParsedAST &AST) {
-   const auto &SM = AST.getSourceManager();
-   const auto &Includes = AST.getIncludeStructure();
-   // FIXME: this map should probably be in IncludeStructure.
-   llvm::StringMap> BySpelling;
-   for (const auto &Inc : Includes.MainFileIncludes) {
-if (Inc.HeaderID)
-  BySpelling.try_emplace(Inc.Written)
-  .first->second.push_back(
-  static_cast(*Inc.HeaderID));
-   }
-   // FIXME: !!this is a hacky way to collect macro references.
-   std::vector Macros;
-auto& PP = AST.getPreprocessor();
-   for (const syntax::Token &Tok :
-AST.getTokens().spelledTokens(SM.getMainFileID())) {
+std::vector
+computeUnusedIncludesExperimental(ParsedAST &AST) {
+  const auto &SM = AST.getSourceManager();
+  const auto &Includes = AST.getIncludeStructure();
+  llvm::StringMap> BySpelling =
+  Includes.getMainFileIncludesBySpelling();
+
+  // FIXME: !!this is a hacky way to collect macro references.
+  std::vector Macros;
+  auto &PP = AST.getPreprocessor();
+  for (const syntax::Token &Tok :
+   AST.getTokens().spelledTokens(SM.getMainFileID())) {
 auto Macro = locateMacroAt(Tok, PP);
 if (!Macro)
   continue;
@@ -499,31 +495,31 @@
include_cleaner::Macro{/*Name=*/PP.getIdentifierInfo(Tok.text(SM)),
   DefLoc},
include_cleaner::RefType::Explicit});
-   }
-   llvm::DenseSet Used;
-   include_cleaner::walkUsed(
-   AST.getLocalTopLevelDecls(), /*MacroRefs=*/Macros,
-   AST.getPragmaIncludes(), SM,
-   [&](const include_cleaner::SymbolReference &Ref,
-   llvm::ArrayRef Providers) {
- for (const auto &H : Providers) {
-   switch (H.kind()) {
-   case include_cleaner::Header::Physical:
- if (auto HeaderID = Includes.getID(H.physical()))
-   Used.insert(*HeaderID);
- break;
-   case include_cleaner::Header::Standard:
- for (auto HeaderID : Includes.StdlibHeaders.lookup(H.standard()))
-   Used.insert(HeaderID);
- break;
-   case include_cleaner::Header::Verbatim:
- for (auto HeaderID : BySpelling.lookup(H.verbatim()))
-   Used.insert(HeaderID);
- break;
-   }
- }
-   });
-   return getUnused(AST, Used, /*ReferencedPublicHeaders*/{});
+  }
+  llvm::DenseSet Used;
+  include_cleaner::walkUsed(
+  AST.getLocalTopLevelDecls(), /*MacroRefs=*/Macros,
+  AST.getPragmaIncludes(), SM,
+  [&](const include_cleaner::SymbolReference &Ref,
+  llvm::ArrayRef Providers) {
+for (const auto &H : Providers) {
+  switch (H.kind()) {
+  case include_cleaner::Header::Physical:
+if (auto HeaderID = Includes.getID(H.physical()))
+  Used.insert(*HeaderID);
+break;
+  case include_cleaner::Header::Standard:
+for (auto HeaderID : Includes.StdlibHeaders.lookup(H.standard()))
+  Used.insert(HeaderID);
+break;
+  case include_cleaner::Header::Verbatim:
+for (auto HeaderID : BySpelling.lookup(H.verbatim()))
+  Used.insert(HeaderID);
+break;
+  }
+}
+  });
+  return getUnused(AST, Used, /*ReferencedPublicHeaders*/ {});
 }
 
 std::vector issueUnusedIncludesDiagnostics(ParsedAST &AST,
Index: clang-tools-extra/clangd/Headers.h
===
--- clang-tools-extra/clangd/Headers.h
+++ clang-tools-extra/clangd/Headers.h
@@ -23,6 +23,8 @@
 #include "clang/Tooling/Inclusions/StandardLibrary.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/DenseSet.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Stri

[PATCH] D143736: [PowerPC] Specify the dynamic loader prefix in ppc-float-abi-warning

2023-02-10 Thread Tulio Magno Quites Machado Filho via Phabricator via cfe-commits
tuliom created this revision.
tuliom added a reviewer: qiucf.
Herald added subscribers: shchenz, kbarton, nemanjai.
Herald added a project: All.
tuliom requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Ensure the tests do not fail during cross compilation by specifying
the dynamic loader prefix for a GNU installation that is expected to
support IEEE 128-bit long double.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143736

Files:
  clang/test/Driver/ppc-float-abi-warning.cpp


Index: clang/test/Driver/ppc-float-abi-warning.cpp
===
--- clang/test/Driver/ppc-float-abi-warning.cpp
+++ clang/test/Driver/ppc-float-abi-warning.cpp
@@ -17,10 +17,12 @@
 // RUN:  -mabi=ieeelongdouble -stdlib=libc++ -Wno-unsupported-abi 2>&1 | \
 // RUN:  FileCheck %s --check-prefix=NOWARN
 // RUN: %clang -### --driver-mode=g++ -target powerpc64le-linux-gnu %s\
+// RUN:  --dyld-prefix=%S/Inputs/powerpc64le-linux-gnu-tree/gcc-12 \
 // RUN:  -mabi=%if ppc_linux_default_ieeelongdouble %{ieeelongdouble%} \
 // RUN:  %else %{ibmlongdouble%} -stdlib=libc++ 2>&1 | \
 // RUN:  FileCheck %s --check-prefix=NOWARN
 // RUN: %clang -### --driver-mode=g++ -target powerpc64le-linux-gnu %s\
+// RUN:  --dyld-prefix=%S/Inputs/powerpc64le-linux-gnu-tree/gcc-12 \
 // RUN:  -mabi=%if ppc_linux_default_ieeelongdouble %{ibmlongdouble%} \
 // RUN:  %else %{ieeelongdouble%} -stdlib=libc++ 2>&1 | FileCheck %s
 


Index: clang/test/Driver/ppc-float-abi-warning.cpp
===
--- clang/test/Driver/ppc-float-abi-warning.cpp
+++ clang/test/Driver/ppc-float-abi-warning.cpp
@@ -17,10 +17,12 @@
 // RUN:  -mabi=ieeelongdouble -stdlib=libc++ -Wno-unsupported-abi 2>&1 | \
 // RUN:  FileCheck %s --check-prefix=NOWARN
 // RUN: %clang -### --driver-mode=g++ -target powerpc64le-linux-gnu %s\
+// RUN:  --dyld-prefix=%S/Inputs/powerpc64le-linux-gnu-tree/gcc-12 \
 // RUN:  -mabi=%if ppc_linux_default_ieeelongdouble %{ieeelongdouble%} \
 // RUN:  %else %{ibmlongdouble%} -stdlib=libc++ 2>&1 | \
 // RUN:  FileCheck %s --check-prefix=NOWARN
 // RUN: %clang -### --driver-mode=g++ -target powerpc64le-linux-gnu %s\
+// RUN:  --dyld-prefix=%S/Inputs/powerpc64le-linux-gnu-tree/gcc-12 \
 // RUN:  -mabi=%if ppc_linux_default_ieeelongdouble %{ibmlongdouble%} \
 // RUN:  %else %{ieeelongdouble%} -stdlib=libc++ 2>&1 | FileCheck %s
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143509: Move the BySpelling map to IncludeStructure.

2023-02-10 Thread Viktoriia Bakalova via Phabricator via cfe-commits
VitaNuo updated this revision to Diff 496463.
VitaNuo added a comment.

Expose API for lookup instead of retrieving the whole map.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143509

Files:
  clang-tools-extra/clangd/Headers.cpp
  clang-tools-extra/clangd/Headers.h
  clang-tools-extra/clangd/IncludeCleaner.cpp

Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -85,7 +85,7 @@
 // Using templateName case is handled by the override TraverseTemplateName.
 if (TST->getTemplateName().getKind() == TemplateName::UsingTemplate)
   return true;
-add(TST->getAsCXXRecordDecl());  // Specialization
+add(TST->getAsCXXRecordDecl()); // Specialization
 return true;
   }
 
@@ -474,22 +474,16 @@
   translateToHeaderIDs(ReferencedFiles, AST.getIncludeStructure(), SM);
   return getUnused(AST, ReferencedHeaders, ReferencedFiles.SpelledUmbrellas);
 }
-std::vector computeUnusedIncludesExperimental(ParsedAST &AST) {
-   const auto &SM = AST.getSourceManager();
-   const auto &Includes = AST.getIncludeStructure();
-   // FIXME: this map should probably be in IncludeStructure.
-   llvm::StringMap> BySpelling;
-   for (const auto &Inc : Includes.MainFileIncludes) {
-if (Inc.HeaderID)
-  BySpelling.try_emplace(Inc.Written)
-  .first->second.push_back(
-  static_cast(*Inc.HeaderID));
-   }
-   // FIXME: !!this is a hacky way to collect macro references.
-   std::vector Macros;
-auto& PP = AST.getPreprocessor();
-   for (const syntax::Token &Tok :
-AST.getTokens().spelledTokens(SM.getMainFileID())) {
+std::vector
+computeUnusedIncludesExperimental(ParsedAST &AST) {
+  const auto &SM = AST.getSourceManager();
+  const auto &Includes = AST.getIncludeStructure();
+
+  // FIXME: !!this is a hacky way to collect macro references.
+  std::vector Macros;
+  auto &PP = AST.getPreprocessor();
+  for (const syntax::Token &Tok :
+   AST.getTokens().spelledTokens(SM.getMainFileID())) {
 auto Macro = locateMacroAt(Tok, PP);
 if (!Macro)
   continue;
@@ -499,31 +493,32 @@
include_cleaner::Macro{/*Name=*/PP.getIdentifierInfo(Tok.text(SM)),
   DefLoc},
include_cleaner::RefType::Explicit});
-   }
-   llvm::DenseSet Used;
-   include_cleaner::walkUsed(
-   AST.getLocalTopLevelDecls(), /*MacroRefs=*/Macros,
-   AST.getPragmaIncludes(), SM,
-   [&](const include_cleaner::SymbolReference &Ref,
-   llvm::ArrayRef Providers) {
- for (const auto &H : Providers) {
-   switch (H.kind()) {
-   case include_cleaner::Header::Physical:
- if (auto HeaderID = Includes.getID(H.physical()))
-   Used.insert(*HeaderID);
- break;
-   case include_cleaner::Header::Standard:
- for (auto HeaderID : Includes.StdlibHeaders.lookup(H.standard()))
-   Used.insert(HeaderID);
- break;
-   case include_cleaner::Header::Verbatim:
- for (auto HeaderID : BySpelling.lookup(H.verbatim()))
-   Used.insert(HeaderID);
- break;
-   }
- }
-   });
-   return getUnused(AST, Used, /*ReferencedPublicHeaders*/{});
+  }
+  llvm::DenseSet Used;
+  include_cleaner::walkUsed(
+  AST.getLocalTopLevelDecls(), /*MacroRefs=*/Macros,
+  AST.getPragmaIncludes(), SM,
+  [&](const include_cleaner::SymbolReference &Ref,
+  llvm::ArrayRef Providers) {
+for (const auto &H : Providers) {
+  switch (H.kind()) {
+  case include_cleaner::Header::Physical:
+if (auto HeaderID = Includes.getID(H.physical()))
+  Used.insert(*HeaderID);
+break;
+  case include_cleaner::Header::Standard:
+for (auto HeaderID : Includes.StdlibHeaders.lookup(H.standard()))
+  Used.insert(HeaderID);
+break;
+  case include_cleaner::Header::Verbatim:
+for (auto HeaderID :
+ Includes.lookupHeaderIDsBySpelling(H.verbatim()))
+  Used.insert(HeaderID);
+break;
+  }
+}
+  });
+  return getUnused(AST, Used, /*ReferencedPublicHeaders*/ {});
 }
 
 std::vector issueUnusedIncludesDiagnostics(ParsedAST &AST,
Index: clang-tools-extra/clangd/Headers.h
===
--- clang-tools-extra/clangd/Headers.h
+++ clang-tools-extra/clangd/Headers.h
@@ -23,6 +23,8 @@
 #include "clang/Tooling/Inclusions/StandardLibrary.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/DenseSet.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSet.h"
 #in

[PATCH] D143509: Move the BySpelling map to IncludeStructure.

2023-02-10 Thread Viktoriia Bakalova via Phabricator via cfe-commits
VitaNuo added a comment.

Thanks for review!




Comment at: clang-tools-extra/clangd/Headers.h:164
+  llvm::StringMap>
+  buildMainFileIncludesBySpelling() const {
+llvm::StringMap> BySpelling;

kadircet wrote:
> instead of building this on-demand, what about building it as we're 
> collecting directives around 
> https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/clangd/Headers.cpp#L52
>  ?
> 
> afterwards we can just have a lookup function exposed here, that returns an 
> `ArrayRef` ?
That's a great idea. I was thinking about this, but didn't know where to put 
it, so I thought if it was possible, you'd point out in review ;-)
Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143509

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


[PATCH] D143624: Inlining: Run the legacy AlwaysInliner before the regular inliner.

2023-02-10 Thread Amara Emerson via Phabricator via cfe-commits
aemerson added a comment.

In D143624#4118257 , @dmgreen wrote:

> Hello - I had to revert this because of some large regressions we got from 
> routines in CMSIS-DSP.
>
> The llvm/test/Transforms/PhaseOrdering/ARM/arm_mult_q15.ll test shows the 
> problem - that's why that test exists to ensure that any pipeline changes 
> don't negatively affect these routines. Unfortunately you just changed the 
> test as opposed to showing the problems that this causes.  They might be 
> fixable with some other tweaks elsewhere, but the ordering of inlining seems 
> important for getting the correct code that can be vectorized nicely.
>
> There are some other cases around inlining this thing on v6m cores: 
> https://github.com/ARM-software/CMSIS-DSP/blob/809202bf185280a322efc2e2c850a544747f9d79/Include/arm_math_memory.h#L76,
>  but I'm not sure about the details yet. The mult examples were the really 
> large regressions.

It’s not clear from the original commit message why the test is related to 
inlining order? It seems entirely testing vectorization cost model which should 
be insensitive to these kind of changes, right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143624

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


[PATCH] D142939: Fix handling of -> calls for modernize-use-emplace

2023-02-10 Thread Peter Wolf via Phabricator via cfe-commits
BigPeet added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142939

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


[PATCH] D143624: Inlining: Run the legacy AlwaysInliner before the regular inliner.

2023-02-10 Thread Dave Green via Phabricator via cfe-commits
dmgreen added a comment.

> It’s not clear from the original commit message why the test is related to 
> inlining order? It seems entirely testing vectorization cost model which 
> should be insensitive to these kind of changes, right?

It's a phase ordering test - it's testing the entire pipeline including all the 
inlining and simplification that needs to happen :)

You can run update_test_checks of the file to see the differences. I believe 
the inlining causes differences in the code that then cause different vector 
factors to be chosen. I can try to add a similar test for the other case that 
got worse, if they are similar.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143624

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


[PATCH] D142933: Add -print-multi-selection-flags argument

2023-02-10 Thread Peter Smith via Phabricator via cfe-commits
peter.smith added a comment.

Thanks for the updates, changes look good to me. I think that we can get away 
without trying to break the floating point options into flags, at least for how 
floating point units are available in hardware today.




Comment at: clang/lib/Driver/ToolChain.cpp:173
 }
 
+std::vector

michaelplatings wrote:
> peter.smith wrote:
> > IIUC this needs to contain the union of all command-line options used by 
> > all clients of the YAML but not any of the existing hard-coded Multilibs?
> > 
> > There is a possibility that this function could get large over time, with 
> > many Toolchain and Architecture specific flags? It is it worth delegating 
> > some of the work to the Toolchain, for example at the moment the BareMetal 
> > driver won't support the sanitizers so this could be processed by a 
> > Toolchain specific function (Fuchsia in this case?). There's likely to be a 
> > lot of options used by many Multilib implementations so there is still 
> > scope for putting stuff here. We would need to know what driver and 
> > architecture we are using here though.
> > 
> > If we had already constructed the MultilibSet it could be possible to 
> > filter the flags against what the MultilibSet actually accepts?
> > 
> > Is it worth making that clear, or have some way for the other non YAML 
> > users to call print_multi_selection_flags? Or is the option purely for 
> > developing/debugging multilib as I'd not expect the output of 
> > print_multi_section flags to be used by a user of clang. In that case a 
> > translation of what command-line flags influence multilib selection 
> > (ideally filtered) through the processed YAML file would be great.
> Correct, we don't yet need to cater for existing hard-coded Multilibs.
> 
> I did think about putting some argument processing in ToolChain subclasses 
> but for now I'm inclined to say YAGNI. If it's needed later on that's an easy 
> refactoring. With the current form, there's less likelihood of different 
> ToolChain subclasses diverging in the style of attributes they emit.
> 
> MultilibSet can use a regex, and both matching and not matching can be 
> significant, so I'm not sure it makes sense to filter against that.
> 
> `-print-multi-selection-flags-experimental` can be used completely 
> independently of any YAML or whether the current ToolChain class actually 
> supports multilib. `-print-multi-selection-flags-experimental` is intended 
> primarily for developing/debugging multilib.
Thinking about Arm floating point modelling (not really relevant to the 
mechanism here). Certainly since the Cortex cores the instructions available to 
an FPU are tied to the architecture. I.e. you cannot mix and match a FPU from 
an earlier or later architecture revision in practice, even if you can put it 
on the command-line in theory. I think this means that in the majority of cases 
we just need to match the floating point libraries with the architecture. The 
exceptions are the floating point variants with cut-down functionality:
* single-precision only (a nightmare of hard-float for floats and soft-float 
for doubles)
* d16 (only 16 double precision registers available rather than 32. I would 
expect this to be interface compatible with code compiled with 32-double 
precision registers as the calling convention doesn't change). All 
single-precision only are also d16.

I think these fpu options are restricted to Cortex-M and Cortex-R.

For a small number of targets we'd likely need at least two (single only, and 
d16) and at most 3 (single only, d16, and full) floating point variants. We'd 
need to map the fpu name suitable for the architecture but I don't think we 
would want to work too hard trying to map an arbitrary floating point unit that 
there is no available hardware for. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142933

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


[PATCH] D143194: [clang][analyzer] Make messages of StdCLibraryFunctionsChecker user-friendly

2023-02-10 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 496471.
balazske added a comment.

change of range descriptions, align comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143194

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-note-tags.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-notes.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-tracking-notes.c
  clang/test/Analysis/std-c-library-functions-arg-constraints.c
  clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
  clang/test/Analysis/stream-note.c
  clang/test/Analysis/stream-stdlibraryfunctionargs.c

Index: clang/test/Analysis/stream-stdlibraryfunctionargs.c
===
--- clang/test/Analysis/stream-stdlibraryfunctionargs.c
+++ clang/test/Analysis/stream-stdlibraryfunctionargs.c
@@ -18,37 +18,31 @@
 void test_fopen(void) {
   FILE *fp = fopen("path", "r");
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}} any-warning{{FALSE}}
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
 }
 
 void test_tmpfile(void) {
   FILE *fp = tmpfile();
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}} any-warning{{FALSE}}
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
 }
 
 void test_fclose(void) {
   FILE *fp = tmpfile();
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
 }
 
 void test_freopen(void) {
   FILE *fp = tmpfile();
-  fp = freopen("file", "w", fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
- // stdargs-note{{The 3rd argument should not be NULL}}
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fp = freopen("file", "w", fp); // stdargs-warning{{should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
 }
 
 void test_fread(void) {
   FILE *fp = tmpfile();
-  size_t ret = fread(buf, size, n, fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-// stdargs-note{{The 4th argument should not be NULL}}
+  size_t ret = fread(buf, size, n, fp); // stdargs-warning{{The 4th argument to 'fread' should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   clang_analyzer_eval(ret <= n); // any-warning{{TRUE}}
   clang_analyzer_eval(ret == n); // any-warning{{TRUE}} any-warning{{FALSE}}
@@ -58,8 +52,7 @@
 
 void test_fwrite(void) {
   FILE *fp = tmpfile();
-  size_t ret = fwrite(buf, size, n, fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-// stdargs-note{{The 4th argument should not be NULL}}
+  size_t ret = fwrite(buf, size, n, fp); // stdargs-warning{{The 4th argument to 'fwrite' should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   clang_analyzer_eval(ret <= n); // any-warning{{TRUE}}
   clang_analyzer_eval(ret == n); // any-warning{{TRUE}} any-warning{{FALSE}}
@@ -69,24 +62,21 @@
 
 void test_fseek(void) {
   FILE *fp = tmpfile();
-  fseek(fp, 0, 0); // stdargs-warning{{Function argument constraint is not satisfied}} \
-   // stdargs-note{{The 1st argument should not be NULL}}
+  fseek(fp, 0, 0); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   fclose(fp);
 }
 
 void test_ftell(void) {
   FILE *fp = tmpfile();
-  ftell(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
- // stdargs-note{{The 1st argument should not be NULL}}
+  ftell(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   fclose(fp);
 }
 
 void test_rewind(void) {
   FILE *fp = tmpfile();
-  rewind(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  rewind(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   fclose(fp);
 }
@@ -94,8 +84,7 @@
 void test_fgetpos(void) {
   FILE *fp = tmpfile();
   fpos_t pos;
-  fgetpos(fp, &pos); // stdargs-warning{{Functio

[PATCH] D143735: [clang][dataflow] Convert nonnull pointer parameter to a reference.

2023-02-10 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

Just realized this is actually more complicated to change, assuming I also want 
to update all the derived classes. For now, I'll limit the scope of the change 
to these files, but I'll follow up with an overload-based solution to admit 
either kind of derived class until we can port them all over to then new 
signature.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143735

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


[PATCH] D143194: [clang][analyzer] Make messages of StdCLibraryFunctionsChecker user-friendly

2023-02-10 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 496474.
balazske added a comment.

fixed another comment format problem


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143194

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-note-tags.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-notes.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-tracking-notes.c
  clang/test/Analysis/std-c-library-functions-arg-constraints.c
  clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
  clang/test/Analysis/stream-note.c
  clang/test/Analysis/stream-stdlibraryfunctionargs.c

Index: clang/test/Analysis/stream-stdlibraryfunctionargs.c
===
--- clang/test/Analysis/stream-stdlibraryfunctionargs.c
+++ clang/test/Analysis/stream-stdlibraryfunctionargs.c
@@ -18,37 +18,31 @@
 void test_fopen(void) {
   FILE *fp = fopen("path", "r");
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}} any-warning{{FALSE}}
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
 }
 
 void test_tmpfile(void) {
   FILE *fp = tmpfile();
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}} any-warning{{FALSE}}
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
 }
 
 void test_fclose(void) {
   FILE *fp = tmpfile();
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
 }
 
 void test_freopen(void) {
   FILE *fp = tmpfile();
-  fp = freopen("file", "w", fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
- // stdargs-note{{The 3rd argument should not be NULL}}
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fp = freopen("file", "w", fp); // stdargs-warning{{should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
 }
 
 void test_fread(void) {
   FILE *fp = tmpfile();
-  size_t ret = fread(buf, size, n, fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-// stdargs-note{{The 4th argument should not be NULL}}
+  size_t ret = fread(buf, size, n, fp); // stdargs-warning{{The 4th argument to 'fread' should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   clang_analyzer_eval(ret <= n); // any-warning{{TRUE}}
   clang_analyzer_eval(ret == n); // any-warning{{TRUE}} any-warning{{FALSE}}
@@ -58,8 +52,7 @@
 
 void test_fwrite(void) {
   FILE *fp = tmpfile();
-  size_t ret = fwrite(buf, size, n, fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-// stdargs-note{{The 4th argument should not be NULL}}
+  size_t ret = fwrite(buf, size, n, fp); // stdargs-warning{{The 4th argument to 'fwrite' should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   clang_analyzer_eval(ret <= n); // any-warning{{TRUE}}
   clang_analyzer_eval(ret == n); // any-warning{{TRUE}} any-warning{{FALSE}}
@@ -69,24 +62,21 @@
 
 void test_fseek(void) {
   FILE *fp = tmpfile();
-  fseek(fp, 0, 0); // stdargs-warning{{Function argument constraint is not satisfied}} \
-   // stdargs-note{{The 1st argument should not be NULL}}
+  fseek(fp, 0, 0); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   fclose(fp);
 }
 
 void test_ftell(void) {
   FILE *fp = tmpfile();
-  ftell(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
- // stdargs-note{{The 1st argument should not be NULL}}
+  ftell(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   fclose(fp);
 }
 
 void test_rewind(void) {
   FILE *fp = tmpfile();
-  rewind(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  rewind(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   fclose(fp);
 }
@@ -94,8 +84,7 @@
 void test_fgetpos(void) {
   FILE *fp = tmpfile();
   fpos_t pos;
-  fgetpos(fp, &pos); // stdargs-warning{{Function argume

[PATCH] D143194: [clang][analyzer] Make messages of StdCLibraryFunctionsChecker user-friendly

2023-02-10 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 496476.
balazske added a comment.

fixed another comment format problem


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143194

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-note-tags.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-notes.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-tracking-notes.c
  clang/test/Analysis/std-c-library-functions-arg-constraints.c
  clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
  clang/test/Analysis/stream-note.c
  clang/test/Analysis/stream-stdlibraryfunctionargs.c

Index: clang/test/Analysis/stream-stdlibraryfunctionargs.c
===
--- clang/test/Analysis/stream-stdlibraryfunctionargs.c
+++ clang/test/Analysis/stream-stdlibraryfunctionargs.c
@@ -18,37 +18,31 @@
 void test_fopen(void) {
   FILE *fp = fopen("path", "r");
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}} any-warning{{FALSE}}
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
 }
 
 void test_tmpfile(void) {
   FILE *fp = tmpfile();
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}} any-warning{{FALSE}}
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
 }
 
 void test_fclose(void) {
   FILE *fp = tmpfile();
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
 }
 
 void test_freopen(void) {
   FILE *fp = tmpfile();
-  fp = freopen("file", "w", fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
- // stdargs-note{{The 3rd argument should not be NULL}}
-  fclose(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  fp = freopen("file", "w", fp); // stdargs-warning{{should not be NULL}}
+  fclose(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
 }
 
 void test_fread(void) {
   FILE *fp = tmpfile();
-  size_t ret = fread(buf, size, n, fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-// stdargs-note{{The 4th argument should not be NULL}}
+  size_t ret = fread(buf, size, n, fp); // stdargs-warning{{The 4th argument to 'fread' should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   clang_analyzer_eval(ret <= n); // any-warning{{TRUE}}
   clang_analyzer_eval(ret == n); // any-warning{{TRUE}} any-warning{{FALSE}}
@@ -58,8 +52,7 @@
 
 void test_fwrite(void) {
   FILE *fp = tmpfile();
-  size_t ret = fwrite(buf, size, n, fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-// stdargs-note{{The 4th argument should not be NULL}}
+  size_t ret = fwrite(buf, size, n, fp); // stdargs-warning{{The 4th argument to 'fwrite' should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   clang_analyzer_eval(ret <= n); // any-warning{{TRUE}}
   clang_analyzer_eval(ret == n); // any-warning{{TRUE}} any-warning{{FALSE}}
@@ -69,24 +62,21 @@
 
 void test_fseek(void) {
   FILE *fp = tmpfile();
-  fseek(fp, 0, 0); // stdargs-warning{{Function argument constraint is not satisfied}} \
-   // stdargs-note{{The 1st argument should not be NULL}}
+  fseek(fp, 0, 0); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   fclose(fp);
 }
 
 void test_ftell(void) {
   FILE *fp = tmpfile();
-  ftell(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
- // stdargs-note{{The 1st argument should not be NULL}}
+  ftell(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   fclose(fp);
 }
 
 void test_rewind(void) {
   FILE *fp = tmpfile();
-  rewind(fp); // stdargs-warning{{Function argument constraint is not satisfied}} \
-  // stdargs-note{{The 1st argument should not be NULL}}
+  rewind(fp); // stdargs-warning{{should not be NULL}}
   clang_analyzer_eval(fp != NULL); // any-warning{{TRUE}}
   fclose(fp);
 }
@@ -94,8 +84,7 @@
 void test_fgetpos(void) {
   FILE *fp = tmpfile();
   fpos_t pos;
-  fgetpos(fp, &pos); // stdargs-warning{{Function argume

[PATCH] D143735: [clang][dataflow] Convert nonnull pointer parameter to a reference.

2023-02-10 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel updated this revision to Diff 496477.
ymandel added a comment.

add fixme and fix compilation error


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143735

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -374,7 +374,7 @@
 }
 
 // User-provided analysis
-AC.Analysis.transferTypeErased(&Element, State.Lattice, State.Env);
+AC.Analysis.transferTypeErased(Element, State.Lattice, State.Env);
 
 // Post processing
 if (PostVisitCFG) {
Index: clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
@@ -96,7 +96,7 @@
 
   /// Applies the analysis transfer function for a given control flow graph
   /// element and type-erased lattice element.
-  virtual void transferTypeErased(const CFGElement *, TypeErasedLattice &,
+  virtual void transferTypeErased(const CFGElement &, TypeErasedLattice &,
   Environment &) = 0;
 
   /// Applies the analysis transfer function for a given edge from a CFG block
Index: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -119,10 +119,11 @@
 return L1 == L2;
   }
 
-  void transferTypeErased(const CFGElement *Element, TypeErasedLattice &E,
+  void transferTypeErased(const CFGElement &Element, TypeErasedLattice &E,
   Environment &Env) final {
 Lattice &L = llvm::any_cast(E.Value);
-static_cast(this)->transfer(Element, L, Env);
+// FIXME: change the contract of `transfer` to take a reference.
+static_cast(this)->transfer(&Element, L, Env);
   }
 
   void transferBranchTypeErased(bool Branch, const Stmt *Stmt,


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -374,7 +374,7 @@
 }
 
 // User-provided analysis
-AC.Analysis.transferTypeErased(&Element, State.Lattice, State.Env);
+AC.Analysis.transferTypeErased(Element, State.Lattice, State.Env);
 
 // Post processing
 if (PostVisitCFG) {
Index: clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
@@ -96,7 +96,7 @@
 
   /// Applies the analysis transfer function for a given control flow graph
   /// element and type-erased lattice element.
-  virtual void transferTypeErased(const CFGElement *, TypeErasedLattice &,
+  virtual void transferTypeErased(const CFGElement &, TypeErasedLattice &,
   Environment &) = 0;
 
   /// Applies the analysis transfer function for a given edge from a CFG block
Index: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -119,10 +119,11 @@
 return L1 == L2;
   }
 
-  void transferTypeErased(const CFGElement *Element, TypeErasedLattice &E,
+  void transferTypeErased(const CFGElement &Element, TypeErasedLattice &E,
   Environment &Env) final {
 Lattice &L = llvm::any_cast(E.Value);
-static_cast(this)->transfer(Element, L, Env);
+// FIXME: change the contract of `transfer` to take a reference.
+static_cast(this)->transfer(&Element, L, Env);
   }
 
   void transferBranchTypeErased(bool Branch, const Stmt *Stmt,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143194: [clang][analyzer] Make messages of StdCLibraryFunctionsChecker user-friendly

2023-02-10 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

I changed the text descriptions to relational operators at some places, this is 
similar to how other clang analyzer messages look (for example notes at `if` 
statements), it is shorter, and probably more faster to understand ("<= 0" 
instead of "non-positive").


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143194

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


[PATCH] D143735: [clang][dataflow] Convert nonnull pointer parameter to a reference.

2023-02-10 Thread Yitzhak Mandelbaum 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 rGa00f17d81efb: [clang][dataflow] Convert nonnull pointer 
parameter to a reference. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143735

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -374,7 +374,7 @@
 }
 
 // User-provided analysis
-AC.Analysis.transferTypeErased(&Element, State.Lattice, State.Env);
+AC.Analysis.transferTypeErased(Element, State.Lattice, State.Env);
 
 // Post processing
 if (PostVisitCFG) {
Index: clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
@@ -96,7 +96,7 @@
 
   /// Applies the analysis transfer function for a given control flow graph
   /// element and type-erased lattice element.
-  virtual void transferTypeErased(const CFGElement *, TypeErasedLattice &,
+  virtual void transferTypeErased(const CFGElement &, TypeErasedLattice &,
   Environment &) = 0;
 
   /// Applies the analysis transfer function for a given edge from a CFG block
Index: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -119,10 +119,11 @@
 return L1 == L2;
   }
 
-  void transferTypeErased(const CFGElement *Element, TypeErasedLattice &E,
+  void transferTypeErased(const CFGElement &Element, TypeErasedLattice &E,
   Environment &Env) final {
 Lattice &L = llvm::any_cast(E.Value);
-static_cast(this)->transfer(Element, L, Env);
+// FIXME: change the contract of `transfer` to take a reference.
+static_cast(this)->transfer(&Element, L, Env);
   }
 
   void transferBranchTypeErased(bool Branch, const Stmt *Stmt,


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -374,7 +374,7 @@
 }
 
 // User-provided analysis
-AC.Analysis.transferTypeErased(&Element, State.Lattice, State.Env);
+AC.Analysis.transferTypeErased(Element, State.Lattice, State.Env);
 
 // Post processing
 if (PostVisitCFG) {
Index: clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
@@ -96,7 +96,7 @@
 
   /// Applies the analysis transfer function for a given control flow graph
   /// element and type-erased lattice element.
-  virtual void transferTypeErased(const CFGElement *, TypeErasedLattice &,
+  virtual void transferTypeErased(const CFGElement &, TypeErasedLattice &,
   Environment &) = 0;
 
   /// Applies the analysis transfer function for a given edge from a CFG block
Index: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -119,10 +119,11 @@
 return L1 == L2;
   }
 
-  void transferTypeErased(const CFGElement *Element, TypeErasedLattice &E,
+  void transferTypeErased(const CFGElement &Element, TypeErasedLattice &E,
   Environment &Env) final {
 Lattice &L = llvm::any_cast(E.Value);
-static_cast(this)->transfer(Element, L, Env);
+// FIXME: change the contract of `transfer` to take a reference.
+static_cast(this)->transfer(&Element, L, Env);
   }
 
   void transferBranchTypeErased(bool Branch, const Stmt *Stmt,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] a00f17d - [clang][dataflow] Convert nonnull pointer parameter to a reference.

2023-02-10 Thread Yitzhak Mandelbaum via cfe-commits

Author: Yitzhak Mandelbaum
Date: 2023-02-10T15:53:28Z
New Revision: a00f17d81efbd06080761aeef660e5269270a53f

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

LOG: [clang][dataflow] Convert nonnull pointer parameter to a reference.

The parameter in question belongs to a function that is only called once. This 
patch updates the API to use a reference and changes the caller accordingly.

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

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
index 517dd3c9997f9..d7ca721246757 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -119,10 +119,11 @@ class DataflowAnalysis : public 
TypeErasedDataflowAnalysis {
 return L1 == L2;
   }
 
-  void transferTypeErased(const CFGElement *Element, TypeErasedLattice &E,
+  void transferTypeErased(const CFGElement &Element, TypeErasedLattice &E,
   Environment &Env) final {
 Lattice &L = llvm::any_cast(E.Value);
-static_cast(this)->transfer(Element, L, Env);
+// FIXME: change the contract of `transfer` to take a reference.
+static_cast(this)->transfer(&Element, L, Env);
   }
 
   void transferBranchTypeErased(bool Branch, const Stmt *Stmt,

diff  --git 
a/clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h 
b/clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
index 1d7962e9f67a5..d69adfad396d1 100644
--- a/clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
+++ b/clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
@@ -96,7 +96,7 @@ class TypeErasedDataflowAnalysis : public 
Environment::ValueModel {
 
   /// Applies the analysis transfer function for a given control flow graph
   /// element and type-erased lattice element.
-  virtual void transferTypeErased(const CFGElement *, TypeErasedLattice &,
+  virtual void transferTypeErased(const CFGElement &, TypeErasedLattice &,
   Environment &) = 0;
 
   /// Applies the analysis transfer function for a given edge from a CFG block

diff  --git a/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp 
b/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
index b125701212c96..fe00d765b6bef 100644
--- a/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ b/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -374,7 +374,7 @@ transferCFGBlock(const CFGBlock &Block, AnalysisContext &AC,
 }
 
 // User-provided analysis
-AC.Analysis.transferTypeErased(&Element, State.Lattice, State.Env);
+AC.Analysis.transferTypeErased(Element, State.Lattice, State.Env);
 
 // Post processing
 if (PostVisitCFG) {



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


[PATCH] D143194: [clang][analyzer] Make messages of StdCLibraryFunctionsChecker user-friendly

2023-02-10 Thread Balázs Kéri via Phabricator via cfe-commits
balazske marked an inline comment as done.
balazske added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:95
+QualType ArgT, BasicValueFactory &BVF,
+DescString &Out);
+  /// Append textual description of a numeric range out of [RMin,RMax] to the

Szelethus wrote:
> Using a `raw_ostream` as a parameter sounds more elegant than a `SmallString` 
> with a precise stack buffer length. Not to mention that you could call this 
> function with `llvm::errs()` for easy debugging.
I want to improve this in a later patch. The change does involve not new code 
too (`getArgDesc` should be changed too and other places where the messages are 
generated).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143194

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


[PATCH] D143587: [Docs] Multilib design

2023-02-10 Thread Peter Smith via Phabricator via cfe-commits
peter.smith added inline comments.



Comment at: clang/docs/Multilib.rst:125
+``-fno-exceptions`` multilib variant need only contain C++ libraries.
+
+Stability

Although implicit in the mechanism, is it worth highlighting that layered 
multib.yaml authors will need to make sure that the includes and the libraries 
in the layer need to be complete enough to mask any incompatibilities? 

For example if in the `-fno-exceptions` case there exists a library `libX.a` 
that is affected by `-fno-exceptions` but is present in the "Core directory" 
but not the layered no-exceptions directory then the exceptions libX.a will be 
selected.

/fp/libX.a (should have a noexcept variant in noexcept but multilib implementer 
gets it wrong!)
/fp/libY.a
/fp/lib/noexecpt/libY.a

execeptions is perhaps not the best example here as including a file with 
exceptions when the intention is `-fno-exceptions` is not optimal, but it will 
work. If there is layering for floating point calling conventions then a mix 
could result in a broken program.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143587

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


[PATCH] D143075: BareMetal ToolChain multilib layering

2023-02-10 Thread Peter Smith via Phabricator via cfe-commits
peter.smith added a comment.

No comments on the implementation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143075

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


[PATCH] D143745: Make section attribute and -ffunction-sections play nicely

2023-02-10 Thread Paul Robinson via Phabricator via cfe-commits
probinson created this revision.
probinson added reviewers: rjmccall, MaskRay.
Herald added a project: All.
probinson requested review of this revision.

People use -ffunction-sections to put each function into its own
object-file section; this makes linker garbage-collection simpler.
However, if there's an explicit __attribute__((section("name"))
on the function, all functions with that attribute end up in a
single section, defeating the linker GC.

Use section groups to make these things work together.


https://reviews.llvm.org/D143745

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/section-attr-comdat.cpp


Index: clang/test/CodeGen/section-attr-comdat.cpp
===
--- /dev/null
+++ clang/test/CodeGen/section-attr-comdat.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -triple=x86_64-linux -emit-llvm  %s -o - | \
+// RUN: FileCheck %s --check-prefix=NOCOMDAT
+// RUN: %clang_cc1 -triple=x86_64-linux -emit-llvm -ffunction-sections %s -o - 
| \
+// RUN: FileCheck %s --check-prefix=COMDAT
+
+// template function = comdat always.
+template
+__attribute__((section("foo"))) T ftemplate(T a) { return a + 1; }
+__attribute__((section("foo"))) int fglobal(int a) { return ftemplate(a) + 2; }
+
+// NOCOMDAT-DAG: ${{.*}}ftemplate{{.*}} = comdat any
+// NOCOMDAT-DAG: define {{.*}}ftemplate{{.*}} section "foo" comdat {
+// NOCOMDAT-DAG: define {{.*}}fglobal{{.*}} section "foo" {
+
+// COMDAT-DAG: ${{.*}}ftemplate{{.*}} = comdat any
+// COMDAT-DAG: ${{.*}}fglobal{{.*}} = comdat nodeduplicate
+// COMDAT-DAG: define {{.*}}ftemplate{{.*}} section "foo" comdat {
+// COMDAT-DAG: define {{.*}}fglobal{{.*}} section "foo" comdat {
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -2293,6 +2293,18 @@
   if (auto *SA = D->getAttr())
 if (!D->getAttr())
   F->addFnAttr("implicit-section-name", SA->getName());
+  // If we have -ffunction-sections, and also an explicit section name,
+  // put the function into a section group so that various linker GC
+  // operations will still work with this function.
+  if (CodeGenOpts.FunctionSections && getTriple().supportsCOMDAT() &&
+  D->hasAttr()) {
+// Don't replace a real comdat.
+if (!F->getComdat()) {
+  llvm::Comdat *C = TheModule.getOrInsertComdat(F->getName());
+  C->setSelectionKind(llvm::Comdat::NoDeduplicate);
+  F->setComdat(C);
+}
+  }
 
   llvm::AttrBuilder Attrs(F->getContext());
   if (GetCPUAndFeaturesAttributes(GD, Attrs)) {


Index: clang/test/CodeGen/section-attr-comdat.cpp
===
--- /dev/null
+++ clang/test/CodeGen/section-attr-comdat.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -triple=x86_64-linux -emit-llvm  %s -o - | \
+// RUN: FileCheck %s --check-prefix=NOCOMDAT
+// RUN: %clang_cc1 -triple=x86_64-linux -emit-llvm -ffunction-sections %s -o - | \
+// RUN: FileCheck %s --check-prefix=COMDAT
+
+// template function = comdat always.
+template
+__attribute__((section("foo"))) T ftemplate(T a) { return a + 1; }
+__attribute__((section("foo"))) int fglobal(int a) { return ftemplate(a) + 2; }
+
+// NOCOMDAT-DAG: ${{.*}}ftemplate{{.*}} = comdat any
+// NOCOMDAT-DAG: define {{.*}}ftemplate{{.*}} section "foo" comdat {
+// NOCOMDAT-DAG: define {{.*}}fglobal{{.*}} section "foo" {
+
+// COMDAT-DAG: ${{.*}}ftemplate{{.*}} = comdat any
+// COMDAT-DAG: ${{.*}}fglobal{{.*}} = comdat nodeduplicate
+// COMDAT-DAG: define {{.*}}ftemplate{{.*}} section "foo" comdat {
+// COMDAT-DAG: define {{.*}}fglobal{{.*}} section "foo" comdat {
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -2293,6 +2293,18 @@
   if (auto *SA = D->getAttr())
 if (!D->getAttr())
   F->addFnAttr("implicit-section-name", SA->getName());
+  // If we have -ffunction-sections, and also an explicit section name,
+  // put the function into a section group so that various linker GC
+  // operations will still work with this function.
+  if (CodeGenOpts.FunctionSections && getTriple().supportsCOMDAT() &&
+  D->hasAttr()) {
+// Don't replace a real comdat.
+if (!F->getComdat()) {
+  llvm::Comdat *C = TheModule.getOrInsertComdat(F->getName());
+  C->setSelectionKind(llvm::Comdat::NoDeduplicate);
+  F->setComdat(C);
+}
+  }
 
   llvm::AttrBuilder Attrs(F->getContext());
   if (GetCPUAndFeaturesAttributes(GD, Attrs)) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143745: Make section attribute and -ffunction-sections play nicely

2023-02-10 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

This works in my simple test cases, but I'm not 100% sure it's (a) the best 
place to do this, or (b) the only place that needs to do this.
Really we should guarantee that `comdat any` wins over `comdat nodeduplicate` 
in all cases.


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

https://reviews.llvm.org/D143745

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


[clang] 7da2d64 - [clang] [extract-api] Don't crash for category in libclang APIs

2023-02-10 Thread Daniel Grumberg via cfe-commits

Author: Daniel Grumberg
Date: 2023-02-10T16:30:19Z
New Revision: 7da2d644e0398be39e188ea6eacab2a942e0fa7e

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

LOG: [clang] [extract-api] Don't crash for category in libclang APIs

Remove failure conditions for categories in libclang and return empty
content instead.

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

Added: 


Modified: 
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
clang/test/Index/extract-api-cursor.m

Removed: 




diff  --git a/clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp 
b/clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
index 01e9b37d26802..8beb01697bc2e 100644
--- a/clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
+++ b/clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
@@ -487,6 +487,7 @@ bool generatePathComponents(
   SmallVector ReverseComponenents;
   ReverseComponenents.emplace_back(Record.USR, Record.Name, Record.getKind());
   const auto *CurrentParent = &Record.ParentInformation;
+  bool FailedToFindParent = false;
   while (CurrentParent && !CurrentParent->empty()) {
 PathComponent CurrentParentComponent(CurrentParent->ParentUSR,
  CurrentParent->ParentName,
@@ -509,8 +510,10 @@ bool generatePathComponents(
 
 // The parent record doesn't exist which means the symbol shouldn't be
 // treated as part of the current product.
-if (!ParentRecord)
-  return true;
+if (!ParentRecord) {
+  FailedToFindParent = true;
+  break;
+}
 
 ReverseComponenents.push_back(std::move(CurrentParentComponent));
 CurrentParent = &ParentRecord->ParentInformation;
@@ -519,8 +522,9 @@ bool generatePathComponents(
   for (const auto &PC : reverse(ReverseComponenents))
 ComponentTransformer(PC);
 
-  return false;
+  return FailedToFindParent;
 }
+
 Object serializeParentContext(const PathComponent &PC, Language Lang) {
   Object ParentContextElem;
   ParentContextElem["usr"] = PC.USR;
@@ -533,12 +537,15 @@ template 
 Array generateParentContexts(const RecordTy &Record, const APISet &API,
  Language Lang) {
   Array ParentContexts;
-  if (generatePathComponents(
-  Record, API, [Lang, &ParentContexts](const PathComponent &PC) {
-ParentContexts.push_back(serializeParentContext(PC, Lang));
-  }))
-ParentContexts.clear();
-  ParentContexts.pop_back();
+  generatePathComponents(Record, API,
+ [Lang, &ParentContexts](const PathComponent &PC) {
+   ParentContexts.push_back(
+   serializeParentContext(PC, Lang));
+ });
+
+  // The last component would be the record itself so let's remove it.
+  if (!ParentContexts.empty())
+ParentContexts.pop_back();
 
   return ParentContexts;
 }
@@ -865,6 +872,9 @@ SymbolGraphSerializer::serializeSingleSymbolSGF(StringRef 
USR,
   if (!Record)
 return {};
 
+  if (isa(Record))
+return {};
+
   Object Root;
   APIIgnoresList EmptyIgnores;
   SymbolGraphSerializer Serializer(API, EmptyIgnores,

diff  --git a/clang/test/Index/extract-api-cursor.m 
b/clang/test/Index/extract-api-cursor.m
index a462c115826c1..078f2f52e215c 100644
--- a/clang/test/Index/extract-api-cursor.m
+++ b/clang/test/Index/extract-api-cursor.m
@@ -25,6 +25,12 @@ @interface Derived: Base
 - (void)derivedMethodWithValue:(id)value;
 @end
 
+/// This won't show up in docs because we can't serialize it
+@interface Derived ()
+/// Derived method in category docs, won't show up either.
+- (void)derivedMethodInCategory;
+@end
+
 // RUN: c-index-test -single-symbol-sgfs local %s | FileCheck %s
 
 // Checking for Foo
@@ -53,7 +59,7 @@ - (void)derivedMethodWithValue:(id)value;
 
 // Checking for baseProperty
 // CHECK-NEXT: 
"parentContexts":[{"kind":"objective-c.class","name":"Base","usr":"c:objc(cs)Base"}]
-// 
CHECK-SAME:"relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
+// CHECK-SAME: 
"relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
 // CHECK-SAME: "isSystem":false
 // CHECK-SAME: "usr":"c:@S@Foo"}]
 // CHECK-SAME: 
"relationships":[{"kind":"memberOf","source":"c:objc(cs)Base(py)baseProperty","target":"c:objc(cs)Base"
@@ -63,7 +69,7 @@ - (void)derivedMethodWithValue:(id)value;
 
 // Checking for baseMethodWithArg
 // CHECK-NEXT: 
"parentContexts":[{"kind":"objective-c.class","name":"Base","usr":"c:objc(cs)Base"}]
-// CHECK-SAME:"relatedSymbols":[]
+// CHECK-SAME: "relatedSymbols":[]
 // CHECK-SAME: 
"relationships":[{"kind":"memberOf","source":"c:objc(cs)Base(im)baseMethodWithArg:","target":"c:objc(cs)Base"
 // CHECK-SAME: "text":"Base method docs"
 /

[PATCH] D142101: [clang] [extract-api] Don't crash for category in libclang APIs

2023-02-10 Thread Daniel Grumberg 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 rG7da2d644e039: [clang] [extract-api] Don't crash for 
category in libclang APIs (authored by dang).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142101

Files:
  clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
  clang/test/Index/extract-api-cursor.m

Index: clang/test/Index/extract-api-cursor.m
===
--- clang/test/Index/extract-api-cursor.m
+++ clang/test/Index/extract-api-cursor.m
@@ -25,6 +25,12 @@
 - (void)derivedMethodWithValue:(id)value;
 @end
 
+/// This won't show up in docs because we can't serialize it
+@interface Derived ()
+/// Derived method in category docs, won't show up either.
+- (void)derivedMethodInCategory;
+@end
+
 // RUN: c-index-test -single-symbol-sgfs local %s | FileCheck %s
 
 // Checking for Foo
@@ -53,7 +59,7 @@
 
 // Checking for baseProperty
 // CHECK-NEXT: "parentContexts":[{"kind":"objective-c.class","name":"Base","usr":"c:objc(cs)Base"}]
-// CHECK-SAME:"relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
+// CHECK-SAME: "relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
 // CHECK-SAME: "isSystem":false
 // CHECK-SAME: "usr":"c:@S@Foo"}]
 // CHECK-SAME: "relationships":[{"kind":"memberOf","source":"c:objc(cs)Base(py)baseProperty","target":"c:objc(cs)Base"
@@ -63,7 +69,7 @@
 
 // Checking for baseMethodWithArg
 // CHECK-NEXT: "parentContexts":[{"kind":"objective-c.class","name":"Base","usr":"c:objc(cs)Base"}]
-// CHECK-SAME:"relatedSymbols":[]
+// CHECK-SAME: "relatedSymbols":[]
 // CHECK-SAME: "relationships":[{"kind":"memberOf","source":"c:objc(cs)Base(im)baseMethodWithArg:","target":"c:objc(cs)Base"
 // CHECK-SAME: "text":"Base method docs"
 // CHECK-SAME: "kind":{"displayName":"Instance Method","identifier":"objective-c.method"}
@@ -79,7 +85,7 @@
 
 // Checking for protocolProperty
 // CHECK-NEXT: "parentContexts":[{"kind":"objective-c.protocol","name":"Protocol","usr":"c:objc(pl)Protocol"}]
-// CHECK-SAME:"relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
+// CHECK-SAME: "relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
 // CHECK-SAME: "isSystem":false
 // CHECK-SAME: "usr":"c:@S@Foo"}]
 // CHECK-SAME: "relationships":[{"kind":"memberOf","source":"c:objc(pl)Protocol(py)protocolProperty","target":"c:objc(pl)Protocol"
@@ -89,7 +95,7 @@
 
 // Checking for Derived
 // CHECK-NEXT: "parentContexts":[]
-// CHECK-SAME:"relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
+// CHECK-SAME: "relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
 // CHECK-SAME: "isSystem":false
 // CHECK-SAME: "usr":"c:objc(cs)Base"}]
 // CHECK-SAME: "relationships":[{"kind":"inheritsFrom","source":"c:objc(cs)Derived","target":"c:objc(cs)Base"
@@ -99,8 +105,11 @@
 
 // Checking for derivedMethodWithValue
 // CHECK-NEXT: "parentContexts":[{"kind":"objective-c.class","name":"Derived","usr":"c:objc(cs)Derived"}]
-// CHECK-SAME:"relatedSymbols":[]
+// CHECK-SAME: "relatedSymbols":[]
 // CHECK-SAME: "relationships":[{"kind":"memberOf","source":"c:objc(cs)Derived(im)derivedMethodWithValue:","target":"c:objc(cs)Derived"
 // CHECK-SAME: "text":"Derived method docs"
 // CHECK-SAME: "kind":{"displayName":"Instance Method","identifier":"objective-c.method"}
 // CHECK-SAME: "title":"derivedMethodWithValue:"
+
+// CHECK-NOT: This won't show up in docs because we can't serialize it
+// CHECK-NOT: Derived method in category docs, won't show up either.
Index: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
===
--- clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
+++ clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
@@ -487,6 +487,7 @@
   SmallVector ReverseComponenents;
   ReverseComponenents.emplace_back(Record.USR, Record.Name, Record.getKind());
   const auto *CurrentParent = &Record.ParentInformation;
+  bool FailedToFindParent = false;
   while (CurrentParent && !CurrentParent->empty()) {
 PathComponent CurrentParentComponent(CurrentParent->ParentUSR,
  CurrentParent->ParentName,
@@ -509,8 +510,10 @@
 
 // The parent record doesn't exist which means the symbol shouldn't be
 // treated as part of the current product.
-if (!ParentRecord)
-  return true;
+if (!ParentRecord) {
+  FailedToFindParent = true;
+  break;
+}
 
 ReverseComponenents.push_back(std::move(CurrentParentComponent));
 CurrentParent = &ParentRecord->ParentInformation;
@@ -519,8 +522,9 @@
   for (const auto &PC : reverse(ReverseComponenents))
 ComponentTransformer(PC);
 
-  return false;
+  return FailedToF

[PATCH] D143509: Move the BySpelling map to IncludeStructure.

2023-02-10 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/Headers.cpp:76
+Out->MainFileIncludesBySpelling.try_emplace(Inc.Written)
+.first->second.push_back(static_cast(*Inc.HeaderID));
   }

right now we're only storing "resolved" includes from the main file and not 
all, this is creating a discrepancy between the view one gets through 
`MainFileIncludes` and through this map.
in addition to that only storing `HeaderID` gets the job done for 
IncludeCleaner, but won't really help anyone that wants to match main file 
includes apart from that (there's no easy way to go from a `HeaderID` to an 
`Inclusion`).

so instead of storing the `HeaderID` in the map values, we can actually store 
indexes into `MainFileIncludes`. later on during the lookup, we can build a 
`SmallVector` that contains pointers to the relevant includes. 
WDYT?



Comment at: clang-tools-extra/clangd/Headers.h:166
+  llvm::SmallVector
+  lookupHeaderIDsBySpelling(llvm::StringRef Spelling) const {
+return MainFileIncludesBySpelling.lookup(Spelling);

what about renaming `lookupHeaderIDsBySpelling` to 
`mainFileIncludesWithSpelling`. with a comment explaining `Returns includes 
inside the main file with the given Spelling. Spelling should include brackets 
or quotes, e.g. `.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143509

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


[PATCH] D143509: Move the BySpelling map to IncludeStructure.

2023-02-10 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

oh forgot to mention, could you also please add some tests into 
llvm-project/clang-tools-extra/clangd/unittests/HeadersTests.cpp ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143509

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


[PATCH] D122215: [WebAssembly] Initial support for reference type externref in clang

2023-02-10 Thread Alex Bradbury via Phabricator via cfe-commits
asb added a comment.

@pmatos and I have tried and failed to reproduce the assert in the stage3 msan 
build locally (both of us on separate machines, different environments). We've 
reached out to @vitalybuka via email for any help in reproducing, because we're 
somewhat stumped at the moment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122215

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


[PATCH] D137527: [C++20] [Modules] [ClangScanDeps] Add ClangScanDeps support for C++20 Named Modules in P1689 format (2/4)

2023-02-10 Thread Tom Weaver via Phabricator via cfe-commits
TWeaver added a comment.

@thakis @ChuanqiXu I have a revision up for review here 
https://reviews.llvm.org/D143749 that adds back the UNSUPPORTED: system-windows 
that was reverted in https://reviews.llvm.org/D139168


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137527

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


[PATCH] D143750: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

2023-02-10 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel created this revision.
ymandel added reviewers: xazax.hun, gribozavr2, sgatev.
Herald added a subscriber: rnkovacs.
Herald added a reviewer: njames93.
Herald added a project: All.
ymandel requested review of this revision.
Herald added a project: clang-tools-extra.

Removes a reference to google-internal document and expands the relevant 
material in place.

Fixes #60633.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143750

Files:
  
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst


Index: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as 
``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as 
equivalent,
+even though there are subtle differences related to exceptions versus undefined
+behavior. See *Additional notes*, below, for more information on this topic.
 
 An access to the value of an ``optional`` is considered safe if and only if
 code in the local scope (for example, a function body) ensures that the
@@ -273,3 +271,26 @@
 A future version will expand the scope to lambdas, following the rules
 outlined above. It is best to follow the same principles when using
 optionals in lambdas.
+
+Access with ``operator*()`` vs. ``value()``
+---
+
+Given that ``value()`` has well-defined program termination behavior, why treat
+it the same as ``operator*()`` which causes undefined behavior (UB)? That is,
+why is it considered unsafe to access an optional with ``value()``, if it's not
+provably populated with a value?  For that matter, why is ``CHECK()`` followed
+by ``operator*()`` any better than ``value()``, given that they are 
semantically
+equivalent (on configurations that disable exceptions)?
+
+The answer is that we assume most users do not realize the difference between
+``value()`` and ``operator*()``. Shifting to ``operator*()`` and some form of
+explicit value-presence check or explicit program termination has two
+advantages:
+
+  * Readability. The check, and any potential side effects like program
+shutdown, are very clear in the code. Separating access from checks can
+actually make the checks more obvious.
+
+  * Performance. A single check can cover many or even all accesses within
+scope. This gives the user the best of both worlds -- the safety of a
+dynamic check, but without incurring redundant costs.


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as ``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as equivalent,
+even though th

[PATCH] D143624: Inlining: Run the legacy AlwaysInliner before the regular inliner.

2023-02-10 Thread Amara Emerson via Phabricator via cfe-commits
aemerson added a comment.

In D143624#4118341 , @dmgreen wrote:

>> It’s not clear from the original commit message why the test is related to 
>> inlining order? It seems entirely testing vectorization cost model which 
>> should be insensitive to these kind of changes, right?
>
> It's a phase ordering test - it's testing the entire pipeline including all 
> the inlining and simplification that needs to happen :)
>
> You can run update_test_checks of the file to see the differences. I believe 
> the inlining causes differences in the code that then cause different vector 
> factors to be chosen. I can try to add a similar test for the other case that 
> got worse, if they are similar.

I’ll take a look, but this indicates to me that there’s something missing from 
the vectoriser or later passes rather than a problem with the inliners 
behaviour.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143624

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


[PATCH] D143751: [clang][analyzer][NFC] Refactor code of StdLibraryFunctionsChecker.

2023-02-10 Thread Balázs Kéri via Phabricator via cfe-commits
balazske created this revision.
Herald added subscribers: steakhal, manas, ASDenysPetrov, martong, gamesh411, 
dkrupp, donat.nagy, Szelethus, mikhail.ramalho, a.sidorin, szepet, 
baloghadamsoftware, xazax.hun.
Herald added a reviewer: Szelethus.
Herald added a reviewer: NoQ.
Herald added a project: All.
balazske requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The code was difficult to maintain (big internal class definitions
with long inline functions, other functions of the same class at
different location far away, irregular ordering of classes and
function definitions). It is now improved to some extent.
New functions are added to RangeConstraint to remove code repetition,
these are useful for planned new features too.
Comments are improved.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143751

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

Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -68,6 +68,19 @@
   /// to us. If he doesn't, he performs additional invalidations.
   enum InvalidationKind { NoEvalCall, EvalCallAsPure };
 
+  /// Given a range, should the argument stay inside or outside this range?
+  enum RangeKind { OutOfRange, WithinRange };
+
+  static RangeKind negateKind(RangeKind K) {
+switch (K) {
+case OutOfRange:
+  return WithinRange;
+case WithinRange:
+  return OutOfRange;
+}
+llvm_unreachable("Unknown range kind");
+  }
+
   // The universal integral type to use in value range descriptions.
   // Unsigned to make sure overflows are well-defined.
   typedef uint64_t RangeInt;
@@ -82,9 +95,11 @@
   /// ArgNo in CallExpr and CallEvent is defined as Unsigned, but
   /// obviously uint32_t should be enough for all practical purposes.
   typedef uint32_t ArgNo;
+  /// Special argument number for specifying the return value.
   static const ArgNo Ret;
 
   using DescString = SmallString<96>;
+
   /// Returns the string representation of an argument index.
   /// E.g.: (1) -> '1st arg', (2) - > '2nd arg'
   static SmallString<8> getArgDesc(ArgNo);
@@ -102,10 +117,12 @@
   class ValueConstraint;
 
   // Pointer to the ValueConstraint. We need a copyable, polymorphic and
-  // default initialize able type (vector needs that). A raw pointer was good,
+  // default initializable type (vector needs that). A raw pointer was good,
   // however, we cannot default initialize that. unique_ptr makes the Summary
   // class non-copyable, therefore not an option. Releasing the copyability
   // requirement would render the initialization of the Summary map infeasible.
+  // A new value constraint is created furthermore by the negate functionality
+  // of the constraint and returned as pointer.
   using ValueConstraintPtr = std::shared_ptr;
 
   /// Polymorphic base class that represents a constraint on a given argument
@@ -122,35 +139,12 @@
   public:
 ValueConstraint(ArgNo ArgN) : ArgN(ArgN) {}
 virtual ~ValueConstraint() {}
+
 /// Apply the effects of the constraint on the given program state. If null
 /// is returned then the constraint is not feasible.
 virtual ProgramStateRef apply(ProgramStateRef State, const CallEvent &Call,
   const Summary &Summary,
   CheckerContext &C) const = 0;
-virtual ValueConstraintPtr negate() const {
-  llvm_unreachable("Not implemented");
-};
-
-/// Check whether the constraint is malformed or not. It is malformed if the
-/// specified argument has a mismatch with the given FunctionDecl (e.g. the
-/// arg number is out-of-range of the function's argument list).
-bool checkValidity(const FunctionDecl *FD) const {
-  const bool ValidArg = ArgN == Ret || ArgN < FD->getNumParams();
-  assert(ValidArg && "Arg out of range!");
-  if (!ValidArg)
-return false;
-  // Subclasses may further refine the validation.
-  return checkSpecificValidity(FD);
-}
-ArgNo getArgNo() const { return ArgN; }
-
-/// Return those arguments that should be tracked when we report a bug. By
-/// default it is the argument that is constrained, however, in some special
-/// cases we need to track other arguments as well. E.g. a buffer size might
-/// be encoded in another argument.
-virtual std::vector getArgsToTrack() const { return {ArgN}; }
-
-virtual StringRef getName() const = 0;
 
 /// Represents that in which context do we require a description of the
 /// constraint.
@@ -158,6 +152,8 @@
   /// The constraint is violated.
   Violation,
   /// We assume that the constraint is satisfied.
+  /// This can be used when a precondition is satisfie

[PATCH] D143522: [AMDGPU] Set a data layout entry for buffer descriptors (addrspace 7)

2023-02-10 Thread Krzysztof Drewniak via Phabricator via cfe-commits
krzysz00 updated this revision to Diff 496515.
krzysz00 added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Apparently clang has its own copy of this data layout.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143522

Files:
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/test/CodeGen/target-data.c
  clang/test/CodeGenOpenCL/amdgpu-env-amdgcn.cl
  llvm/lib/IR/AutoUpgrade.cpp
  llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
  
llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-non-integral-address-spaces.ll
  llvm/test/CodeGen/AMDGPU/addrspacecast-captured.ll
  llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa.ll
  llvm/test/CodeGen/AMDGPU/cgp-addressing-modes.ll
  llvm/test/CodeGen/AMDGPU/force-alwaysinline-lds-global-address.ll
  llvm/test/CodeGen/AMDGPU/loop-idiom.ll
  llvm/test/CodeGen/AMDGPU/mdt-preserving-crash.ll
  llvm/test/CodeGen/AMDGPU/noop-shader-O0.ll
  llvm/test/CodeGen/AMDGPU/nullptr-addrspace-7-tmp.ll
  llvm/test/CodeGen/AMDGPU/nullptr.ll
  llvm/test/CodeGen/AMDGPU/promote-alloca-lifetime.ll
  llvm/test/CodeGen/AMDGPU/promote-alloca-to-lds-select.ll
  llvm/test/CodeGen/AMDGPU/sgpr-copy-local-cse.ll
  llvm/test/CodeGen/AMDGPU/unroll.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/adaptive_constant_global_redzones.ll
  llvm/test/Instrumentation/AddressSanitizer/AMDGPU/adaptive_global_redzones.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/asan_do_not_instrument_lds.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/asan_do_not_instrument_scratch.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/asan_instrument_constant_address_space.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/asan_instrument_generic_address_space.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/asan_instrument_global_address_space.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/global_metadata_addrspacecasts.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/no_redzones_in_lds_globals.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/no_redzones_in_scratch_globals.ll
  llvm/test/Transforms/AlignmentFromAssumptions/amdgpu-crash.ll
  llvm/test/Transforms/AtomicExpand/AMDGPU/expand-atomic-i16.ll
  llvm/test/Transforms/EarlyCSE/AMDGPU/memrealtime.ll
  llvm/test/Transforms/IndVarSimplify/AMDGPU/no-widen-to-i64.ll
  llvm/test/Transforms/InferAddressSpaces/AMDGPU/noop-ptrint-pair.ll
  llvm/test/Transforms/InferAddressSpaces/AMDGPU/ptrmask.ll
  llvm/test/Transforms/InferAddressSpaces/X86/noop-ptrint-pair.ll
  llvm/test/Transforms/Inline/AMDGPU/amdgpu-inline-alloca-argument.ll
  llvm/test/Transforms/InstCombine/AMDGPU/memcpy-from-constant.ll
  llvm/test/Transforms/InstCombine/alloca-in-non-alloca-as.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/aa-metadata.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/adjust-alloca-alignment.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/complex-index.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/extended-index.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/gep-bitcast.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/insertion-point.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/interleaved-mayalias-store.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/invariant-load.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/merge-stores-private.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/merge-stores.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/merge-vectors.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/missing-alignment.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/multiple_tails.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/no-implicit-float.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/optnone.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/pointer-elements.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/selects-inseltpoison.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/selects.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/store_with_aliasing_load.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/weird-type-accesses.ll
  llvm/test/Transforms/LoopLoadElim/pr46854-adress-spaces.ll
  llvm/test/Transforms/LoopStrengthReduce/AMDGPU/atomics.ll
  
llvm/test/Transforms/LoopStrengthReduce/AMDGPU/different-addrspace-addressing-mode-loops.ll
  llvm/test/Transforms/LoopStrengthReduce/AMDGPU/lsr-invalid-ptr-extend.ll
  llvm/test/Transforms/LoopStrengthReduce/AMDGPU/lsr-postinc-pos-addrspace.ll
  llvm/test/Transforms/LoopStrengthReduce/AMDGPU/preserve-addrspace-assert.ll
  llvm/test/Transforms/OpenMP/attributor_pointer_offset_crash.ll
  llvm/test/Transforms/OpenMP/spmdization_constant_prop.ll
  llvm/test/Transforms/OpenMP/values_in_offload_arrays.alloca.ll
  
llvm/test/Transforms/SLPVectorizer/AMDGPU/address-space-ptr-sze-gep-index-assert.ll
  llvm/test/Transforms/VectorCombine/AMDGPU/as-transition-inseltpoison.ll

[PATCH] D143755: [clang-format] Add a space between an overloaded operator and '>'

2023-02-10 Thread Owen Pan via Phabricator via cfe-commits
owenpan created this revision.
owenpan added reviewers: MyDeveloperDay, HazardyKnusperkeks, rymiel.
owenpan added a project: clang-format.
Herald added a project: All.
owenpan requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The token annotator doesn't annotate the template opener and closer as such if 
they enclose an overloaded operator. This causes the space between the operator 
and the closer to be removed, resulting
in invalid C++ code.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143755

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/TokenAnnotatorTest.cpp

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -574,6 +574,72 @@
   EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_OverloadedOperatorLParen);
 }
 
+TEST_F(TokenAnnotatorTest, OverloadedOperatorInTemplate) {
+  struct {
+const char *Text;
+tok::TokenKind Kind;
+  } Operators[] = {{"+", tok::plus},
+   {"-", tok::minus},
+   // FIXME:
+   // {"*", tok::star},
+   {"/", tok::slash},
+   {"%", tok::percent},
+   {"^", tok::caret},
+   // FIXME:
+   // {"&", tok::amp},
+   {"|", tok::pipe},
+   {"~", tok::tilde},
+   {"!", tok::exclaim},
+   {"=", tok::equal},
+   // FIXME:
+   // {"<", tok::less},
+   {">", tok::greater},
+   {"+=", tok::plusequal},
+   {"-=", tok::minusequal},
+   {"*=", tok::starequal},
+   {"/=", tok::slashequal},
+   {"%=", tok::percentequal},
+   {"^=", tok::caretequal},
+   {"&=", tok::ampequal},
+   {"|=", tok::pipeequal},
+   // FIXME:
+   // {"<<", tok::lessless},
+   // {">>", tok::greatergreater},
+   {">>=", tok::greatergreaterequal},
+   {"<<=", tok::lesslessequal},
+   {"==", tok::equalequal},
+   {"!=", tok::exclaimequal},
+   {"<=", tok::lessequal},
+   {">=", tok::greaterequal},
+   {"<=>", tok::spaceship},
+   {"&&", tok::ampamp},
+   {"||", tok::pipepipe},
+   {"++", tok::plusplus},
+   {"--", tok::minusminus},
+   {",", tok::comma},
+   {"->*", tok::arrowstar},
+   {"->", tok::arrow}};
+
+  for (const auto &Operator : Operators) {
+std::string Input("C<&operator ");
+Input += Operator.Text;
+Input += " > a;";
+auto Tokens = annotate(std::string(Input));
+ASSERT_EQ(Tokens.size(), 9u) << Tokens;
+EXPECT_TOKEN(Tokens[1], tok::less, TT_TemplateOpener);
+EXPECT_TOKEN(Tokens[4], Operator.Kind, TT_OverloadedOperator);
+EXPECT_TOKEN(Tokens[5], tok::greater, TT_TemplateCloser);
+  }
+
+  auto Tokens = annotate("C<&operator< > lt;");
+  ASSERT_EQ(Tokens.size(), 12u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[4], tok::less, TT_OverloadedOperator);
+  EXPECT_TOKEN(Tokens[5], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[7], tok::greater, TT_TemplateCloser);
+  EXPECT_TOKEN(Tokens[8], tok::greater, TT_TemplateCloser);
+}
+
 TEST_F(TokenAnnotatorTest, UnderstandsRequiresClausesAndConcepts) {
   auto Tokens = annotate("template \n"
  "concept C = (Foo && Bar) && (Bar && Baz);");
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -10663,6 +10663,14 @@
   verifyFormat("foo() { ::operator new(n * sizeof(foo)); }");
 }
 
+TEST_F(FormatTest, SpaceBeforeTemplateCloser) {
+  verifyFormat("C<&operator- > minus;");
+  verifyFormat("C<&operator> > gt;");
+  verifyFormat("C<&operator>= > ge;");
+  verifyFormat("C<&operator<= > le;");
+  verifyFormat("C<&operator< > lt;");
+}
+
 TEST_F(FormatTest, UnderstandsFunctionRefQualification) {
   verifyFormat("void A::b() && {}");
   verifyFormat("void A::b() && noexcept {}");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1219,9 +1219,14 @@
  !CurrentToken->isOneOf(tok::l_paren, tok::semi, tok::r_paren)) {
 if (CurrentToken->isOneOf(tok::star, tok::amp))
   CurrentTok

[PATCH] D143750: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

2023-02-10 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst:278
+
+Given that ``value()`` has well-defined program termination behavior, why treat
+it the same as ``operator*()`` which causes undefined behavior (UB)? That is,

Strictly speaking, `value` on an empty optional will not terminate the program. 
It will raise an exception that can be handled.

(Of course, at Google, exceptions are banned so termination is right in that 
context.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143750

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


[PATCH] D143750: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

2023-02-10 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel updated this revision to Diff 496527.
ymandel added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143750

Files:
  
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst


Index: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as 
``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as 
equivalent,
+even though there are subtle differences related to exceptions versus undefined
+behavior. See *Additional notes*, below, for more information on this topic.
 
 An access to the value of an ``optional`` is considered safe if and only if
 code in the local scope (for example, a function body) ensures that the
@@ -273,3 +271,27 @@
 A future version will expand the scope to lambdas, following the rules
 outlined above. It is best to follow the same principles when using
 optionals in lambdas.
+
+Access with ``operator*()`` vs. ``value()``
+---
+
+Given that ``value()`` has well-defined behavior (either throwing an exception
+or terminating the program), why treat it the same as ``operator*()`` which
+causes undefined behavior (UB)? That is, why is it considered unsafe to access
+an optional with ``value()``, if it's not provably populated with a value?  For
+that matter, why is ``CHECK()`` followed by ``operator*()`` any better than
+``value()``, given that they are semantically equivalent (on configurations 
that
+disable exceptions)?
+
+The answer is that we assume most users do not realize the difference between
+``value()`` and ``operator*()``. Shifting to ``operator*()`` and some form of
+explicit value-presence check or explicit program termination has two
+advantages:
+
+  * Readability. The check, and any potential side effects like program
+shutdown, are very clear in the code. Separating access from checks can
+actually make the checks more obvious.
+
+  * Performance. A single check can cover many or even all accesses within
+scope. This gives the user the best of both worlds -- the safety of a
+dynamic check, but without incurring redundant costs.


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as ``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as equivalent,
+even though there are subtle differences related to exceptions versus undefined
+behavior. See *Additional notes*, below, for more information on this topic.
 
 An access to the value of an ``optional``

[PATCH] D143750: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

2023-02-10 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel marked an inline comment as done.
ymandel added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst:278
+
+Given that ``value()`` has well-defined program termination behavior, why treat
+it the same as ``operator*()`` which causes undefined behavior (UB)? That is,

xazax.hun wrote:
> Strictly speaking, `value` on an empty optional will not terminate the 
> program. It will raise an exception that can be handled.
> 
> (Of course, at Google, exceptions are banned so termination is right in that 
> context.)
Right! Updated to mention both possibilities. Thx


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143750

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


[PATCH] D143755: [clang-format] Add a space between an overloaded operator and '>'

2023-02-10 Thread Igor Kushnir via Phabricator via cfe-commits
vedgy added a comment.

Hi @owenpan. Thank you for fixing this bug!
Have you noticed this paragraph in my bug report?

> I believe `clang_getTypeSpelling()`, or more likely `QualType::print()` used 
> by it, should insert a tab character between such tokens to pretty-print 
> compilable code. The tab character is preferable to the space character here, 
> because the users may rely on the fact that pretty-printed binary operators 
> are surrounded by spaces to distinguish them from angle brackets.

KDevelop parses the result of `clang_getTypeSpelling()` when libclang API is 
lacking. Since this recent commit 

 KDevelop's parsing relies on the empirical fact that only operators are 
surrounded by spaces to distinguish them from angle brackets. Does this 
revision introduce angle brackets surrounded by spaces? Can tab characters be 
used instead? If not, do you know how else such angle brackets can be 
distinguished from operators?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143755

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


[PATCH] D143692: [clang][driver] Emit error when enabling emulated tls on unsupported architectures

2023-02-10 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth updated this revision to Diff 496529.
paulkirth added a comment.

Rebase on parent revision


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143692

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/emulated-tls.cpp


Index: clang/test/Driver/emulated-tls.cpp
===
--- clang/test/Driver/emulated-tls.cpp
+++ clang/test/Driver/emulated-tls.cpp
@@ -29,6 +29,10 @@
 // RUN: %clang -### -target i686-pc-openbsd %s -femulated-tls 
-fno-emulated-tls 2>&1 \
 // RUN: | FileCheck -check-prefix=NOEMU %s
 
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV %s
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls 
-femulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV-ERROR %s
 
 // Default without -f[no-]emulated-tls, will be decided by the target triple.
 // DEFAULT-NOT: "-cc1" {{.*}}"-femulated-tls"
@@ -40,3 +44,6 @@
 
 // NOEMU: "-cc1" {{.*}}"-fno-emulated-tls"
 // NOEMU-NOT: "-cc1" {{.*}}"-femulated-tls"
+
+// RISCV-NOT:  unsupported option '-fno-emulated-tls' for target 
'riscv64-unknown-linux-android'
+// RISCV-ERROR:  unsupported option '-femulated-tls' for target 
'riscv64-unknown-linux-android'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6164,8 +6164,19 @@
   Args.AddLastArg(CmdArgs, options::OPT_femit_all_decls);
   Args.AddLastArg(CmdArgs, options::OPT_fheinous_gnu_extensions);
   Args.AddLastArg(CmdArgs, options::OPT_fdigraphs, options::OPT_fno_digraphs);
-  Args.AddLastArg(CmdArgs, options::OPT_femulated_tls,
-  options::OPT_fno_emulated_tls);
+
+  if (Arg *A = Args.getLastArg(options::OPT_femulated_tls,
+   options::OPT_fno_emulated_tls)) {
+// LLVM does not support Emulated TLS for some architectures, like RISCV
+// So issue an error to avoid subtle problems in codegen if the flags are
+// incompatible. see https://github.com/llvm/llvm-project/issues/59500
+if (!Triple.supportsEmulatedTLS() &&
+A->getOption().getID() == options::OPT_femulated_tls)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << A->getAsString(Args) << TripleStr;
+A->render(Args, CmdArgs);
+  }
+
   Args.AddLastArg(CmdArgs, options::OPT_fzero_call_used_regs_EQ);
 
   if (Arg *A = Args.getLastArg(options::OPT_fzero_call_used_regs_EQ)) {


Index: clang/test/Driver/emulated-tls.cpp
===
--- clang/test/Driver/emulated-tls.cpp
+++ clang/test/Driver/emulated-tls.cpp
@@ -29,6 +29,10 @@
 // RUN: %clang -### -target i686-pc-openbsd %s -femulated-tls -fno-emulated-tls 2>&1 \
 // RUN: | FileCheck -check-prefix=NOEMU %s
 
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV %s
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls -femulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV-ERROR %s
 
 // Default without -f[no-]emulated-tls, will be decided by the target triple.
 // DEFAULT-NOT: "-cc1" {{.*}}"-femulated-tls"
@@ -40,3 +44,6 @@
 
 // NOEMU: "-cc1" {{.*}}"-fno-emulated-tls"
 // NOEMU-NOT: "-cc1" {{.*}}"-femulated-tls"
+
+// RISCV-NOT:  unsupported option '-fno-emulated-tls' for target 'riscv64-unknown-linux-android'
+// RISCV-ERROR:  unsupported option '-femulated-tls' for target 'riscv64-unknown-linux-android'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6164,8 +6164,19 @@
   Args.AddLastArg(CmdArgs, options::OPT_femit_all_decls);
   Args.AddLastArg(CmdArgs, options::OPT_fheinous_gnu_extensions);
   Args.AddLastArg(CmdArgs, options::OPT_fdigraphs, options::OPT_fno_digraphs);
-  Args.AddLastArg(CmdArgs, options::OPT_femulated_tls,
-  options::OPT_fno_emulated_tls);
+
+  if (Arg *A = Args.getLastArg(options::OPT_femulated_tls,
+   options::OPT_fno_emulated_tls)) {
+// LLVM does not support Emulated TLS for some architectures, like RISCV
+// So issue an error to avoid subtle problems in codegen if the flags are
+// incompatible. see https://github.com/llvm/llvm-project/issues/59500
+if (!Triple.supportsEmulatedTLS() &&
+A->getOption().getID() == options::OPT_femulated_tls)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << A->getAsString(Args) << TripleStr;
+A->render(Args, CmdArgs);
+  }
+
   Args.AddLastArg(CmdArgs, options::OPT_fzero_call_used_regs_EQ);
 
   if (Arg *A = Args.getLastArg(options::OPT_fzero_call_used_regs_EQ)) {
___

[PATCH] D143587: [Docs] Multilib design

2023-02-10 Thread Michael Platings via Phabricator via cfe-commits
michaelplatings updated this revision to Diff 496533.
michaelplatings added a comment.

Tweak multilib.yaml spec slightly


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143587

Files:
  clang/docs/Multilib.rst
  clang/docs/index.rst

Index: clang/docs/index.rst
===
--- clang/docs/index.rst
+++ clang/docs/index.rst
@@ -100,6 +100,7 @@
CodeOwners
InternalsManual
DriverInternals
+   Multilib
OffloadingDesign
PCHInternals
ItaniumMangleAbiTags
Index: clang/docs/Multilib.rst
===
--- /dev/null
+++ clang/docs/Multilib.rst
@@ -0,0 +1,321 @@
+
+Multilib
+
+
+Introduction
+
+
+This document describes how multilib is implemented in Clang.
+
+What is multilib and why might you care?
+If you're :doc:`cross compiling` then you can't use native
+system headers and libraries. To address this, you can use a combination of
+``--sysroot``, ``-isystem`` and ``-L`` options to point clang at suitable
+directories for your target.
+However, when there are many possible directories to choose from, it's not
+necessarily obvious which one to pick.
+Multilib allows a toolchain designer to imbue the toolchain with the ability to
+pick a suitable directory automatically, based on the options the user provides
+to clang. For example, if the user specifies
+``--target=arm-none-eabi -mcpu=cortex-m4`` the toolchain can choose a directory
+containing headers and libraries suitable for Armv7E-M, because it knows that's
+a suitable architecture for Arm Cortex-M4.
+Multilib can also choose between libraries for the same architecture based on
+other options. For example if the user specifies ``-fno-exceptions`` then a
+toolchain could select libraries built without exception support, thereby
+reducing the size of the resulting binary.
+
+Design
+==
+
+Clang supports GCC's ``-print-multi-lib`` and ``-print-multi-directory``
+options. These are described in
+`GCC Developer Options `_.
+
+There are two ways to configure multilib in Clang: hard-coded or via a
+configuration file.
+
+Hard-coded Multilib
+===
+
+The available libraries can be hard-coded in clang. Typically this is done
+using the ``MultilibBuilder`` interface. There are many examples of this in
+``Gnu.cpp``.
+The remainder of this document will not focus on this type of multilib.
+
+Multilib via configuration file
+===
+
+Some clang toolchains support loading multilib configuration from a
+``multilib.yaml`` configuration file.
+
+A ``multilib.yaml`` configuration file specifies which multilib variants are
+available, their relative location, what compilation options were used to build
+them, and the criteria by which they are selected.
+
+Multilib processing
+===
+
+Clang goes through the following steps to use multilib from a configuration
+file:
+#. Convert command line arguments to flags. Clang can accept the same
+   information via different arguments - for example,
+   ``--target=arm-none-eabi -march=armv7-m`` and
+   ``--target=armv7m-none-eabi`` are equivalent. Clang can also accept many
+   independent pieces of information within a single flag - for example
+   ``-march=armv8.1m.main+fp+mve`` specifies the architecture and two
+   extensions in a single command line argument.
+   To make it easier for the multilib system, clang converts the command line
+   arguments into a standard set of simpler "flags". In many cases these flags
+   will look like a command line argument with the leading ``-`` stripped off,
+   but where a suitable form for the flag doesn't exist in command line
+   arguments then its form will be different. For example, an Arm architecture
+   extension is represented like ``march=+mve`` since there's no way to specify
+   it in isolation in a command line argument.
+   To see what flags are emitted for a given set of command line arguments, use
+   the ``-print-multi-selection-flags-experimental`` command line argument
+   along with the rest of the arguments you want to use.
+#. Load ``multilib.yaml`` from sysroot.
+#. Generate additional flags. ``multilib.yaml`` contains a ``flagMap`` section,
+   which specifies how to generate additional flags based on the flags derived
+   from command line arguments. Flags are matched using regular expressions.
+   These regular expressions shall use the POSIX extended regular expression
+   syntax.
+#. Match flags against multilib variants. If the generated flags are a superset
+   of the flags specified for a multilib variant then the variant is considered
+   a match.
+   If more than one variant matches then a toolchain may opt to either use only
+   the *last* matching multilib variant, or may use all matching vari

[PATCH] D142932: [NFC] Multilib YAML parsing

2023-02-10 Thread Michael Platings via Phabricator via cfe-commits
michaelplatings updated this revision to Diff 496534.
michaelplatings added a comment.

Make "variants" required


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142932

Files:
  clang/include/clang/Driver/Multilib.h
  clang/lib/Driver/Multilib.cpp
  clang/unittests/Driver/MultilibTest.cpp

Index: clang/unittests/Driver/MultilibTest.cpp
===
--- clang/unittests/Driver/MultilibTest.cpp
+++ clang/unittests/Driver/MultilibTest.cpp
@@ -187,3 +187,347 @@
   EXPECT_EQ("/a", Selection[0].gccSuffix());
   EXPECT_EQ("/b", Selection[1].gccSuffix());
 }
+
+static void diagnosticCallback(const llvm::SMDiagnostic &D, void *Out) {
+  *reinterpret_cast(Out) = D.getMessage();
+}
+
+static bool parse(MultilibSet &MS, std::string &Diagnostic, const char *Data) {
+  return MS.parse(llvm::MemoryBufferRef(Data, "TEST"), diagnosticCallback,
+  &Diagnostic);
+}
+
+static bool parse(MultilibSet &MS, const char *Data) {
+  return MS.parse(llvm::MemoryBufferRef(Data, "TEST"));
+}
+
+TEST(MultilibTest, ParseInvalid) {
+  std::string Diagnostic;
+
+  MultilibSet MS;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, "{}"));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'variants'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants:
+- dir: /abc
+  flags: []
+  printArgs: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("paths must be relative"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants:
+- flags: []
+  printArgs: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'dir'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants:
+- dir: .
+  printArgs: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'flags'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants:
+- dir: .
+  flags: []
+)"));
+  EXPECT_TRUE(
+  StringRef(Diagnostic).contains("missing required key 'printArgs'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants: []
+flagMap:
+- regex: abc
+)"));
+  EXPECT_TRUE(
+  StringRef(Diagnostic)
+  .contains("value required for 'matchFlags' or 'noMatchFlags'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants: []
+flagMap:
+- dir: .
+  regex: '('
+  printArgs: []
+
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("parentheses not balanced"))
+  << Diagnostic;
+}
+
+TEST(MultilibTest, Parse) {
+  MultilibSet MS;
+  EXPECT_TRUE(parse(MS, R"(
+variants:
+- dir: .
+  flags: []
+  printArgs: []
+)"));
+  EXPECT_EQ(1U, MS.size());
+  EXPECT_EQ("", MS.begin()->gccSuffix());
+
+  EXPECT_TRUE(parse(MS, R"(
+variants:
+- dir: abc
+  flags: []
+  printArgs: []
+)"));
+  EXPECT_EQ(1U, MS.size());
+  EXPECT_EQ("/abc", MS.begin()->gccSuffix());
+
+  EXPECT_TRUE(parse(MS, R"(
+variants:
+- dir: pqr
+  flags: []
+  printArgs: [-mfloat-abi=soft]
+)"));
+  EXPECT_EQ(1U, MS.size());
+  EXPECT_EQ("/pqr", MS.begin()->gccSuffix());
+  EXPECT_EQ(std::vector({"-mfloat-abi=soft"}),
+MS.begin()->getPrintArgs());
+
+  EXPECT_TRUE(parse(MS, R"(
+variants:
+- dir: pqr
+  flags: []
+  printArgs: [-mfloat-abi=soft, -fno-exceptions]
+)"));
+  EXPECT_EQ(1U, MS.size());
+  EXPECT_EQ(std::vector({"-mfloat-abi=soft", "-fno-exceptions"}),
+MS.begin()->getPrintArgs());
+
+  EXPECT_TRUE(parse(MS, R"(
+variants:
+- dir: a
+  flags: []
+  printArgs: []
+- dir: b
+  flags: []
+  printArgs: []
+)"));
+  EXPECT_EQ(2U, MS.size());
+}
+
+TEST(MultilibTest, SelectSoft) {
+  MultilibSet MS;
+  Multilib Selected;
+  ASSERT_TRUE(parse(MS, R"(
+variants:
+- dir: s
+  flags: [softabi]
+  printArgs: []
+flagMap:
+- regex: mfloat-abi=soft
+  matchFlags: [softabi]
+- regex: mfloat-abi=softfp
+  matchFlags: [softabi]
+)"));
+  EXPECT_TRUE(MS.select({"mfloat-abi=soft"}, Selected));
+  EXPECT_TRUE(MS.select({"mfloat-abi=softfp"}, Selected));
+  EXPECT_FALSE(MS.select({"mfloat-abi=hard"}, Selected));
+}
+
+TEST(MultilibTest, SelectSoftFP) {
+  MultilibSet MS;
+  Multilib Selected;
+  ASSERT_TRUE(parse(MS, R"(
+variants:
+- dir: f
+  flags: [mfloat-abi=softfp]
+  printArgs: []
+)"));
+  EXPECT_FALSE(MS.select({"mfloat-abi=soft"}, Selected));
+  EXPECT_TRUE(MS.select({"mfloat-abi=softfp"}, Selected));
+  EXPECT_FALSE(MS.select({"mfloat-abi=hard"}, Selected));
+}
+
+TEST(MultilibTest, SelectHard) {
+  // If hard float is all that's available then select that only if compiling
+  // with hard float.
+  MultilibSet MS;
+  Multilib Selected;
+  ASSERT_TRUE(parse(MS, R"(
+variants:
+- dir: h
+  flags: [mfloat-abi=hard]
+  printArgs: []
+)"));
+  EXPECT_FALSE(MS.select({"mfloat-abi=soft"}, Selected));
+  EXPECT_FALSE(MS.select({"mfloat-abi=softfp"}, Selected));
+  EXPECT_TRUE(MS.select({"mfloat-abi=hard"}, Selected));
+}
+
+TEST(MultilibTest, SelectFloatABI)

[PATCH] D143763: [Clang] Add clangMinimumVersion to multilib.yaml

2023-02-10 Thread Michael Platings via Phabricator via cfe-commits
michaelplatings created this revision.
michaelplatings added a reviewer: peter.smith.
Herald added a subscriber: dmgreen.
Herald added a project: All.
michaelplatings requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

This avoids a potential source of subtle errors if an older version of
Clang were to be used with a multilib.yaml that requires a newer Clang
to work correctly.

This feature is comparable to CMake's cmake_minimum_required.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143763

Files:
  clang/lib/Driver/Multilib.cpp
  clang/unittests/Driver/MultilibTest.cpp

Index: clang/unittests/Driver/MultilibTest.cpp
===
--- clang/unittests/Driver/MultilibTest.cpp
+++ clang/unittests/Driver/MultilibTest.cpp
@@ -13,6 +13,7 @@
 #include "clang/Driver/Multilib.h"
 #include "../../lib/Driver/ToolChains/CommonArgs.h"
 #include "clang/Basic/LLVM.h"
+#include "clang/Basic/Version.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSwitch.h"
@@ -197,20 +198,80 @@
   &Diagnostic);
 }
 
+static bool parse(MultilibSet &MS, std::string &Diagnostic,
+  const std::string &Data) {
+  return MS.parse(llvm::MemoryBufferRef(Data, "TEST"), diagnosticCallback,
+  &Diagnostic);
+}
+
 static bool parse(MultilibSet &MS, const char *Data) {
   return MS.parse(llvm::MemoryBufferRef(Data, "TEST"));
 }
 
+#define _STRINGIFY(x) #x
+#define STRINGIFY(x) _STRINGIFY(x)
+// Avoid using MULTILIB_CLANG_VERSION in case it has extra non-numeric parts.
+#define MULTILIB_CLANG_VERSION \
+  STRINGIFY(CLANG_VERSION_MAJOR)   \
+  "." STRINGIFY(CLANG_VERSION_MINOR) "." STRINGIFY(CLANG_VERSION_PATCHLEVEL)
+#define YAML_PREAMBLE "clangMinimumVersion: " MULTILIB_CLANG_VERSION "\n"
+
 TEST(MultilibTest, ParseInvalid) {
   std::string Diagnostic;
 
   MultilibSet MS;
 
-  EXPECT_FALSE(parse(MS, Diagnostic, "{}"));
-  EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'variants'"))
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic)
+  .contains("missing required key 'clangMinimumVersion'"))
   << Diagnostic;
 
+  // Require all 3 major.minor.patch version components
   EXPECT_FALSE(parse(MS, Diagnostic, R"(
+clangMinimumVersion: )" STRINGIFY(CLANG_VERSION_MAJOR) R"(.0
+variants: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic)
+  .contains("not a valid version string \"" STRINGIFY(
+  CLANG_VERSION_MAJOR) ".0\""))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+clangMinimumVersion: )" MULTILIB_CLANG_VERSION R"(a
+variants: []
+)"));
+  EXPECT_TRUE(
+  StringRef(Diagnostic)
+  .contains("not a valid version string \"" MULTILIB_CLANG_VERSION
+"a\""))
+  << Diagnostic;
+
+  // Reject configurations that require a later clang version
+  EXPECT_FALSE(parse(MS, Diagnostic,
+ R"(
+clangMinimumVersion: )" + std::to_string(CLANG_VERSION_MAJOR + 1) +
+ R"(.0.0
+variants: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic)
+  .contains("clang version " MULTILIB_CLANG_VERSION
+" is less than clangMinimumVersion: " +
+std::to_string(CLANG_VERSION_MAJOR + 1) + ".0.0"))
+  << Diagnostic;
+
+  // but accept configurations that only need an earlier clang version
+  EXPECT_TRUE(parse(MS, Diagnostic, R"(
+clangMinimumVersion: 16.0.0
+variants: []
+)")) << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, YAML_PREAMBLE));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'variants'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, YAML_PREAMBLE R"(
 variants:
 - dir: /abc
   flags: []
@@ -219,7 +280,7 @@
   EXPECT_TRUE(StringRef(Diagnostic).contains("paths must be relative"))
   << Diagnostic;
 
-  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+  EXPECT_FALSE(parse(MS, Diagnostic, YAML_PREAMBLE R"(
 variants:
 - flags: []
   printArgs: []
@@ -227,7 +288,7 @@
   EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'dir'"))
   << Diagnostic;
 
-  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+  EXPECT_FALSE(parse(MS, Diagnostic, YAML_PREAMBLE R"(
 variants:
 - dir: .
   printArgs: []
@@ -235,7 +296,7 @@
   EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'flags'"))
   << Diagnostic;
 
-  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+  EXPECT_FALSE(parse(MS, Diagnostic, YAML_PREAMBLE R"(
 variants:
 - dir: .
   flags: []
@@ -244,7 +305,7 @@
   StringRef(Diagnostic).contains("missing required key 'printArgs'"))
   << Diagnostic;
 
-  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+  EXPECT_FALSE(parse(MS, Diagnostic,

[PATCH] D143418: [libclang] Add API to set preferred temp dir path

2023-02-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D143418#4117246 , @vedgy wrote:

> In D143418#4116290 , @aaron.ballman 
> wrote:
>
>>> So how about a more sincere general solution: setPreferredTempDirPath()? 
>>> The documentation would say that libclang tries its best to place temporary 
>>> files into the specified directory, but some might end up in the system 
>>> temporary directory instead.
>>
>> I don't think those semantics are reasonable. "Tries its best" is fine for 
>> things that are heuristic based, like deciding when to do an analysis cut 
>> point, but is too non-deterministic for something like "where do files get 
>> placed". I think it's reasonable that we either:
>>
>> 1. expose an option to say "I prefer preambles to be put in this directory" 
>> for libclang, or
>> 2. expose an option to say "I prefer using this directory over the temp 
>> directory for all files" for libclang,
>>
>> I thought we agreed that #2 is too high of risk because it requires auditing 
>> libclang for all the places it decides to put something into the temp 
>> directory, and so we were going with #1 and doing it as part of the cindex 
>> constructor so that users cannot run into the surprise issues 
>> (multithreading, files changing location mid-run) with an independent setter.
>
> This revision implements #2, but warns about possible imperfections of the 
> implementation.

I don't think "tries hard" is a good enough guarantee for where files are 
placed. I'm not comfortable with the security posture of that approach as it 
could potentially leak sensitive information (try to override the temp 
directory to something that's chroot jailed, get sensitive files showing up in 
the system temp directory anyway).

> In D139774#4066519 , @dblaikie 
> wrote:
>
>> In D139774#4065753 , 
>> @aaron.ballman wrote:
>>
>>> From a design perspective, my preference is to not add new APIs at the file 
>>> system support layer in LLVM to override the temporary directory but 
>>> instead allow individual components to override the decision where to put 
>>> files. Overriding a system directory at the LLVM support level feels 
>>> unclean to me because 1) threading concerns (mostly related to lock 
>>> performance), 2) consistency concerns (put files in temp directory, 
>>> override temp directory, put additional files in the new directory), 3) 
>>> principle of least surprise. To me, the LLVM layer is responsible for 
>>> interfacing with the system and asking for the system temp directory should 
>>> get you the same answer as querying for that from the OS directly.
>>
>> I've mixed feelings about this, but yeah, I guess the issues with global 
>> state are pretty undesirable. I don't worry too much about (2) - doesn't 
>> feel too problematic to me (for any individual file, presumably the 
>> implementation recorded the name of the file if they were going to access it 
>> again - so still be using the old path if necessary).
>>
>> But, yeah, lack of any "system" abstraction that could be passed into all 
>> the various LLVM/MC/AST contexts to swap out the implementation limits the 
>> options a bit to more ad-hoc/case-by-case solutions. I feel like that's not 
>> a great solution to KDevelop's general problem, though - they're dealing 
>> with one particularly big file, but it doesn't feel very principled to me to 
>> fix that one compared to all the other (albeit smaller) temp files & maybe 
>> at some point in the future some bigger temp files are created elsewhere...
>
> Based on this comment and on current preamble storage path code, I thought 
> files-changing-location-mid-run should not be a problem.
>
> Does the multithreading issue mean that `clang_parseTranslationUnit_Impl()` 
> can be called in a non-main thread and thus concurrently with 
> `clang_CXIndex_setPreferredTempDirPath()`?

Yes. However, I don't think that situation is officially supported (it's more 
that we don't want to knowingly make it harder to support in the future).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143418

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


[PATCH] D142986: Enable multilib.yaml in the BareMetal ToolChain

2023-02-10 Thread Michael Platings via Phabricator via cfe-commits
michaelplatings updated this revision to Diff 496537.
michaelplatings added a comment.

Add clangMinimumVersion


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142986

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.h
  clang/lib/Driver/ToolChains/BareMetal.cpp
  clang/test/Driver/Inputs/baremetal_multilib/multilib.yaml
  clang/test/Driver/baremetal-multilib.cpp
  clang/test/Driver/baremetal.cpp

Index: clang/test/Driver/baremetal.cpp
===
--- clang/test/Driver/baremetal.cpp
+++ clang/test/Driver/baremetal.cpp
@@ -118,9 +118,9 @@
 // Verify that the bare metal driver does not include any host system paths:
 // CHECK-AARCH64-NO-HOST-INC: InstalledDir: [[INSTALLEDDIR:.+]]
 // CHECK-AARCH64-NO-HOST-INC: "-resource-dir" "[[RESOURCE:[^"]+]]"
-// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}aarch64-none-elf{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
+// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+[^"]*}}include{{[/\\]+}}c++{{[/\\]+}}v1"
 // CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[RESOURCE]]{{[/\\]+}}include"
-// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}aarch64-none-elf{{[/\\]+}}include"
+// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+[^"]*}}include"
 
 // RUN: %clang %s -### --target=riscv64-unknown-elf -o %t.out -L some/directory/user/asked/for \
 // RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf 2>&1 \
Index: clang/test/Driver/baremetal-multilib.cpp
===
--- /dev/null
+++ clang/test/Driver/baremetal-multilib.cpp
@@ -0,0 +1,45 @@
+// REQUIRES: shell
+// UNSUPPORTED: system-windows
+
+// RUN: rm -rf %T/baremetal_multilib
+// RUN: mkdir -p %T/baremetal_multilib/bin
+// RUN: mkdir -p %T/baremetal_multilib/lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/lib
+// RUN: touch %T/baremetal_multilib/lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/lib/libclang_rt.builtins.a
+// RUN: ln -s %clang %T/baremetal_multilib/bin/clang
+// RUN: ln -s %S/Inputs/baremetal_multilib/multilib.yaml %T/baremetal_multilib/lib/clang-runtimes/multilib.yaml
+
+// RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=thumbv8m.main-none-eabihf --sysroot= \
+// RUN:   | FileCheck %s
+// CHECK: "{{.*}}clang{{.*}}" "-cc1" "-triple" "thumbv8m.main-none-unknown-eabihf"
+// CHECK-SAME: "-internal-isystem" "{{.*}}/baremetal_multilib/bin/../lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/include/c++/v1"
+// CHECK-SAME: "-internal-isystem" "{{.*}}/baremetal_multilib/bin/../lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/include"
+// CHECK-SAME: "-x" "c++" "{{.*}}/baremetal-multilib.cpp"
+// CHECK-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
+// CHECK-SAME: "-L{{.*}}/baremetal_multilib/bin/../lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/lib"
+// CHECK-SAME: "-lc" "-lm" "-lclang_rt.builtins"
+// CHECK-SAME: "-o" "{{.*}}.o"
+
+// RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes -print-multi-directory 2>&1 \
+// RUN: --target=thumbv8m.main-none-eabihf --sysroot= \
+// RUN:   | FileCheck --check-prefix=CHECK-PRINT-MULTI-DIRECTORY %s
+// CHECK-PRINT-MULTI-DIRECTORY: arm-none-eabi/thumb/v8-m.main/fp
+
+// RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes -print-multi-lib 2>&1 \
+// RUN: --target=arm-none-eabi --sysroot= \
+// RUN:   | FileCheck --check-prefix=CHECK-PRINT-MULTI-LIB %s
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v6-m/nofp;@-target=thumbv6m-none-eabi@mfloat-abi=soft
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v7-m/nofp;@-target=thumbv7m-none-eabi@mfloat-abi=soft
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v7e-m/nofp;@-target=thumbv7em-none-eabi@mfloat-abi=soft@mfpu=none
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v8-m.main/nofp;@-target=arm-none-eabi@mfloat-abi=soft@march=armv8m.main+nofp
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v8.1-m.main/nofp/nomve;@-target=arm-none-eabi@mfloat-abi=soft@march=armv8.1m.main+nofp+nomve
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v7e-m/fpv4_sp_d16;@-target=thumbv7em-none-eabihf@mfpu=fpv4-sp-d16
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v7e-m/fpv5_d16;@-target=thumbv7em-none-eabihf@mfpu=fpv5-d16
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v8-m.main/fp;@-target=thumbv8m.main-none-eabihf
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v8.1-m.main/fp;@-target=thumbv8.1m.main-none-eabihf
+// CHECK-PRINT-MULTI-LIB:

[PATCH] D143059: [NFC] Enable selecting multiple multilibs

2023-02-10 Thread Michael Platings via Phabricator via cfe-commits
michaelplatings updated this revision to Diff 496538.
michaelplatings added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143059

Files:
  clang/include/clang/Driver/Multilib.h
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/Multilib.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/BareMetal.cpp
  clang/lib/Driver/ToolChains/CSKYToolChain.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Gnu.h
  clang/lib/Driver/ToolChains/Hexagon.cpp
  clang/lib/Driver/ToolChains/Hurd.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/lib/Driver/ToolChains/MipsLinux.cpp
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  clang/test/Driver/fuchsia.cpp
  clang/unittests/Driver/MultilibBuilderTest.cpp
  clang/unittests/Driver/MultilibTest.cpp

Index: clang/unittests/Driver/MultilibTest.cpp
===
--- clang/unittests/Driver/MultilibTest.cpp
+++ clang/unittests/Driver/MultilibTest.cpp
@@ -154,18 +154,18 @@
   Multilib("/bar", {}, {}, {"+bar"}),
   });
   Multilib::flag_set Flags1 = {"+foo", "-bar"};
-  Multilib Selection1;
+  llvm::SmallVector Selection1;
   ASSERT_TRUE(MS.select(Flags1, Selection1))
   << "Flag set was {\"+foo\"}, but selection not found";
-  ASSERT_TRUE(Selection1.gccSuffix() == "/foo")
-  << "Selection picked " << Selection1 << " which was not expected";
+  ASSERT_TRUE(Selection1.back().gccSuffix() == "/foo")
+  << "Selection picked " << Selection1.back() << " which was not expected";
 
   Multilib::flag_set Flags2 = {"+foo", "+bar"};
-  Multilib Selection2;
+  llvm::SmallVector Selection2;
   ASSERT_TRUE(MS.select(Flags2, Selection2))
   << "Flag set was {\"+bar\"}, but selection not found";
-  ASSERT_TRUE(Selection2.gccSuffix() == "/bar")
-  << "Selection picked " << Selection2 << " which was not expected";
+  ASSERT_TRUE(Selection2.back().gccSuffix() == "/bar")
+  << "Selection picked " << Selection2.back() << " which was not expected";
 }
 
 TEST(MultilibTest, SelectMultiple) {
@@ -173,17 +173,17 @@
   Multilib("/a", {}, {}, {"x"}),
   Multilib("/b", {}, {}, {"y"}),
   });
-  std::vector Selection;
+  llvm::SmallVector Selection;
 
-  Selection = MS.select({"x"});
+  ASSERT_TRUE(MS.select({"x"}, Selection));
   ASSERT_EQ(1u, Selection.size());
   EXPECT_EQ("/a", Selection[0].gccSuffix());
 
-  Selection = MS.select({"y"});
+  ASSERT_TRUE(MS.select({"y"}, Selection));
   ASSERT_EQ(1u, Selection.size());
   EXPECT_EQ("/b", Selection[0].gccSuffix());
 
-  Selection = MS.select({"y", "x"});
+  ASSERT_TRUE(MS.select({"y", "x"}, Selection));
   ASSERT_EQ(2u, Selection.size());
   EXPECT_EQ("/a", Selection[0].gccSuffix());
   EXPECT_EQ("/b", Selection[1].gccSuffix());
@@ -382,7 +382,7 @@
 
 TEST(MultilibTest, SelectSoft) {
   MultilibSet MS;
-  Multilib Selected;
+  llvm::SmallVector Selected;
   ASSERT_TRUE(parse(MS, YAML_PREAMBLE R"(
 variants:
 - dir: s
@@ -401,7 +401,7 @@
 
 TEST(MultilibTest, SelectSoftFP) {
   MultilibSet MS;
-  Multilib Selected;
+  llvm::SmallVector Selected;
   ASSERT_TRUE(parse(MS, YAML_PREAMBLE R"(
 variants:
 - dir: f
@@ -417,7 +417,7 @@
   // If hard float is all that's available then select that only if compiling
   // with hard float.
   MultilibSet MS;
-  Multilib Selected;
+  llvm::SmallVector Selected;
   ASSERT_TRUE(parse(MS, YAML_PREAMBLE R"(
 variants:
 - dir: h
@@ -431,7 +431,7 @@
 
 TEST(MultilibTest, SelectFloatABI) {
   MultilibSet MS;
-  Multilib Selected;
+  llvm::SmallVector Selected;
   ASSERT_TRUE(parse(MS, YAML_PREAMBLE R"(
 variants:
 - dir: s
@@ -452,18 +452,18 @@
   noMatchFlags: [hasfp]
 )"));
   MS.select({"mfloat-abi=soft"}, Selected);
-  EXPECT_EQ("/s", Selected.gccSuffix());
+  EXPECT_EQ("/s", Selected.back().gccSuffix());
   MS.select({"mfloat-abi=softfp"}, Selected);
-  EXPECT_EQ("/f", Selected.gccSuffix());
+  EXPECT_EQ("/f", Selected.back().gccSuffix());
   MS.select({"mfloat-abi=hard"}, Selected);
-  EXPECT_EQ("/h", Selected.gccSuffix());
+  EXPECT_EQ("/h", Selected.back().gccSuffix());
 }
 
 TEST(MultilibTest, SelectFloatABIReversed) {
   // If soft is specified after softfp then softfp will never be
   // selected because soft is compatible with softfp and last wins.
   MultilibSet MS;
-  Multilib Selected;
+  llvm::SmallVector Selected;
   ASSERT_TRUE(parse(MS, YAML_PREAMBLE R"(
 variants:
 - dir: h
@@ -484,11 +484,11 @@
   noMatchFlags: [hasfp]
 )"));
   MS.select({"mfloat-abi=soft"}, Selected);
-  EXPECT_EQ("/s", Selected.gccSuffix());
+  EXPECT_EQ("/s", Selected.back().gccSuffix());
   MS.select({"mfloat-abi=softfp"}, Selected);
-  EXPECT_EQ("/s", Selected.gccSuffix());
+  EXPECT_EQ("/s", Selected.back().gccSuffix());
   MS.select({"mfloat-abi=hard"}, Selected);
-  EXPECT_EQ("/h", Selected.gccSuffix());
+  EXPECT_EQ("/h", 

[clang-tools-extra] e7e577f - [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

2023-02-10 Thread Yitzhak Mandelbaum via cfe-commits

Author: Yitzhak Mandelbaum
Date: 2023-02-10T18:15:21Z
New Revision: e7e577f6842135faaf2c960c7a4e69c71836dc0a

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

LOG: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

Removes a reference to google-internal document and expands the relevant 
material in place.

Fixes: #60633.

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

Added: 


Modified: 

clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst

Removed: 




diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
 
b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
index 256cb6d05e254..ddb43a3dac98b 100644
--- 
a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ 
b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@ results. Therefore, it may be more resource intensive (RAM, 
CPU) than the
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as 
``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle 
diff erences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as 
equivalent,
+even though there are subtle 
diff erences related to exceptions versus undefined
+behavior. See *Additional notes*, below, for more information on this topic.
 
 An access to the value of an ``optional`` is considered safe if and only if
 code in the local scope (for example, a function body) ensures that the
@@ -273,3 +271,27 @@ The check does not currently report unsafe optional 
accesses in lambdas.
 A future version will expand the scope to lambdas, following the rules
 outlined above. It is best to follow the same principles when using
 optionals in lambdas.
+
+Access with ``operator*()`` vs. ``value()``
+---
+
+Given that ``value()`` has well-defined behavior (either throwing an exception
+or terminating the program), why treat it the same as ``operator*()`` which
+causes undefined behavior (UB)? That is, why is it considered unsafe to access
+an optional with ``value()``, if it's not provably populated with a value?  For
+that matter, why is ``CHECK()`` followed by ``operator*()`` any better than
+``value()``, given that they are semantically equivalent (on configurations 
that
+disable exceptions)?
+
+The answer is that we assume most users do not realize the 
diff erence between
+``value()`` and ``operator*()``. Shifting to ``operator*()`` and some form of
+explicit value-presence check or explicit program termination has two
+advantages:
+
+  * Readability. The check, and any potential side effects like program
+shutdown, are very clear in the code. Separating access from checks can
+actually make the checks more obvious.
+
+  * Performance. A single check can cover many or even all accesses within
+scope. This gives the user the best of both worlds -- the safety of a
+dynamic check, but without incurring redundant costs.



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


[PATCH] D143750: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

2023-02-10 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
ymandel marked an inline comment as done.
Closed by commit rGe7e577f68421: [clang-tidy] Clarify documention of 
`bugprone-unchecked-optional-access`. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143750

Files:
  
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst


Index: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as 
``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as 
equivalent,
+even though there are subtle differences related to exceptions versus undefined
+behavior. See *Additional notes*, below, for more information on this topic.
 
 An access to the value of an ``optional`` is considered safe if and only if
 code in the local scope (for example, a function body) ensures that the
@@ -273,3 +271,27 @@
 A future version will expand the scope to lambdas, following the rules
 outlined above. It is best to follow the same principles when using
 optionals in lambdas.
+
+Access with ``operator*()`` vs. ``value()``
+---
+
+Given that ``value()`` has well-defined behavior (either throwing an exception
+or terminating the program), why treat it the same as ``operator*()`` which
+causes undefined behavior (UB)? That is, why is it considered unsafe to access
+an optional with ``value()``, if it's not provably populated with a value?  For
+that matter, why is ``CHECK()`` followed by ``operator*()`` any better than
+``value()``, given that they are semantically equivalent (on configurations 
that
+disable exceptions)?
+
+The answer is that we assume most users do not realize the difference between
+``value()`` and ``operator*()``. Shifting to ``operator*()`` and some form of
+explicit value-presence check or explicit program termination has two
+advantages:
+
+  * Readability. The check, and any potential side effects like program
+shutdown, are very clear in the code. Separating access from checks can
+actually make the checks more obvious.
+
+  * Performance. A single check can cover many or even all accesses within
+scope. This gives the user the best of both worlds -- the safety of a
+dynamic check, but without incurring redundant costs.


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as ``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as eq

[PATCH] D143692: [clang][driver] Emit error when enabling emulated tls on unsupported architectures

2023-02-10 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay accepted this revision.
MaskRay added a comment.

With nits




Comment at: clang/test/Driver/emulated-tls.cpp:49
+// RISCV-NOT:  unsupported option '-fno-emulated-tls' for target 
'riscv64-unknown-linux-android'
+// RISCV-ERROR:  unsupported option '-femulated-tls' for target 
'riscv64-unknown-linux-android'

Prepend `error:`

For the `NOT` pattern, use `RISCV-NOT: error:` or change FileCheck to 
`FileCheck --implicit-check-not=error:`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143692

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


[PATCH] D143768: [Clang] Add options to disable direct linking of arch tools

2023-02-10 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 created this revision.
jhuber6 added reviewers: aaronmondal, JonChesterfield, tra, jdoerfert, 
tianshilei1992.
Herald added subscribers: kosarev, mattd, asavonic, kerbowa, tpr, jvesely.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

We use the `nvptx-arch` and `amdgpu-arch` tools to identify the system's
installed GPUs. These are used across LLVM to handle setting up unit
tests and the `--offload-arch=native` option. This patch adds the
`CLANG_FORCE_DLOPEN_LIBCUDA` and `CLANG_FORCE_DLOPEN_LIBHSA` CMake
options to enable disabling these directly.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143768

Files:
  clang/tools/amdgpu-arch/CMakeLists.txt
  clang/tools/nvptx-arch/CMakeLists.txt


Index: clang/tools/nvptx-arch/CMakeLists.txt
===
--- clang/tools/nvptx-arch/CMakeLists.txt
+++ clang/tools/nvptx-arch/CMakeLists.txt
@@ -9,10 +9,12 @@
 set(LLVM_LINK_COMPONENTS Support)
 add_clang_tool(nvptx-arch NVPTXArch.cpp)
 
-find_package(CUDAToolkit QUIET)
+option(CLANG_FORCE_DLOPEN_LIBCUDA "Build with 'dlopened' libcuda" OFF)
 
 # If we found the CUDA library directly we just dynamically link against it.
-if(CUDAToolkit_FOUND AND NOT (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 
4))
+find_package(CUDAToolkit QUIET)
+if(CUDAToolkit_FOUND AND NOT
+   (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4 OR 
CLANG_FORCE_DLOPEN_LIBCUDA))
   target_link_libraries(nvptx-arch PRIVATE CUDA::cuda_driver)
 else()
   target_compile_definitions(nvptx-arch PRIVATE "DYNAMIC_CUDA")
Index: clang/tools/amdgpu-arch/CMakeLists.txt
===
--- clang/tools/amdgpu-arch/CMakeLists.txt
+++ clang/tools/amdgpu-arch/CMakeLists.txt
@@ -10,9 +10,12 @@
 
 add_clang_tool(amdgpu-arch AMDGPUArch.cpp)
 
+option(CLANG_FORCE_DLOPEN_LIBHSA "Build with 'dlopened' libhsa" OFF)
+
 # If we find the HSA runtime we link with it directly.
 find_package(hsa-runtime64 QUIET 1.2.0 HINTS ${CMAKE_INSTALL_PREFIX} PATHS 
/opt/rocm)
-if(hsa-runtime64_FOUND AND NOT (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P 
EQUAL 4))
+if(hsa-runtime64_FOUND AND NOT
+   (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4 OR 
CLANG_FORCE_DLOPEN_LIBHSA))
   set_target_properties(amdgpu-arch PROPERTIES INSTALL_RPATH_USE_LINK_PATH ON)
   target_link_libraries(amdgpu-arch PRIVATE hsa-runtime64::hsa-runtime64)
 else()


Index: clang/tools/nvptx-arch/CMakeLists.txt
===
--- clang/tools/nvptx-arch/CMakeLists.txt
+++ clang/tools/nvptx-arch/CMakeLists.txt
@@ -9,10 +9,12 @@
 set(LLVM_LINK_COMPONENTS Support)
 add_clang_tool(nvptx-arch NVPTXArch.cpp)
 
-find_package(CUDAToolkit QUIET)
+option(CLANG_FORCE_DLOPEN_LIBCUDA "Build with 'dlopened' libcuda" OFF)
 
 # If we found the CUDA library directly we just dynamically link against it.
-if(CUDAToolkit_FOUND AND NOT (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4))
+find_package(CUDAToolkit QUIET)
+if(CUDAToolkit_FOUND AND NOT
+   (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4 OR CLANG_FORCE_DLOPEN_LIBCUDA))
   target_link_libraries(nvptx-arch PRIVATE CUDA::cuda_driver)
 else()
   target_compile_definitions(nvptx-arch PRIVATE "DYNAMIC_CUDA")
Index: clang/tools/amdgpu-arch/CMakeLists.txt
===
--- clang/tools/amdgpu-arch/CMakeLists.txt
+++ clang/tools/amdgpu-arch/CMakeLists.txt
@@ -10,9 +10,12 @@
 
 add_clang_tool(amdgpu-arch AMDGPUArch.cpp)
 
+option(CLANG_FORCE_DLOPEN_LIBHSA "Build with 'dlopened' libhsa" OFF)
+
 # If we find the HSA runtime we link with it directly.
 find_package(hsa-runtime64 QUIET 1.2.0 HINTS ${CMAKE_INSTALL_PREFIX} PATHS /opt/rocm)
-if(hsa-runtime64_FOUND AND NOT (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4))
+if(hsa-runtime64_FOUND AND NOT
+   (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4 OR CLANG_FORCE_DLOPEN_LIBHSA))
   set_target_properties(amdgpu-arch PROPERTIES INSTALL_RPATH_USE_LINK_PATH ON)
   target_link_libraries(amdgpu-arch PRIVATE hsa-runtime64::hsa-runtime64)
 else()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 79a3803 - [ClangScanDeps] Add UNSUPPORTED: system-windows to test P1689.cppm

2023-02-10 Thread Tom Weaver via cfe-commits

Author: Tom Weaver
Date: 2023-02-10T18:29:41Z
New Revision: 79a3803bb2ccdd852436cd1653017a1159a12157

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

LOG: [ClangScanDeps] Add UNSUPPORTED: system-windows to test P1689.cppm

The revert of
  https://reviews.llvm.org/rG65f9719913eca9c7c72d1abf4eddab767abaebf6

removes a system-windows guard but does not remove the test causing windows
system failures. This patch adds back a guard to prevent further failures.

Added: 


Modified: 
clang/test/ClangScanDeps/P1689.cppm

Removed: 




diff  --git a/clang/test/ClangScanDeps/P1689.cppm 
b/clang/test/ClangScanDeps/P1689.cppm
index 22d7721c2e9bf..3329d1efbfa63 100644
--- a/clang/test/ClangScanDeps/P1689.cppm
+++ b/clang/test/ClangScanDeps/P1689.cppm
@@ -1,3 +1,5 @@
+// UNSUPPORTED: system-windows
+
 // RUN: rm -fr %t
 // RUN: mkdir -p %t
 // RUN: split-file %s %t



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


[PATCH] D143745: Make section attribute and -ffunction-sections play nicely

2023-02-10 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

> [...] all functions with that attribute end up in a single section, defeating 
> the linker GC.

This can be made preciser.

Say we have

  __attribute__((section("foo"))) void f(i) {}
  __attribute__((section("foo"))) void g() {}

`f` and `g` don't use COMDAT, therefore they are in the same section `foo` in 
Clang and GCC (coarse-grained). This `foo` section is retained or discarded as 
a unit. Considering the whole link, a `foo` section in a translation unit can 
be discarded.

I suspect that some people may find the new behavior surprising, so an option 
is probably needed. Ideally inform GCC about this new toggle as well.

I think ThinLTO's `comdat nodeduplicate` handling is great. In D108879 
 I noted an interesting issue related to 
regular LTO. I haven't tested more scenarios about regular LTO. If you want to 
use it at scale, consider more testing.


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

https://reviews.llvm.org/D143745

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


[PATCH] D135341: [clang] adds `__reference_constructs_from_temporary`

2023-02-10 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added a comment.

In D135341#4111884 , @cjdb wrote:

> In D135341#4111673 , @ldionne wrote:
>
>> I've been looking at implementing `reference_constructs_from_temporary` & 
>> friends and this would be sweet to have. Is this blocked on something 
>> specific?
>
> This trait should be ready to go, pending an LGTM. 
> `__reference_converts_from_temporary` is a different story, and someone else 
> might need to do this one if you need it in a timely fashion (but I'll be 
> happy to review it).

Sounds good! This naively looks good to me, but it would be nice if a Clang 
regular could take a look!




Comment at: clang/include/clang/Basic/DiagnosticCommonKinds.td:397
+def err_reserved_identifier_for_future_use : Error<
+  "%0 is a compiler-reserved identifier for a future feature">;
 }

cjdb wrote:
> ldionne wrote:
> > cjdb wrote:
> > > erichkeane wrote:
> > > > I don't think we should diagnose this for individual identifiers, I 
> > > > don't think this adds much value, and the identifier is already 
> > > > reserved for implementation use.  This implies we are going to diagnose 
> > > > ALL future reserved things, which we have no intention of doing.
> > > The motivation for this error is to ensure that standard library 
> > > implementations don't take this name (`__remove_cvref` and 
> > > `__is_null_pointer` had to get names that weren't a 1:1 mapping to their 
> > > library counterparts as a result).
> > Oh, just ask and we can rename ours! What do you want us to rename?
> Much appreciated! I think `__remove_cvref` had a libc++ conflict and 
> `__is_null_pointer` had a libstdc++ conflict, so it's not specific to one 
> library. I figured that it would be easier for backwards-compatibility 
> reasons to just rename them to something slightly more awkward, so that 
> previous versions of the stdlib don't spontaneously break for more recent 
> compilers. This is more of an issue when you're dealing with package managers 
> like apt, where some things depend on libc++-v$OLD, but there aren't any 
> restrictions on Clang's version (for example, I use nightly Clang on Ubuntu, 
> but apt notes that the Discord app has an older libc++ dependency).
> 
> After having let this sit for a few months, I don't really have strong 
> opinions on reserving `__std_trait` anymore, so I'll touch this up in the 
> morning.
I just checked and I think we define `__remove_cvref_t`, but not 
`__remove_cvref` (that probably changed in the last year). In the future, don't 
hesitate to ping us if we are using a name that Clang would like to use, we 
should almost always be able to quickly get out of your way!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135341

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


[PATCH] D143768: [Clang] Add options to disable direct linking of arch tools

2023-02-10 Thread Aaron Siddhartha Mondal via Phabricator via cfe-commits
aaronmondal added a comment.

Does this address the case where we have HSA headers present on the system?

Since this only seems to modify link time behavior, I think building with this 
flag would still include "hsa/hsa.h" if they were present.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143768

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


[PATCH] D143768: [Clang] Add options to disable direct linking of arch tools

2023-02-10 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added a comment.

In D143768#4119021 , @aaronmondal 
wrote:

> Does this address the case where we have HSA headers present on the system?
>
> Since this only seems to modify link time behavior, I think building with 
> this flag would still include "hsa/hsa.h" if they were present.

Those headers are guarded behind `#ifndef DYNAMIC_CUDA`. This is how we 
configure it to use the `dlopen` method, see the `target_compile_definitions` 
line. We used to use `__has_include` but it caused buildbots to fail for 
Windows cross compiling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143768

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


[PATCH] D122215: [WebAssembly] Initial support for reference type externref in clang

2023-02-10 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added a comment.

In D122215#4118516 , @asb wrote:

> @pmatos and I have tried and failed to reproduce the assert in the stage3 
> msan build locally (both of us on separate machines, different environments). 
> We've reached out to @vitalybuka via email for any help in reproducing, 
> because we're somewhat stumped at the moment.

I will try to reproduce on fresh VM and reply to you with details.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122215

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


[PATCH] D143624: Inlining: Run the legacy AlwaysInliner before the regular inliner.

2023-02-10 Thread Dave Green via Phabricator via cfe-commits
dmgreen added a comment.

> I’ll take a look, but this indicates to me that there’s something missing 
> from the vectoriser or later passes rather than a problem with the inliners 
> behaviour.

Sure. I'm not saying that this patch is wrong. I'm just saying that 
unfortunately it leads to some pretty large regressions. Hopefully we can 
figure out why and put fixes in place instead of just bodging the tests. 
Hopefully it's just some missing fold to get the code into the same form it was 
before, after all the inlining has happened.

I took a look at one of the other cases, it appears to be a pretty unfortunate 
case of the load order in loops leading to LSR not recognizing chains of 
instructions due to them being order with offsets [2,0,6,4,10,8,..], as opposed 
to the order they were in before [0,2,4,6,8,10...], which was an easier to 
reason about. https://godbolt.org/z/Grv64xoxW. I'm not sure exactly what the 
best way to fix that would be, without making other cases worse.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143624

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


[clang-tools-extra] a543d84 - Fix handling of -> calls for modernize-use-emplace

2023-02-10 Thread Carlos Galvez via cfe-commits

Author: BigPeet
Date: 2023-02-10T18:52:56Z
New Revision: a543d840ee0ac53ef9df70c0e2a996e1a222064b

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

LOG: Fix handling of -> calls for modernize-use-emplace

Fixes #55869

Reviewed By: njames93, nicovank

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp 
b/clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
index ccd07065d1573..554abcd900e32 100644
--- a/clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
@@ -80,6 +80,29 @@ AST_MATCHER(DeclRefExpr, hasExplicitTemplateArgs) {
   return Node.hasExplicitTemplateArgs();
 }
 
+// Helper Matcher which applies the given QualType Matcher either directly or 
by
+// resolving a pointer type to its pointee. Used to match v.push_back() as well
+// as p->push_back().
+auto hasTypeOrPointeeType(
+const ast_matchers::internal::Matcher &TypeMatcher) {
+  return anyOf(hasType(TypeMatcher),
+   hasType(pointerType(pointee(TypeMatcher;
+}
+
+// Matches if the node has canonical type matching any of the given names.
+auto hasWantedType(llvm::ArrayRef TypeNames) {
+  return 
hasCanonicalType(hasDeclaration(cxxRecordDecl(hasAnyName(TypeNames;
+}
+
+// Matches member call expressions of the named method on the listed container
+// types.
+auto cxxMemberCallExprOnContainer(
+StringRef MethodName, llvm::ArrayRef ContainerNames) {
+  return cxxMemberCallExpr(
+  hasDeclaration(functionDecl(hasName(MethodName))),
+  on(hasTypeOrPointeeType(hasWantedType(ContainerNames;
+}
+
 const auto DefaultContainersWithPushBack =
 "::std::vector; ::std::list; ::std::deque";
 const auto DefaultContainersWithPush =
@@ -130,27 +153,19 @@ void UseEmplaceCheck::registerMatchers(MatchFinder 
*Finder) {
   // because this requires special treatment (it could cause performance
   // regression)
   // + match for emplace calls that should be replaced with insertion
-  auto CallPushBack = cxxMemberCallExpr(
-  hasDeclaration(functionDecl(hasName("push_back"))),
-  on(hasType(hasCanonicalType(
-  
hasDeclaration(cxxRecordDecl(hasAnyName(ContainersWithPushBack)));
-
-  auto CallPush =
-  cxxMemberCallExpr(hasDeclaration(functionDecl(hasName("push"))),
-on(hasType(hasCanonicalType(hasDeclaration(
-cxxRecordDecl(hasAnyName(ContainersWithPush)));
-
-  auto CallPushFront = cxxMemberCallExpr(
-  hasDeclaration(functionDecl(hasName("push_front"))),
-  on(hasType(hasCanonicalType(hasDeclaration(
-  cxxRecordDecl(hasAnyName(ContainersWithPushFront)));
+  auto CallPushBack =
+  cxxMemberCallExprOnContainer("push_back", ContainersWithPushBack);
+  auto CallPush = cxxMemberCallExprOnContainer("push", ContainersWithPush);
+  auto CallPushFront =
+  cxxMemberCallExprOnContainer("push_front", ContainersWithPushFront);
 
   auto CallEmplacy = cxxMemberCallExpr(
   hasDeclaration(
   functionDecl(hasAnyNameIgnoringTemplates(EmplacyFunctions))),
-  on(hasType(hasCanonicalType(hasDeclaration(has(typedefNameDecl(
-  hasName("value_type"), hasType(type(hasUnqualifiedDesugaredType(
- recordType().bind("value_type")));
+  on(hasTypeOrPointeeType(hasCanonicalType(hasDeclaration(
+  has(typedefNameDecl(hasName("value_type"),
+  hasType(type(hasUnqualifiedDesugaredType(
+  recordType().bind("value_type")));
 
   // We can't replace push_backs of smart pointer because
   // if emplacement fails (f.e. bad_alloc in vector) we will have leak of

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp 
b/clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
index 537263d988be3..a055b25798de0 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
+++ b/clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
@@ -1334,3 +1334,90 @@ void testBracedInitTemporaries() {
   v3.push_back({{0}});
   v3.push_back({{}});
 }
+
+void testWithPointerTypes() {
+  std::list l;
+  std::list* lp = &l;
+  std::stack s;
+  std::stack* sp;
+
+  lp->push_back(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_back instead of 
push_back [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_back(1, 2);
+  lp->push_front(Something(1, 2));
+  // CHECK-MESSAGES: :[[

[PATCH] D142939: Fix handling of -> calls for modernize-use-emplace

2023-02-10 Thread Carlos Galvez via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa543d840ee0a: Fix handling of -> calls for 
modernize-use-emplace (authored by BigPeet, committed by carlosgalvezp).

Changed prior to commit:
  https://reviews.llvm.org/D142939?vs=493756&id=496552#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142939

Files:
  clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
@@ -1334,3 +1334,90 @@
   v3.push_back({{0}});
   v3.push_back({{}});
 }
+
+void testWithPointerTypes() {
+  std::list l;
+  std::list* lp = &l;
+  std::stack s;
+  std::stack* sp;
+
+  lp->push_back(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_back instead of push_back [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_back(1, 2);
+  lp->push_front(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_front instead of push_front [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_front(1, 2);
+  sp->push(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace instead of push [modernize-use-emplace]
+  // CHECK-FIXES: sp->emplace(1, 2);
+
+  lp->push_back(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_back instead of push_back [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_back(1, 2);
+  lp->push_front(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_front instead of push_front [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_front(1, 2);
+  sp->push(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace instead of push [modernize-use-emplace]
+  // CHECK-FIXES: sp->emplace(1, 2);
+
+  lp->push_back(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_back instead of push_back [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_back();
+  lp->push_front(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_front instead of push_front [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_front();
+  sp->push(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace instead of push [modernize-use-emplace]
+  // CHECK-FIXES: sp->emplace();
+
+  lp->push_back(Something{});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_back instead of push_back [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_back();
+  lp->push_front(Something{});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_front instead of push_front [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_front();
+  sp->push(Something{});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace instead of push [modernize-use-emplace]
+  // CHECK-FIXES: sp->emplace();
+
+  lp->emplace_back(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: unnecessary temporary object created while calling emplace_back
+  // CHECK-FIXES: lp->emplace_back(1, 2);
+  lp->emplace_front(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: unnecessary temporary object created while calling emplace_front
+  // CHECK-FIXES: lp->emplace_front(1, 2);
+  sp->emplace(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: unnecessary temporary object created while calling emplace
+  // CHECK-FIXES: sp->emplace(1, 2);
+
+  lp->emplace_back(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: unnecessary temporary object created while calling emplace_back
+  // CHECK-FIXES: lp->emplace_back(1, 2);
+  lp->emplace_front(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: unnecessary temporary object created while calling emplace_front
+  // CHECK-FIXES: lp->emplace_front(1, 2);
+  sp->emplace(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: unnecessary temporary object created while calling emplace
+  // CHECK-FIXES: sp->emplace(1, 2);
+
+  lp->emplace_back(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: unnecessary temporary object created while calling emplace_back
+  // CHECK-FIXES: lp->emplace_back();
+  lp->emplace_front(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: unnecessary temporary object created while calling emplace_front
+  // CHECK-FIXES: lp->emplace_front();
+  sp->emplace(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: unnecessary temporary object created while calling emplace
+  // CHECK-FIXES: sp->emplace();
+
+  lp->emplace_back(Something{});
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: unnecessary temporary object created while ca

  1   2   >