date:20230912

[clang] [clang][dataflow] Change `diagnoseFunction` to take type of diagnostic list instead of diagnostic itself. (PR #66014)

2023-09-12 Thread via cfe-commits


martinboehme wrote:

I'm not convinced of the value of this change. Wouldn't it be simpler to keep 
the template arguments of `diagnoseFunction()` unchanged and instead change the 
return type to be `llvm::Expected>`? In other 
words, always return an `llvm::SmallVector` instead of a `std::vector`?

I think `llvm::SmallVector` makes sense for both callsites that currently exist 
(and ones that we might add in the future). This patch currently lets 
`UncheckedOptionalAccessCheck::check()` continue to use `std::vector`, but I 
think `llvm::SmallVector` makes sense there as well, as in the common case, we 
expect only a small number of diagnostics or none at all. This seems like it 
would be true for any function that wants to call `diagnoseFunction()` in the 
future as well.

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

[clang] [clang][dataflow] Change `diagnoseFunction` to take type of diagnostic list instead of diagnostic itself. (PR #66014)

2023-09-12 Thread via cfe-commits


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

[clang] [clang][dataflow] Change `diagnoseFunction` to take type of diagnostic list instead of diagnostic itself. (PR #66014)

2023-09-12 Thread via cfe-commits


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


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

[clang] [clang][dataflow] Change `diagnoseFunction` to take type of diagnostic list instead of diagnostic itself. (PR #66014)

2023-09-12 Thread via cfe-commits


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

[clang] [clang][dataflow] Change `diagnoseFunction` to take type of diagnostic list instead of diagnostic itself. (PR #66014)

2023-09-12 Thread via cfe-commits



@@ -245,10 +245,10 @@ runDataflowAnalysis(
 ///   iterations.
 /// - This limit is still low enough to keep runtimes acceptable (on typical
 ///   machines) in cases where we hit the limit.
-template 
-llvm::Expected> diagnoseFunction(
+template 
+llvm::Expected diagnoseFunction(

martinboehme wrote:

```suggestion
template 
llvm::Expected> diagnoseFunction(
```

See also PR-level comment with rationale.

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

[clang] 7cf20f1 - [clang][dataflow] Eliminate `RecordValue::getChild()`. (#65586)

2023-09-12 Thread via cfe-commits


Author: martinboehme
Date: 2023-09-12T09:17:38+02:00
New Revision: 7cf20f156f6c6133456fb7bcf2f7b88e87fa5ff5

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

LOG: [clang][dataflow] Eliminate `RecordValue::getChild()`. (#65586)

We want to eliminate the `RecordStorageLocation` from `RecordValue` and,
ultimately, eliminate `RecordValue` entirely (see the discussion linked
in the
`RecordValue` class comment). This is one step in that direction.

To eliminate `RecordValue::getChild()`, we also eliminate the last
remaining
caller, namely the `getFieldValue(const RecordValue *, ...)` overload.
Calls
to this overload have been rewritten to use the
`getFieldValue(const RecordStorageLocation *, ...)` overload. Note that
this
also makes the code slightly simpler in many cases.

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/Value.h
clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
clang/unittests/Analysis/FlowSensitive/TestingSupport.h
clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/Value.h 
b/clang/include/clang/Analysis/FlowSensitive/Value.h
index 6e911af7264ced9..e6c68e5b4e93e1e 100644
--- a/clang/include/clang/Analysis/FlowSensitive/Value.h
+++ b/clang/include/clang/Analysis/FlowSensitive/Value.h
@@ -225,12 +225,6 @@ class RecordValue final : public Value {
   /// Returns the storage location that this `RecordValue` is associated with.
   RecordStorageLocation &getLoc() const { return Loc; }
 
-  /// Convenience function that returns the child storage location for `Field`.
-  /// See also the documentation for `RecordStorageLocation::getChild()`.
-  StorageLocation *getChild(const ValueDecl &Field) const {
-return Loc.getChild(Field);
-  }
-
 private:
   RecordStorageLocation &Loc;
 };

diff  --git 
a/clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
index 6e37011a052c5e4..ad40c0b082d302e 100644
--- a/clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
@@ -91,8 +91,8 @@ TEST_F(EnvironmentTest, CreateValueRecursiveType) {
   // Verify that the struct and the field (`R`) with first appearance of the
   // type is created successfully.
   Environment Env(DAContext, *Fun);
-  RecordValue *SVal = cast(Env.createValue(Ty));
-  PointerValue *PV = cast_or_null(getFieldValue(SVal, *R, Env));
+  auto &SLoc = cast(Env.createObject(Ty));
+  PointerValue *PV = cast_or_null(getFieldValue(&SLoc, *R, Env));
   EXPECT_THAT(PV, NotNull());
 }
 
@@ -240,8 +240,8 @@ TEST_F(EnvironmentTest, 
IncludeFieldsFromDefaultInitializers) {
   // Verify that the `X` field of `S` is populated when analyzing the
   // constructor, even though it is not referenced directly in the constructor.
   Environment Env(DAContext, *Constructor);
-  auto *Val = cast(Env.createValue(QTy));
-  EXPECT_THAT(getFieldValue(Val, *XDecl, Env), NotNull());
+  auto &Loc = cast(Env.createObject(QTy));
+  EXPECT_THAT(getFieldValue(&Loc, *XDecl, Env), NotNull());
 }
 
 TEST_F(EnvironmentTest, InitGlobalVarsFieldFun) {
@@ -285,8 +285,7 @@ TEST_F(EnvironmentTest, InitGlobalVarsFieldFun) {
   Environment Env(DAContext, *Fun);
   const auto *GlobalLoc =
   cast(Env.getStorageLocation(*GlobalDecl));
-  const auto *GlobalVal = cast(Env.getValue(*GlobalLoc));
-  auto *BarVal = getFieldValue(GlobalVal, *BarDecl, Env);
+  auto *BarVal = getFieldValue(GlobalLoc, *BarDecl, Env);
   EXPECT_TRUE(isa(BarVal));
 }
 

diff  --git a/clang/unittests/Analysis/FlowSensitive/TestingSupport.h 
b/clang/unittests/Analysis/FlowSensitive/TestingSupport.h
index c61e9f26beff40b..0cf66c218f43fdc 100644
--- a/clang/unittests/Analysis/FlowSensitive/TestingSupport.h
+++ b/clang/unittests/Analysis/FlowSensitive/TestingSupport.h
@@ -463,18 +463,6 @@ inline Value *getFieldValue(const RecordStorageLocation 
*Loc,
   return Env.getValue(*FieldLoc);
 }
 
-/// Returns the value of a `Field` on a `Struct.
-/// Returns null if `Struct` is null.
-inline Value *getFieldValue(const RecordValue *Struct, const ValueDecl &Field,
-const Environment &Env) {
-  if (Struct == nullptr)
-return nullptr;
-  StorageLocation *FieldLoc = Struct->getChild(Field);
-  if (FieldLoc == nullptr)
-return nullptr;
-  return Env.getValue(*FieldLoc);
-}
-
 /// Creates and owns constraints which are boolean values.
 class ConstraintContext {
   unsigned NextAtom = 0;

diff  --git a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
index cced3925c4721c5..05ee5df0e95a433 100644
--- a/clang/unittests/Analys

[clang] [clang][dataflow] Eliminate `RecordValue::getChild()`. (PR #65586)

2023-09-12 Thread via cfe-commits


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

[clang] [clang][dataflow] Remove RecordValue.getLog() usage in HTMLLogger (PR #65645)

2023-09-12 Thread via cfe-commits


martinboehme wrote:

> Here's the screenshot for a simple code snippet !
[snip]
> You can see some more screenshots here: 
> https://docs.google.com/document/d/1gJqU5g7HCUifDUJBb5NzSBC0K-9W4nyZ3zxtpbTUDdk/view

Thanks for this -- looks great! Just wanted to make sure the output makes sense 
in context.

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

[clang] [clang][dataflow] Remove RecordValue.getLog() usage in HTMLLogger (PR #65645)

2023-09-12 Thread via cfe-commits


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


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

[PATCH] D159498: [clangd] Implement the 'Organize Imports' source action. Fix include-cleaner findings in batch.

2023-09-12 Thread Viktoriia Bakalova via Phabricator via cfe-commits

VitaNuo updated this revision to Diff 556531.
VitaNuo added a comment.

Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159498

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/ParsedAST.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/refactor/Tweak.cpp
  clang-tools-extra/clangd/refactor/Tweak.h
  clang-tools-extra/clangd/refactor/tweaks/CMakeLists.txt
  clang-tools-extra/clangd/refactor/tweaks/OrganizeImports.cpp
  clang-tools-extra/clangd/test/code-action-request.test
  clang-tools-extra/clangd/test/include-cleaner-batch-fix.test
  clang-tools-extra/clangd/test/request-reply.test
  clang-tools-extra/clangd/test/tweaks-format.test
  clang-tools-extra/clangd/tool/Check.cpp
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/ClangdTests.cpp
  clang-tools-extra/clangd/unittests/FeatureModulesTests.cpp
  clang-tools-extra/clangd/unittests/tweaks/OrganizeImportsTests.cpp
  clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
  clang-tools-extra/clangd/unittests/tweaks/TweakTesting.h

Index: clang-tools-extra/clangd/unittests/tweaks/TweakTesting.h
===
--- clang-tools-extra/clangd/unittests/tweaks/TweakTesting.h
+++ clang-tools-extra/clangd/unittests/tweaks/TweakTesting.h
@@ -18,6 +18,7 @@
 #include "gtest/gtest.h"
 #include 
 #include 
+#include 
 
 namespace clang {
 namespace clangd {
@@ -88,13 +89,16 @@
   //  - if the tweak produces a message, returns "message:\n"
   //  - if prepare() returns false, returns "unavailable"
   //  - if apply() returns an error, returns "fail: "
-  std::string apply(llvm::StringRef MarkedCode,
-llvm::StringMap *EditedFiles = nullptr) const;
+  std::string
+  apply(llvm::StringRef MarkedCode,
+llvm::StringMap *EditedFiles = nullptr,
+const std::vector &RequestedActionKinds = {}) const;
 
   // Helpers for EXPECT_AVAILABLE/EXPECT_UNAVAILABLE macros.
   using WrappedAST = std::pair;
   WrappedAST build(llvm::StringRef) const;
-  bool isAvailable(WrappedAST &, llvm::Annotations::Range) const;
+  bool isAvailable(WrappedAST &, llvm::Annotations::Range,
+   const std::vector & = {}) const;
   // Return code re-decorated with a single point/range.
   static std::string decorate(llvm::StringRef, unsigned);
   static std::string decorate(llvm::StringRef, llvm::Annotations::Range);
@@ -116,9 +120,10 @@
 auto AST = build(A.code());\
 assert(!A.points().empty() || !A.ranges().empty());\
 for (const auto &P : A.points())   \
-  EXPECT_EQ(Available, isAvailable(AST, {P, P})) << decorate(A.code(), P); \
+  EXPECT_EQ(Available, isAvailable(AST, {P, P}, {}))   \
+  << decorate(A.code(), P);\
 for (const auto &R : A.ranges())   \
-  EXPECT_EQ(Available, isAvailable(AST, R)) << decorate(A.code(), R);  \
+  EXPECT_EQ(Available, isAvailable(AST, R, {})) << decorate(A.code(), R);  \
   } while (0)
 #define EXPECT_AVAILABLE(MarkedCode) EXPECT_AVAILABLE_(MarkedCode, true)
 #define EXPECT_UNAVAILABLE(MarkedCode) EXPECT_AVAILABLE_(MarkedCode, false)
Index: clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
@@ -8,6 +8,7 @@
 
 #include "TweakTesting.h"
 
+#include "Protocol.h"
 #include "SourceCode.h"
 #include "TestTU.h"
 #include "refactor/Tweak.h"
@@ -16,6 +17,7 @@
 #include "gtest/gtest.h"
 #include 
 #include 
+#include 
 
 namespace clang {
 namespace clangd {
@@ -63,12 +65,14 @@
 // Returns std::nullopt if and only if prepare() failed.
 std::optional>
 applyTweak(ParsedAST &AST, llvm::Annotations::Range Range, StringRef TweakID,
-   const SymbolIndex *Index, llvm::vfs::FileSystem *FS) {
+   const SymbolIndex *Index, llvm::vfs::FileSystem *FS,
+   const std::vector &RequestedActionKinds) {
   std::optional> Result;
   SelectionTree::createEach(AST.getASTContext(), AST.getTokens(), Range.Begin,
 Range.End, [&](SelectionTree ST) {
   Tweak::Selection S(Index, AST, Range.Begin,
- Range.End, std::move(ST), FS);
+ Range.End, std::move(ST), FS,
+ RequestedActionKinds);

[clang] [AMDGPU] Remove Code Object V2 (PR #65715)

2023-09-12 Thread via cfe-commits


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

[PATCH] D153769: [clangd] Implement the 'Organize Imports' source action. Fix include-cleaner findings in batch.

2023-09-12 Thread Viktoriia Bakalova via Phabricator via cfe-commits

VitaNuo marked 2 inline comments as done.
VitaNuo added a comment.

I'm sorry I think the upload failed because I tried to upload without a message 
or something, and I didn't notice that it failed :(


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153769

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

[clang] [AMDGPU] Remove Code Object V2 (PR #65715)

2023-09-12 Thread via cfe-commits


llvmbot wrote:

@llvm/pr-subscribers-lld-elf


Changes

Code Object V2 has been deprecated for more than a year now. We can safely 
remove it from LLVM.

- [clang] Remove support for the `-mcode-object-version=2` option.
- [lld] Remove/refactor tests that were still using COV2
- [llvm] Update AMDGPUUsage.rst
   - Code Object V2 docs are left for informational purposes because those code 
objects may still be supported by the runtime/loaders for a while.
- [AMDGPU] Remove COV2 emission capabilities.
- [AMDGPU] Remove `MetadataStreamerYamlV2` which was only used by COV2
- [AMDGPU] Update all tests that were still using COV2 - They are either 
deleted or ported directly to code object v4 (as v3 is also planned to be 
removed soon).
--

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

82 Files Affected:

- (modified) clang/include/clang/Basic/TargetOptions.h (+1-1) 
- (modified) clang/include/clang/Driver/Options.td (+2-2) 
- (modified) clang/lib/Driver/ToolChains/CommonArgs.cpp (+1-1) 
- (modified) clang/test/CodeGenCUDA/amdgpu-code-object-version.cu (-4) 
- (modified) clang/test/Driver/hip-code-object-version.hip (+10-13) 
- (modified) lld/test/ELF/Inputs/amdgpu-kernel-0.s (-1) 
- (modified) lld/test/ELF/Inputs/amdgpu-kernel-1.s (-1) 
- (modified) lld/test/ELF/amdgpu-abi-version-err.s (+2-2) 
- (modified) lld/test/ELF/amdgpu-elf-flags-err.s (+3-3) 
- (modified) lld/test/ELF/amdgpu-elf-flags.s (+2-2) 
- (removed) lld/test/ELF/amdgpu-kernels.s (-56) 
- (modified) llvm/docs/AMDGPUUsage.rst (+5-10) 
- (modified) llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp (+5-24) 
- (modified) llvm/lib/Target/AMDGPU/AMDGPUHSAMetadataStreamer.cpp (-429) 
- (modified) llvm/lib/Target/AMDGPU/AMDGPUHSAMetadataStreamer.h (-76) 
- (modified) llvm/lib/Target/AMDGPU/AsmParser/AMDGPUAsmParser.cpp (+17-31) 
- (modified) llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp 
(+2-5) 
- (modified) llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp (+5-65) 
- (modified) llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.h (+2-7) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.dispatch.id.ll 
(+2-4) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.dispatch.ptr.ll 
(+2-2) 
- (modified) 
llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.kernarg.segment.ptr.ll (+27-23) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.queue.ptr.ll 
(+2-2) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.workgroup.id.ll 
(+47-49) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.workitem.id.ll 
(+19-19) 
- (modified) llvm/test/CodeGen/AMDGPU/addrspacecast.ll (+28-20) 
- (modified) llvm/test/CodeGen/AMDGPU/amdgpu.private-memory.ll (+15-19) 
- (modified) llvm/test/CodeGen/AMDGPU/attr-amdgpu-flat-work-group-size.ll 
(+10-12) 
- (modified) llvm/test/CodeGen/AMDGPU/call-graph-register-usage.ll (+4-14) 
- (modified) llvm/test/CodeGen/AMDGPU/callee-special-input-vgprs.ll (+19-10) 
- (modified) llvm/test/CodeGen/AMDGPU/control-flow-fastregalloc.ll (+5-4) 
- (modified) llvm/test/CodeGen/AMDGPU/flat-for-global-subtarget-feature.ll 
(+9-10) 
- (modified) llvm/test/CodeGen/AMDGPU/flat-scratch-reg.ll (+16-40) 
- (modified) llvm/test/CodeGen/AMDGPU/gfx902-without-xnack.ll (+2-3) 
- (modified) llvm/test/CodeGen/AMDGPU/hsa-default-device.ll (+2-2) 
- (modified) llvm/test/CodeGen/AMDGPU/hsa-fp-mode.ll (+28-28) 
- (modified) llvm/test/CodeGen/AMDGPU/hsa-func.ll (+11-11) 
- (removed) llvm/test/CodeGen/AMDGPU/hsa-metadata-deduce-ro-arg-v2.ll (-35) 
- (removed) llvm/test/CodeGen/AMDGPU/hsa-metadata-deduce-ro-arg.ll (-31) 
- (removed) llvm/test/CodeGen/AMDGPU/hsa-metadata-enqueue-kernel.ll (-92) 
- (removed) llvm/test/CodeGen/AMDGPU/hsa-metadata-from-llvm-ir-full.ll (-1931) 
- (removed) llvm/test/CodeGen/AMDGPU/hsa-metadata-hidden-args.ll (-313) 
- (removed) llvm/test/CodeGen/AMDGPU/hsa-metadata-images.ll (-95) 
- (removed) llvm/test/CodeGen/AMDGPU/hsa-metadata-invalid-ocl-version-1.ll 
(-11) 
- (removed) llvm/test/CodeGen/AMDGPU/hsa-metadata-invalid-ocl-version-2-v3.ll 
(-14) 
- (removed) llvm/test/CodeGen/AMDGPU/hsa-metadata-invalid-ocl-version-2.ll 
(-12) 
- (removed) llvm/test/CodeGen/AMDGPU/hsa-metadata-invalid-ocl-version-3.ll 
(-12) 
- (removed) llvm/test/CodeGen/AMDGPU/hsa-metadata-kernel-code-props.ll (-173) 
- (modified) llvm/test/CodeGen/AMDGPU/hsa-note-no-func.ll (+52-53) 
- (modified) llvm/test/CodeGen/AMDGPU/hsa.ll (+68-34) 
- (modified) llvm/test/CodeGen/AMDGPU/indirect-call.ll (+5-277) 
- (modified) llvm/test/CodeGen/AMDGPU/kernel-argument-dag-lowering.ll (+24-20) 
- (modified) llvm/test/CodeGen/AMDGPU/lds-alignment.ll (+15-28) 
- (modified) llvm/test/CodeGen/AMDGPU/lds-size.ll (+3-3) 
- (modified) llvm/test/CodeGen/AMDGPU/llvm.amdgcn.dispatch.id.ll (+2-3) 
- (modified) llvm/test/CodeGen/AMDGPU/llvm.amdgcn.dispatch.ptr.ll (+3-3) 
- (modified) llvm/test/CodeGen/AMDGPU/llvm.amdgcn.implicitarg.ptr.ll (+50-128) 
- (modified) llvm/test/CodeGen/AM

[PATCH] D135341: adds `__reference_constructs_from_temporary`

2023-09-12 Thread Corentin Jabot via Phabricator via cfe-commits

cor3ntin added inline comments.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:33
 #include "clang/Basic/TypeTraits.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Lex/Preprocessor.h"

Superfluous change



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5513
+
+  QualType TPtr = S.BuiltinAddPointer(S.BuiltinRemoveReference(T, 
UnaryTransformType::RemoveCVRef, {}), {});
+  QualType UPtr = S.BuiltinAddPointer(S.BuiltinRemoveReference(U, 
UnaryTransformType::RemoveCVRef, {}), {});

`BuiltinRemoveReference` is nice here as I don't think we have a way to remove 
all cv and ref in one go at the ASTContext/QualType level.
However `BuiltinAddPointer` does nothing for us over 
`Context.getPointerType()`, so I'd rather we used that.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5515
+  QualType UPtr = S.BuiltinAddPointer(S.BuiltinRemoveReference(U, 
UnaryTransformType::RemoveCVRef, {}), {});
+  return EvaluateBinaryTypeTrait(S, TypeTrait::BTT_IsConvertibleTo, UPtr, 
TPtr, RParenLoc);
 }

Could you put the implementation of `BTT_IsConvertibleTo` in its own function?


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

[clang] [include-mapping] Python fixes (PR #65401)

2023-09-12 Thread Haojian Wu via cfe-commits


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

thanks.

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

[PATCH] D153769: [clangd] Implement the 'Organize Imports' source action. Fix include-cleaner findings in batch.

2023-09-12 Thread Viktoriia Bakalova via Phabricator via cfe-commits

VitaNuo updated this revision to Diff 556532.
VitaNuo marked an inline comment as done.
VitaNuo added a comment.

Address review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153769

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/ParsedAST.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/refactor/Tweak.cpp
  clang-tools-extra/clangd/refactor/Tweak.h
  clang-tools-extra/clangd/refactor/tweaks/CMakeLists.txt
  clang-tools-extra/clangd/refactor/tweaks/OrganizeImports.cpp
  clang-tools-extra/clangd/test/code-action-request.test
  clang-tools-extra/clangd/test/include-cleaner-batch-fix.test
  clang-tools-extra/clangd/test/request-reply.test
  clang-tools-extra/clangd/test/tweaks-format.test
  clang-tools-extra/clangd/tool/Check.cpp
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/ClangdTests.cpp
  clang-tools-extra/clangd/unittests/FeatureModulesTests.cpp
  clang-tools-extra/clangd/unittests/tweaks/OrganizeImportsTests.cpp
  clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
  clang-tools-extra/clangd/unittests/tweaks/TweakTesting.h

Index: clang-tools-extra/clangd/unittests/tweaks/TweakTesting.h
===
--- clang-tools-extra/clangd/unittests/tweaks/TweakTesting.h
+++ clang-tools-extra/clangd/unittests/tweaks/TweakTesting.h
@@ -18,6 +18,7 @@
 #include "gtest/gtest.h"
 #include 
 #include 
+#include 
 
 namespace clang {
 namespace clangd {
@@ -88,13 +89,16 @@
   //  - if the tweak produces a message, returns "message:\n"
   //  - if prepare() returns false, returns "unavailable"
   //  - if apply() returns an error, returns "fail: "
-  std::string apply(llvm::StringRef MarkedCode,
-llvm::StringMap *EditedFiles = nullptr) const;
+  std::string
+  apply(llvm::StringRef MarkedCode,
+llvm::StringMap *EditedFiles = nullptr,
+const std::vector &RequestedActionKinds = {}) const;
 
   // Helpers for EXPECT_AVAILABLE/EXPECT_UNAVAILABLE macros.
   using WrappedAST = std::pair;
   WrappedAST build(llvm::StringRef) const;
-  bool isAvailable(WrappedAST &, llvm::Annotations::Range) const;
+  bool isAvailable(WrappedAST &, llvm::Annotations::Range,
+   const std::vector & = {}) const;
   // Return code re-decorated with a single point/range.
   static std::string decorate(llvm::StringRef, unsigned);
   static std::string decorate(llvm::StringRef, llvm::Annotations::Range);
@@ -116,9 +120,10 @@
 auto AST = build(A.code());\
 assert(!A.points().empty() || !A.ranges().empty());\
 for (const auto &P : A.points())   \
-  EXPECT_EQ(Available, isAvailable(AST, {P, P})) << decorate(A.code(), P); \
+  EXPECT_EQ(Available, isAvailable(AST, {P, P}, {}))   \
+  << decorate(A.code(), P);\
 for (const auto &R : A.ranges())   \
-  EXPECT_EQ(Available, isAvailable(AST, R)) << decorate(A.code(), R);  \
+  EXPECT_EQ(Available, isAvailable(AST, R, {})) << decorate(A.code(), R);  \
   } while (0)
 #define EXPECT_AVAILABLE(MarkedCode) EXPECT_AVAILABLE_(MarkedCode, true)
 #define EXPECT_UNAVAILABLE(MarkedCode) EXPECT_AVAILABLE_(MarkedCode, false)
Index: clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
@@ -8,6 +8,7 @@
 
 #include "TweakTesting.h"
 
+#include "Protocol.h"
 #include "SourceCode.h"
 #include "TestTU.h"
 #include "refactor/Tweak.h"
@@ -16,6 +17,7 @@
 #include "gtest/gtest.h"
 #include 
 #include 
+#include 
 
 namespace clang {
 namespace clangd {
@@ -63,12 +65,14 @@
 // Returns std::nullopt if and only if prepare() failed.
 std::optional>
 applyTweak(ParsedAST &AST, llvm::Annotations::Range Range, StringRef TweakID,
-   const SymbolIndex *Index, llvm::vfs::FileSystem *FS) {
+   const SymbolIndex *Index, llvm::vfs::FileSystem *FS,
+   const std::vector &RequestedActionKinds) {
   std::optional> Result;
   SelectionTree::createEach(AST.getASTContext(), AST.getTokens(), Range.Begin,
 Range.End, [&](SelectionTree ST) {
   Tweak::Selection S(Index, AST, Range.Begin,
- Range.End, std::move(ST), FS);
+ Range.End, std::move(ST), FS,
+ Requ

[PATCH] D153769: [clangd] Implement the 'Organize Imports' source action. Fix include-cleaner findings in batch.

2023-09-12 Thread Viktoriia Bakalova via Phabricator via cfe-commits

VitaNuo added a comment.

I think I also managed to update the wrong patch. Not sure how an alternative 
patch got created in the first place :( Sorry for the mess, should be fine now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153769

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

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits


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

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits



@@ -214,6 +214,14 @@ class StmtComparer {
 return E1->size() == E2->size();
   }
 
+  bool IsStmtEquivalent(const DeclRefExpr *DRE1, const DeclRefExpr *DRE2) {
+if (nullptr == DRE1->getDecl() || nullptr == DRE2->getDecl()) {
+  return false;
+}
+return IsStructurallyEquivalent(Context, DRE1->getDecl()->getDeclName(),

cor3ntin wrote:

Shouldn't that simply be `IsStructurallyEquivalent(DRE1->getDecl(), 
DRE2->getDecl())` ?

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

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits


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

Thanks for working on that!
Can you explain why you are comparing declaration only with their name? that 
seems suspicious to me. Otherwise, I think the intent of the change is correct

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

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits



@@ -214,6 +214,14 @@ class StmtComparer {
 return E1->size() == E2->size();
   }
 
+  bool IsStmtEquivalent(const DeclRefExpr *DRE1, const DeclRefExpr *DRE2) {
+if (nullptr == DRE1->getDecl() || nullptr == DRE2->getDecl()) {

cor3ntin wrote:

```suggestion
if (!DRE1->getDecl() || !DRE2->getDecl()) {
```

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

[PATCH] D153769: [clangd] Implement the 'Organize Imports' source action. Fix include-cleaner findings in batch.

2023-09-12 Thread Viktoriia Bakalova via Phabricator via cfe-commits

VitaNuo marked an inline comment as done.
VitaNuo added a comment.

Respond to comments.




Comment at: clang-tools-extra/clangd/refactor/tweaks/OrganizeImports.cpp:56
+return false;
+  Range PreambleRange;
+  PreambleRange.start =

kadircet wrote:
> VitaNuo wrote:
> > kadircet wrote:
> > > kadircet wrote:
> > > > relying on `MainFileIncludes` for preamble range is not correct in 
> > > > general. we can have includes way down inside the main file that'll be 
> > > > part of this vector, but not preamble (also it's not sorted explicitly).
> > > > 
> > > > we should instead use `ComputePreambleBounds` (nit: we can also store 
> > > > it in ParsedAST, instead of relexing the file one more time with each 
> > > > CodeAction request)
> > > Having a comment for reason would also be helpful, something like `To 
> > > accommodate clients without knowledge of source actions, we trigger 
> > > without checking code action kinds when inside the preamble region`.
> > > nit: we can also store it in ParsedAST
> > 
> > Seems like the data is already there, I just need to expose it.
> > > nit: we can also store it in ParsedAST
> > Seems like the data is already there, I just need to expose it.
> 
> not really, we calculate bounds when building a `ParsedAST` but we don't 
> store it anywhere.
I was referring to 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Frontend/PrecompiledPreamble.cpp#L580.
 We store the `PreambleData` and that seems to store the `PrecompiledPreamble` 
which seems to know its bounds


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153769

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

[clang] Fix out of line Concept-comparisons of NestedNameSpecifiers (PR #65993)

2023-09-12 Thread via cfe-commits


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

You obviously have a better grasp of that part of the code than I do, but the 
patch looks sensible to me. Thanks!

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

[clang] Fix out of line Concept-comparisons of NestedNameSpecifiers (PR #65993)

2023-09-12 Thread via cfe-commits



@@ -218,6 +218,9 @@ Bug Fixes in This Version
   (`#65156 `_`)
 - Clang no longer considers the loss of ``__unaligned`` qualifier from objects 
as
   an invalid conversion during method function overload resolution.
+- Clang now properly handles out of line template specializations when there is
+  a non-template inner-class between the function and the class template
+  (`#65810 `_).

cor3ntin wrote:

```suggestion
  a non-template inner-class between the function and the class template.
  (`#65810 `_)
```

For consistency (Yes, it's weird). Can you also move that to the "Bug Fixes to 
C++ Support" section?

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

[clang] Fix out of line Concept-comparisons of NestedNameSpecifiers (PR #65993)

2023-09-12 Thread via cfe-commits


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

[clang] [AMDGPU] Make default AMDHSA Code Object Version to be 5 (PR #65410)

2023-09-12 Thread via cfe-commits


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

[clang] [AArch64][SME]Update intrinsic interface for ldr/str (PR #65593)

2023-09-12 Thread via cfe-commits


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

[clang] [AArch64][SME]Update intrinsic interface for ldr/str (PR #65593)

2023-09-12 Thread via cfe-commits


https://github.com/sdesmalen-arm approved this pull request.


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

[clang] [AArch64][SME]Update intrinsic interface for ldr/str (PR #65593)

2023-09-12 Thread via cfe-commits



@@ -216,9 +216,9 @@ void test_range_0_15(svbool_t pg, void *ptr) {
   SVE_ACLE_FUNC(svst1_ver_vnum_za8,,,)(0, -1, 16, pg, ptr, 1);
 
   // expected-error@+1 {{argument value 16 is outside the valid range [0, 15]}}
-  SVE_ACLE_FUNC(svldr_vnum_za,,,)(-1, 16, ptr);
+  SVE_ACLE_FUNC(svldr_vnum_za,,,)(-1, ptr, 16);

sdesmalen-arm wrote:

Not something to fix in this patch, but we shouldn't be adding limits to the 
vnum parameter, or even require it to be a constant/immediate, because the SVE 
_vnum intrinsics also don't require this.

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

[clang] [AMDGPU] Make default AMDHSA Code Object Version to be 5 (PR #65410)

2023-09-12 Thread via cfe-commits


llvmbot wrote:

@llvm/pr-subscribers-lld-elf


Changes

Also update LIT tests and docs.
For more details, see
https://llvm.org/docs/AMDGPUUsage.html#code-object-v5-metadata

Differential Revision: https://reviews.llvm.org/D129818
--

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

109 Files Affected:

- (modified) clang/include/clang/Driver/Options.td (+2-2) 
- (modified) clang/lib/Driver/ToolChains/CommonArgs.cpp (+1-1) 
- (modified) clang/test/CodeGenCUDA/amdgpu-code-object-version.cu (+1-1) 
- (modified) clang/test/CodeGenCUDA/amdgpu-workgroup-size.cu (+2-2) 
- (modified) clang/test/CodeGenHIP/default-attributes.hip (+2-2) 
- (modified) clang/test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl (+2-2) 
- (modified) clang/test/CodeGenOpenCL/builtins-amdgcn.cl (+5-5) 
- (modified) clang/test/Driver/hip-device-libs.hip (+8-8) 
- (modified) lld/test/ELF/emulation-amdgpu.s (+1-1) 
- (modified) lld/test/ELF/lto/amdgcn-oses.ll (+1-1) 
- (modified) llvm/docs/AMDGPUUsage.rst (+7-8) 
- (modified) llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp (+2-2) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/crash-stack-address-O0.ll 
(+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/dropped_debug_info_assert.ll 
(+28-29) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-assert-align.ll 
(+8-8) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-atomicrmw.ll 
(+2-2) 
- (modified) 
llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-abi-attribute-hints.ll 
(+53-55) 
- (modified) 
llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-implicit-args.ll 
(+468-484) 
- (modified) 
llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-return-values.ll 
(+1578-1623) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-sret.ll 
(+31-32) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call.ll 
(+2013-2077) 
- (modified) 
llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-constant-fold-vector-op.ll 
(+2-2) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-indirect-call.ll 
(+31-32) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-inline-asm.ll 
(+51-51) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-sibling-call.ll 
(+18-18) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-tail-call.ll 
(+2-2) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-addrspacecast.mir 
(+28-39) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.private.ll 
(+5-6) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.shared.ll 
(+5-6) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/non-entry-alloca.ll (+7-4) 
- (modified) llvm/test/CodeGen/AMDGPU/abi-attribute-hints-undefined-behavior.ll 
(+75-35) 
- (modified) llvm/test/CodeGen/AMDGPU/addrspacecast-constantexpr.ll (+2-2) 
- (modified) llvm/test/CodeGen/AMDGPU/addrspacecast.gfx6.ll (+46-20) 
- (modified) llvm/test/CodeGen/AMDGPU/amdgpu-simplify-libcall-pow-codegen.ll 
(+30-30) 
- (modified) llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa-call.ll 
(+12-12) 
- (modified) llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa.ll (+8-7) 
- (modified) llvm/test/CodeGen/AMDGPU/attributor-noopt.ll (+1-1) 
- (modified) 
llvm/test/CodeGen/AMDGPU/blender-no-live-segment-at-def-implicit-def.ll 
(+22-24) 
- (modified) llvm/test/CodeGen/AMDGPU/branch-folding-implicit-def-subreg.ll 
(+384-366) 
- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage-agpr.ll (+3-3) 
- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage0.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage1.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage2.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage3.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/call-argument-types.ll (+1219-1461) 
- (modified) llvm/test/CodeGen/AMDGPU/call-waitcnt.ll (+42-47) 
- (modified) llvm/test/CodeGen/AMDGPU/callee-special-input-sgprs-fixed-abi.ll 
(+8-12) 
- (modified) llvm/test/CodeGen/AMDGPU/cc-update.ll (+144-160) 
- (modified) llvm/test/CodeGen/AMDGPU/cf-loop-on-constant.ll (+45-45) 
- (modified) llvm/test/CodeGen/AMDGPU/codegen-internal-only-func.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/collapse-endcf.ll (+10-10) 
- (modified) llvm/test/CodeGen/AMDGPU/cross-block-use-is-not-abi-copy.ll 
(+28-32) 
- (modified) llvm/test/CodeGen/AMDGPU/cvt_f32_ubyte.ll (+20-20) 
- (modified) llvm/test/CodeGen/AMDGPU/dagcombine-lshr-and-cmp.ll (+2-4) 
- (modified) llvm/test/CodeGen/AMDGPU/ds_read2.ll (+28-32) 
- (modified) llvm/test/CodeGen/AMDGPU/dwarf-multi-register-use-crash.ll (+6-6) 
- (modified) llvm/test/CodeGen/AMDGPU/elf-header-osabi.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/flat-scratch-init.ll (+17-19) 
- (modified) llvm/test/CodeGen/AMDGPU/fneg-fabs.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/gfx11-user-sgpr-init16-bug.ll (+19-12) 
- (modified) llvm/t

[clang] [AMDGPU] Make default AMDHSA Code Object Version to be 5 (PR #65410)

2023-09-12 Thread via cfe-commits


llvmbot wrote:

@llvm/pr-subscribers-clang


Changes

Also update LIT tests and docs.
For more details, see
https://llvm.org/docs/AMDGPUUsage.html#code-object-v5-metadata

Differential Revision: https://reviews.llvm.org/D129818
--

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

109 Files Affected:

- (modified) clang/include/clang/Driver/Options.td (+2-2) 
- (modified) clang/lib/Driver/ToolChains/CommonArgs.cpp (+1-1) 
- (modified) clang/test/CodeGenCUDA/amdgpu-code-object-version.cu (+1-1) 
- (modified) clang/test/CodeGenCUDA/amdgpu-workgroup-size.cu (+2-2) 
- (modified) clang/test/CodeGenHIP/default-attributes.hip (+2-2) 
- (modified) clang/test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl (+2-2) 
- (modified) clang/test/CodeGenOpenCL/builtins-amdgcn.cl (+5-5) 
- (modified) clang/test/Driver/hip-device-libs.hip (+8-8) 
- (modified) lld/test/ELF/emulation-amdgpu.s (+1-1) 
- (modified) lld/test/ELF/lto/amdgcn-oses.ll (+1-1) 
- (modified) llvm/docs/AMDGPUUsage.rst (+7-8) 
- (modified) llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp (+2-2) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/crash-stack-address-O0.ll 
(+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/dropped_debug_info_assert.ll 
(+28-29) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-assert-align.ll 
(+8-8) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-atomicrmw.ll 
(+2-2) 
- (modified) 
llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-abi-attribute-hints.ll 
(+53-55) 
- (modified) 
llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-implicit-args.ll 
(+468-484) 
- (modified) 
llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-return-values.ll 
(+1578-1623) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-sret.ll 
(+31-32) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call.ll 
(+2013-2077) 
- (modified) 
llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-constant-fold-vector-op.ll 
(+2-2) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-indirect-call.ll 
(+31-32) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-inline-asm.ll 
(+51-51) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-sibling-call.ll 
(+18-18) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-tail-call.ll 
(+2-2) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-addrspacecast.mir 
(+28-39) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.private.ll 
(+5-6) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.shared.ll 
(+5-6) 
- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/non-entry-alloca.ll (+7-4) 
- (modified) llvm/test/CodeGen/AMDGPU/abi-attribute-hints-undefined-behavior.ll 
(+75-35) 
- (modified) llvm/test/CodeGen/AMDGPU/addrspacecast-constantexpr.ll (+2-2) 
- (modified) llvm/test/CodeGen/AMDGPU/addrspacecast.gfx6.ll (+46-20) 
- (modified) llvm/test/CodeGen/AMDGPU/amdgpu-simplify-libcall-pow-codegen.ll 
(+30-30) 
- (modified) llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa-call.ll 
(+12-12) 
- (modified) llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa.ll (+8-7) 
- (modified) llvm/test/CodeGen/AMDGPU/attributor-noopt.ll (+1-1) 
- (modified) 
llvm/test/CodeGen/AMDGPU/blender-no-live-segment-at-def-implicit-def.ll 
(+22-24) 
- (modified) llvm/test/CodeGen/AMDGPU/branch-folding-implicit-def-subreg.ll 
(+384-366) 
- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage-agpr.ll (+3-3) 
- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage0.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage1.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage2.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage3.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/call-argument-types.ll (+1219-1461) 
- (modified) llvm/test/CodeGen/AMDGPU/call-waitcnt.ll (+42-47) 
- (modified) llvm/test/CodeGen/AMDGPU/callee-special-input-sgprs-fixed-abi.ll 
(+8-12) 
- (modified) llvm/test/CodeGen/AMDGPU/cc-update.ll (+144-160) 
- (modified) llvm/test/CodeGen/AMDGPU/cf-loop-on-constant.ll (+45-45) 
- (modified) llvm/test/CodeGen/AMDGPU/codegen-internal-only-func.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/collapse-endcf.ll (+10-10) 
- (modified) llvm/test/CodeGen/AMDGPU/cross-block-use-is-not-abi-copy.ll 
(+28-32) 
- (modified) llvm/test/CodeGen/AMDGPU/cvt_f32_ubyte.ll (+20-20) 
- (modified) llvm/test/CodeGen/AMDGPU/dagcombine-lshr-and-cmp.ll (+2-4) 
- (modified) llvm/test/CodeGen/AMDGPU/ds_read2.ll (+28-32) 
- (modified) llvm/test/CodeGen/AMDGPU/dwarf-multi-register-use-crash.ll (+6-6) 
- (modified) llvm/test/CodeGen/AMDGPU/elf-header-osabi.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/flat-scratch-init.ll (+17-19) 
- (modified) llvm/test/CodeGen/AMDGPU/fneg-fabs.ll (+1-1) 
- (modified) llvm/test/CodeGen/AMDGPU/gfx11-user-sgpr-init16-bug.ll (+19-12) 
- (modified) llvm/tes

[clang] [AMDGPU] Make default AMDHSA Code Object Version to be 5 (PR #65410)

2023-09-12 Thread via cfe-commits


llvmbot wrote:


>@llvm/pr-subscribers-lld-elf
>
>
>Changes
>
>Also update LIT tests and docs.
>For more details, see
>https://llvm.org/docs/AMDGPUUsage.html#code-object-v5-metadata
>
>Differential Revision: https://reviews.llvm.org/D129818
>--
>
>Patch is 1.92 MiB, truncated to 20.00 KiB below, full version: 
>https://github.com/llvm/llvm-project/pull/65410.diff
>
>109 Files Affected:
>
>- (modified) clang/include/clang/Driver/Options.td (+2-2) 
>- (modified) clang/lib/Driver/ToolChains/CommonArgs.cpp (+1-1) 
>- (modified) clang/test/CodeGenCUDA/amdgpu-code-object-version.cu (+1-1) 
>- (modified) clang/test/CodeGenCUDA/amdgpu-workgroup-size.cu (+2-2) 
>- (modified) clang/test/CodeGenHIP/default-attributes.hip (+2-2) 
>- (modified) clang/test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl (+2-2) 
>- (modified) clang/test/CodeGenOpenCL/builtins-amdgcn.cl (+5-5) 
>- (modified) clang/test/Driver/hip-device-libs.hip (+8-8) 
>- (modified) lld/test/ELF/emulation-amdgpu.s (+1-1) 
>- (modified) lld/test/ELF/lto/amdgcn-oses.ll (+1-1) 
>- (modified) llvm/docs/AMDGPUUsage.rst (+7-8) 
>- (modified) llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp (+2-2) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/crash-stack-address-O0.ll 
>(+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/dropped_debug_info_assert.ll 
>(+28-29) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-assert-align.ll 
>(+8-8) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-atomicrmw.ll 
>(+2-2) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-abi-attribute-hints.ll 
>(+53-55) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-implicit-args.ll 
>(+468-484) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-return-values.ll 
>(+1578-1623) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-sret.ll 
>(+31-32) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call.ll 
>(+2013-2077) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-constant-fold-vector-op.ll 
>(+2-2) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-indirect-call.ll 
>(+31-32) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-inline-asm.ll 
>(+51-51) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-sibling-call.ll 
>(+18-18) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-tail-call.ll 
>(+2-2) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-addrspacecast.mir 
>(+28-39) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.private.ll 
>(+5-6) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.shared.ll 
>(+5-6) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/non-entry-alloca.ll (+7-4) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/abi-attribute-hints-undefined-behavior.ll (+75-35) 
>- (modified) llvm/test/CodeGen/AMDGPU/addrspacecast-constantexpr.ll (+2-2) 
>- (modified) llvm/test/CodeGen/AMDGPU/addrspacecast.gfx6.ll (+46-20) 
>- (modified) llvm/test/CodeGen/AMDGPU/amdgpu-simplify-libcall-pow-codegen.ll 
>(+30-30) 
>- (modified) llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa-call.ll 
>(+12-12) 
>- (modified) llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa.ll (+8-7) 
>- (modified) llvm/test/CodeGen/AMDGPU/attributor-noopt.ll (+1-1) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/blender-no-live-segment-at-def-implicit-def.ll 
>(+22-24) 
>- (modified) llvm/test/CodeGen/AMDGPU/branch-folding-implicit-def-subreg.ll 
>(+384-366) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage-agpr.ll (+3-3) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage0.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage1.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage2.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage3.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-argument-types.ll (+1219-1461) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-waitcnt.ll (+42-47) 
>- (modified) llvm/test/CodeGen/AMDGPU/callee-special-input-sgprs-fixed-abi.ll 
>(+8-12) 
>- (modified) llvm/test/CodeGen/AMDGPU/cc-update.ll (+144-160) 
>- (modified) llvm/test/CodeGen/AMDGPU/cf-loop-on-constant.ll (+45-45) 
>- (modified) llvm/test/CodeGen/AMDGPU/codegen-internal-only-func.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/collapse-endcf.ll (+10-10) 
>- (modified) llvm/test/CodeGen/AMDGPU/cross-block-use-is-not-abi-copy.ll 
>(+28-32) 
>- (modified) llvm/test/CodeGen/AMDGPU/cvt_f32_ubyte.ll (+20-20) 
>- (modified) llvm/test/CodeGen/AMDGPU/dagcombine-lshr-and-cmp.ll (+2-4) 
>- (modified) llvm/test/CodeGen/AMDGPU/ds_read2.ll (+28-32) 
>- (modified) llvm/test/CodeGen/AMDGPU/dwarf-multi-register-use-crash.ll (+6-6) 
>- (modified) llvm/test/CodeGen/AMDGPU/elf-header-osabi.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/flat-scratch-init.ll (+17-19) 
>- (modified) llvm/test/CodeGen/AMDGPU/fneg-fabs.ll

[clang] [AMDGPU] Make default AMDHSA Code Object Version to be 5 (PR #65410)

2023-09-12 Thread via cfe-commits


llvmbot wrote:


>@llvm/pr-subscribers-clang
>
>
>Changes
>
>Also update LIT tests and docs.
>For more details, see
>https://llvm.org/docs/AMDGPUUsage.html#code-object-v5-metadata
>
>Differential Revision: https://reviews.llvm.org/D129818
>--
>
>Patch is 1.92 MiB, truncated to 20.00 KiB below, full version: 
>https://github.com/llvm/llvm-project/pull/65410.diff
>
>109 Files Affected:
>
>- (modified) clang/include/clang/Driver/Options.td (+2-2) 
>- (modified) clang/lib/Driver/ToolChains/CommonArgs.cpp (+1-1) 
>- (modified) clang/test/CodeGenCUDA/amdgpu-code-object-version.cu (+1-1) 
>- (modified) clang/test/CodeGenCUDA/amdgpu-workgroup-size.cu (+2-2) 
>- (modified) clang/test/CodeGenHIP/default-attributes.hip (+2-2) 
>- (modified) clang/test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl (+2-2) 
>- (modified) clang/test/CodeGenOpenCL/builtins-amdgcn.cl (+5-5) 
>- (modified) clang/test/Driver/hip-device-libs.hip (+8-8) 
>- (modified) lld/test/ELF/emulation-amdgpu.s (+1-1) 
>- (modified) lld/test/ELF/lto/amdgcn-oses.ll (+1-1) 
>- (modified) llvm/docs/AMDGPUUsage.rst (+7-8) 
>- (modified) llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp (+2-2) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/crash-stack-address-O0.ll 
>(+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/dropped_debug_info_assert.ll 
>(+28-29) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-assert-align.ll 
>(+8-8) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-atomicrmw.ll 
>(+2-2) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-abi-attribute-hints.ll 
>(+53-55) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-implicit-args.ll 
>(+468-484) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-return-values.ll 
>(+1578-1623) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-sret.ll 
>(+31-32) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call.ll 
>(+2013-2077) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-constant-fold-vector-op.ll 
>(+2-2) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-indirect-call.ll 
>(+31-32) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-inline-asm.ll 
>(+51-51) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-sibling-call.ll 
>(+18-18) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-tail-call.ll 
>(+2-2) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-addrspacecast.mir 
>(+28-39) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.private.ll 
>(+5-6) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.shared.ll 
>(+5-6) 
>- (modified) llvm/test/CodeGen/AMDGPU/GlobalISel/non-entry-alloca.ll (+7-4) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/abi-attribute-hints-undefined-behavior.ll (+75-35) 
>- (modified) llvm/test/CodeGen/AMDGPU/addrspacecast-constantexpr.ll (+2-2) 
>- (modified) llvm/test/CodeGen/AMDGPU/addrspacecast.gfx6.ll (+46-20) 
>- (modified) llvm/test/CodeGen/AMDGPU/amdgpu-simplify-libcall-pow-codegen.ll 
>(+30-30) 
>- (modified) llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa-call.ll 
>(+12-12) 
>- (modified) llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa.ll (+8-7) 
>- (modified) llvm/test/CodeGen/AMDGPU/attributor-noopt.ll (+1-1) 
>- (modified) 
>llvm/test/CodeGen/AMDGPU/blender-no-live-segment-at-def-implicit-def.ll 
>(+22-24) 
>- (modified) llvm/test/CodeGen/AMDGPU/branch-folding-implicit-def-subreg.ll 
>(+384-366) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage-agpr.ll (+3-3) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage0.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage1.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage2.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-alias-register-usage3.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-argument-types.ll (+1219-1461) 
>- (modified) llvm/test/CodeGen/AMDGPU/call-waitcnt.ll (+42-47) 
>- (modified) llvm/test/CodeGen/AMDGPU/callee-special-input-sgprs-fixed-abi.ll 
>(+8-12) 
>- (modified) llvm/test/CodeGen/AMDGPU/cc-update.ll (+144-160) 
>- (modified) llvm/test/CodeGen/AMDGPU/cf-loop-on-constant.ll (+45-45) 
>- (modified) llvm/test/CodeGen/AMDGPU/codegen-internal-only-func.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/collapse-endcf.ll (+10-10) 
>- (modified) llvm/test/CodeGen/AMDGPU/cross-block-use-is-not-abi-copy.ll 
>(+28-32) 
>- (modified) llvm/test/CodeGen/AMDGPU/cvt_f32_ubyte.ll (+20-20) 
>- (modified) llvm/test/CodeGen/AMDGPU/dagcombine-lshr-and-cmp.ll (+2-4) 
>- (modified) llvm/test/CodeGen/AMDGPU/ds_read2.ll (+28-32) 
>- (modified) llvm/test/CodeGen/AMDGPU/dwarf-multi-register-use-crash.ll (+6-6) 
>- (modified) llvm/test/CodeGen/AMDGPU/elf-header-osabi.ll (+1-1) 
>- (modified) llvm/test/CodeGen/AMDGPU/flat-scratch-init.ll (+17-19) 
>- (modified) llvm/test/CodeGen/AMDGPU/fneg-fabs.ll (

[clang] [AMDGPU] Make default AMDHSA Code Object Version to be 5 (PR #65410)

2023-09-12 Thread Saiyedul Islam via cfe-commits


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

[PATCH] D129818: AMDGPU: Make default AMDHSA Code Object Version to be 5

2023-09-12 Thread Phabricator via cfe-commits

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0a8d17e79b02: [AMDGPU] Make default AMDHSA Code Object 
Version to be 5 (#65410) (authored by saiislam, committed by GitHub 
).
Herald added a reviewer: jhenderson.
Herald added a reviewer: MaskRay.
Herald added projects: clang, OpenMP.
Herald added subscribers: openmp-commits, cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D129818?vs=530947&id=556533#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129818

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/CodeGenCUDA/amdgpu-code-object-version.cu
  clang/test/CodeGenCUDA/amdgpu-workgroup-size.cu
  clang/test/CodeGenHIP/default-attributes.hip
  clang/test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl
  clang/test/CodeGenOpenCL/builtins-amdgcn.cl
  clang/test/Driver/hip-device-libs.hip
  lld/test/ELF/emulation-amdgpu.s
  lld/test/ELF/lto/amdgcn-oses.ll
  llvm/docs/AMDGPUUsage.rst
  llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp
  llvm/test/CodeGen/AMDGPU/GlobalISel/crash-stack-address-O0.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/dropped_debug_info_assert.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-assert-align.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-atomicrmw.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-abi-attribute-hints.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-implicit-args.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-return-values.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-sret.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-constant-fold-vector-op.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-indirect-call.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-inline-asm.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-sibling-call.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-tail-call.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-addrspacecast.mir
  llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.private.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.shared.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/non-entry-alloca.ll
  llvm/test/CodeGen/AMDGPU/abi-attribute-hints-undefined-behavior.ll
  llvm/test/CodeGen/AMDGPU/addrspacecast-constantexpr.ll
  llvm/test/CodeGen/AMDGPU/addrspacecast.gfx6.ll
  llvm/test/CodeGen/AMDGPU/amdgpu-simplify-libcall-pow-codegen.ll
  llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa-call.ll
  llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa.ll
  llvm/test/CodeGen/AMDGPU/attributor-noopt.ll
  llvm/test/CodeGen/AMDGPU/blender-no-live-segment-at-def-implicit-def.ll
  llvm/test/CodeGen/AMDGPU/branch-folding-implicit-def-subreg.ll
  llvm/test/CodeGen/AMDGPU/call-alias-register-usage-agpr.ll
  llvm/test/CodeGen/AMDGPU/call-alias-register-usage0.ll
  llvm/test/CodeGen/AMDGPU/call-alias-register-usage1.ll
  llvm/test/CodeGen/AMDGPU/call-alias-register-usage2.ll
  llvm/test/CodeGen/AMDGPU/call-alias-register-usage3.ll
  llvm/test/CodeGen/AMDGPU/call-argument-types.ll
  llvm/test/CodeGen/AMDGPU/call-waitcnt.ll
  llvm/test/CodeGen/AMDGPU/callee-special-input-sgprs-fixed-abi.ll
  llvm/test/CodeGen/AMDGPU/cc-update.ll
  llvm/test/CodeGen/AMDGPU/cf-loop-on-constant.ll
  llvm/test/CodeGen/AMDGPU/codegen-internal-only-func.ll
  llvm/test/CodeGen/AMDGPU/collapse-endcf.ll
  llvm/test/CodeGen/AMDGPU/cross-block-use-is-not-abi-copy.ll
  llvm/test/CodeGen/AMDGPU/cvt_f32_ubyte.ll
  llvm/test/CodeGen/AMDGPU/dagcombine-lshr-and-cmp.ll
  llvm/test/CodeGen/AMDGPU/ds_read2.ll
  llvm/test/CodeGen/AMDGPU/dwarf-multi-register-use-crash.ll
  llvm/test/CodeGen/AMDGPU/elf-header-osabi.ll
  llvm/test/CodeGen/AMDGPU/flat-scratch-init.ll
  llvm/test/CodeGen/AMDGPU/fneg-fabs.ll
  llvm/test/CodeGen/AMDGPU/gfx11-user-sgpr-init16-bug.ll
  llvm/test/CodeGen/AMDGPU/global_atomics_scan_fadd.ll
  llvm/test/CodeGen/AMDGPU/global_atomics_scan_fmax.ll
  llvm/test/CodeGen/AMDGPU/global_atomics_scan_fmin.ll
  llvm/test/CodeGen/AMDGPU/global_atomics_scan_fsub.ll
  llvm/test/CodeGen/AMDGPU/indirect-addressing-term.ll
  llvm/test/CodeGen/AMDGPU/insert-delay-alu-bug.ll
  llvm/test/CodeGen/AMDGPU/kernel-vgpr-spill-mubuf-with-voffset.ll
  llvm/test/CodeGen/AMDGPU/lds-frame-extern.ll
  llvm/test/CodeGen/AMDGPU/lds-global-non-entry-func.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.is.private.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.is.shared.ll
  llvm/test/CodeGen/AMDGPU/llvm.dbg.value.ll
  llvm/test/CodeGen/AMDGPU/lower-kernargs.ll
  llvm/test/CodeGen/AMDGPU/lower-module-lds-via-hybrid.ll
  llvm/test/CodeGen/AMDGPU/lower-module-lds-via-table.ll
  llvm/test/CodeGen/AMDGPU/module-lds-false-sharin

[clang] [LLD][AARCH64] lld incorrectly handles .eh_frame when it has a non-zero offset within its output section. (PR #65966)

2023-09-12 Thread via cfe-commits



@@ -770,6 +770,9 @@ void AArch64::relocateAlloc(InputSectionBase &sec, uint8_t 
*buf) const {
   uint64_t secAddr = sec.getOutputSection()->addr;
   if (auto *s = dyn_cast(&sec))
 secAddr += s->outSecOff;
+  else if (auto *eh = dyn_cast(&sec))

simpal01 wrote:

i could not find the general way of fixing this without modifying 
target->relocateAlloc. 

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

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits


https://github.com/mzyKi updated 
https://github.com/llvm/llvm-project/pull/66041:

>From 18039e20fd8bbc97373eaec3f788eeb4e4b53194 Mon Sep 17 00:00:00 2001
From: miaozhiyuan 
Date: Tue, 12 Sep 2023 10:51:35 +0800
Subject: [PATCH] [clang] fix lack comparison of declRefExpr in
 ASTStructuralEquivalence

---
 clang/lib/AST/ASTStructuralEquivalence.cpp| 10 ++
 clang/unittests/AST/StructuralEquivalenceTest.cpp |  9 +
 2 files changed, 19 insertions(+)

diff --git a/clang/lib/AST/ASTStructuralEquivalence.cpp 
b/clang/lib/AST/ASTStructuralEquivalence.cpp
index 544420234ef0eb0..31c006a263fd7cd 100644
--- a/clang/lib/AST/ASTStructuralEquivalence.cpp
+++ b/clang/lib/AST/ASTStructuralEquivalence.cpp
@@ -214,6 +214,16 @@ class StmtComparer {
 return E1->size() == E2->size();
   }
 
+  bool IsStmtEquivalent(const DeclRefExpr *DRE1, const DeclRefExpr *DRE2) {
+auto *Decl1 = DRE1->getDecl();
+auto *Decl2 = DRE2->getDecl();
+if (!Decl1 || !Decl2) {
+  return false;
+}
+return IsStructurallyEquivalent(Context, const_cast(Decl1),
+const_cast(Decl2));
+  }
+
   bool IsStmtEquivalent(const DependentScopeDeclRefExpr *DE1,
 const DependentScopeDeclRefExpr *DE2) {
 if (!IsStructurallyEquivalent(Context, DE1->getDeclName(),
diff --git a/clang/unittests/AST/StructuralEquivalenceTest.cpp 
b/clang/unittests/AST/StructuralEquivalenceTest.cpp
index 4e9f476659b9ee6..5787fc5a6566617 100644
--- a/clang/unittests/AST/StructuralEquivalenceTest.cpp
+++ b/clang/unittests/AST/StructuralEquivalenceTest.cpp
@@ -2320,5 +2320,14 @@ TEST_F(StructuralEquivalenceStmtTest, UnresolvedLookup) {
   EXPECT_TRUE(testStructuralMatch(t));
 }
 
+TEST_F(StructuralEquivalenceStmtTest, DeclRefENoEq) {
+  std::string Prefix = "enum Test { AAA, BBB };";
+  auto t = makeStmts(
+  Prefix + "void foo(int i) {if (i > 0) {i = AAA;} else {i = BBB;}}",
+  Prefix + "void foo(int i) {if (i > 0) {i = BBB;} else {i = AAA;}}",
+  Lang_CXX03, ifStmt());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
 } // end namespace ast_matchers
 } // end namespace clang

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

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits


cor3ntin wrote:

You should edit `clang/docs/ReleaseNotes.rst`, indicating that 
https://github.com/llvm/llvm-project/issues/66047 was fixed, 
and edit the description of the PR with `Fixes #66047` so that it gets closed 
automatically.

Otherwise LGTM

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

[clang-tools-extra] [clang] [C23] Fix crash with _BitInt running clang-tidy (PR #65889)

2023-09-12 Thread Congcong Cai via cfe-commits


https://github.com/HerrCai0907 commented:

I wonder whether we should also add some test in clang/analysis module?
Crash happens in `StmtProfiler` but only add test case in clang-tidy level.

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

[clang-tools-extra] [clang] [C23] Fix crash with _BitInt running clang-tidy (PR #65889)

2023-09-12 Thread Congcong Cai via cfe-commits


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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Congcong Cai via cfe-commits


https://github.com/HerrCai0907 created 
https://github.com/llvm/llvm-project/pull/66055:

None

>From ed5150a69925dc3b6557796026a2820ac5c2e2f5 Mon Sep 17 00:00:00 2001
From: Congcong Cai 
Date: Tue, 12 Sep 2023 14:41:57 +0800
Subject: [PATCH] add

---
 .../bugprone/BugproneTidyModule.cpp   |  3 +
 .../clang-tidy/bugprone/CMakeLists.txt|  1 +
 ...arePointerToMemberVirtualFunctionCheck.cpp | 90 +++
 ...mparePointerToMemberVirtualFunctionCheck.h | 30 +++
 clang-tools-extra/docs/ReleaseNotes.rst   |  6 ++
 ...are-pointer-to-member-virtual-function.rst | 44 +
 .../docs/clang-tidy/checks/list.rst   |  1 +
 ...are-pointer-to-member-virtual-function.cpp | 73 +++
 8 files changed, 248 insertions(+)
 create mode 100644 
clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
 create mode 100644 
clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.h
 create mode 100644 
clang-tools-extra/docs/clang-tidy/checks/bugprone/compare-pointer-to-member-virtual-function.rst
 create mode 100644 
clang-tools-extra/test/clang-tidy/checkers/bugprone/compare-pointer-to-member-virtual-function.cpp

diff --git a/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp 
b/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
index a67a91eedd10482..543c522899d7a52 100644
--- a/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
@@ -16,6 +16,7 @@
 #include "BadSignalToKillThreadCheck.h"
 #include "BoolPointerImplicitConversionCheck.h"
 #include "BranchCloneCheck.h"
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
 #include "CopyConstructorInitCheck.h"
 #include "DanglingHandleCheck.h"
 #include "DynamicStaticInitializersCheck.h"
@@ -103,6 +104,8 @@ class BugproneModule : public ClangTidyModule {
 CheckFactories.registerCheck(
 "bugprone-bool-pointer-implicit-conversion");
 CheckFactories.registerCheck("bugprone-branch-clone");
+CheckFactories.registerCheck(
+"bugprone-compare-pointer-to-member-virtual-function");
 CheckFactories.registerCheck(
 "bugprone-copy-constructor-init");
 CheckFactories.registerCheck(
diff --git a/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
index 3c768021feb1502..0df9e439b715e5a 100644
--- a/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
@@ -11,6 +11,7 @@ add_clang_library(clangTidyBugproneModule
   BoolPointerImplicitConversionCheck.cpp
   BranchCloneCheck.cpp
   BugproneTidyModule.cpp
+  ComparePointerToMemberVirtualFunctionCheck.cpp
   CopyConstructorInitCheck.cpp
   DanglingHandleCheck.cpp
   DynamicStaticInitializersCheck.cpp
diff --git 
a/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
 
b/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
new file mode 100644
index 000..fed5825dfdbde23
--- /dev/null
+++ 
b/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
@@ -0,0 +1,90 @@
+//===--- ComparePointerToMemberVirtualFunctionCheck.cpp - clang-tidy 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/OperationKinds.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticIDs.h"
+#include "llvm/ADT/SmallVector.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::bugprone {
+
+// Matches a `UnaryOperator` whose operator is pre-increment:
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
+
+void ComparePointerToMemberVirtualFunctionCheck::registerMatchers(
+MatchFinder *Finder) {
+
+  auto DirectMemberPointer = unaryOperator(
+  allOf(hasOperatorName("&"),
+hasUnaryOperand(declRefExpr(to(cxxMethodDecl(isVirtual()));
+  auto IndirectMemberPointer = ignoringImpCasts(declRefExpr());
+
+  auto BinaryOperatorMatcher = [](auto &&Matcher) {
+return binaryOperator(allOf(hasAnyOperatorName("==", "!="),
+hasEitherOperand(hasType(memberPointerType(
+pointee(functionType(),
+hasEitherOperand(Matcher)),
+  unless(hasEitherO

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Congcong Cai via cfe-commits


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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Congcong Cai via cfe-commits


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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Congcong Cai via cfe-commits


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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Congcong Cai via cfe-commits


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

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits



@@ -214,6 +214,14 @@ class StmtComparer {
 return E1->size() == E2->size();
   }
 
+  bool IsStmtEquivalent(const DeclRefExpr *DRE1, const DeclRefExpr *DRE2) {
+if (nullptr == DRE1->getDecl() || nullptr == DRE2->getDecl()) {
+  return false;
+}
+return IsStructurallyEquivalent(Context, DRE1->getDecl()->getDeclName(),

mzyKi wrote:

Thanks for review, now I have taken your suggestions.When I develop in llvm 
13,```static bool IsStructurallyEquivalent(StructuralEquivalenceContext 
&Context,Decl *D1, Decl *D2)``` this function do not give me expected result. 
Maybe now this updated, I will find changes between two versions after

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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread via cfe-commits


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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread via cfe-commits


llvmbot wrote:

@llvm/pr-subscribers-clang-tidy


Changes

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

8 Files Affected:

- (modified) clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp (+3) 
- (modified) clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt (+1) 
- (added) 
clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
 (+90) 
- (added) 
clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.h
 (+30) 
- (modified) clang-tools-extra/docs/ReleaseNotes.rst (+6) 
- (added) 
clang-tools-extra/docs/clang-tidy/checks/bugprone/compare-pointer-to-member-virtual-function.rst
 (+44) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/list.rst (+1) 
- (added) 
clang-tools-extra/test/clang-tidy/checkers/bugprone/compare-pointer-to-member-virtual-function.cpp
 (+73) 



diff --git a/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp 
b/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
index a67a91eedd10482..543c522899d7a52 100644
--- a/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
@@ -16,6 +16,7 @@
 #include "BadSignalToKillThreadCheck.h"
 #include "BoolPointerImplicitConversionCheck.h"
 #include "BranchCloneCheck.h"
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
 #include "CopyConstructorInitCheck.h"
 #include "DanglingHandleCheck.h"
 #include "DynamicStaticInitializersCheck.h"
@@ -103,6 +104,8 @@ class BugproneModule : public ClangTidyModule {
 CheckFactories.registerCheck(
 "bugprone-bool-pointer-implicit-conversion");
 CheckFactories.registerCheck("bugprone-branch-clone");
+CheckFactories.registerCheck(
+"bugprone-compare-pointer-to-member-virtual-function");
 CheckFactories.registerCheck(
 "bugprone-copy-constructor-init");
 CheckFactories.registerCheck(
diff --git a/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
index 3c768021feb1502..0df9e439b715e5a 100644
--- a/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
@@ -11,6 +11,7 @@ add_clang_library(clangTidyBugproneModule
   BoolPointerImplicitConversionCheck.cpp
   BranchCloneCheck.cpp
   BugproneTidyModule.cpp
+  ComparePointerToMemberVirtualFunctionCheck.cpp
   CopyConstructorInitCheck.cpp
   DanglingHandleCheck.cpp
   DynamicStaticInitializersCheck.cpp
diff --git 
a/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
 
b/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
new file mode 100644
index 000..fed5825dfdbde23
--- /dev/null
+++ 
b/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
@@ -0,0 +1,90 @@
+//===--- ComparePointerToMemberVirtualFunctionCheck.cpp - clang-tidy 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/OperationKinds.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticIDs.h"
+#include "llvm/ADT/SmallVector.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::bugprone {
+
+// Matches a `UnaryOperator` whose operator is pre-increment:
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
+
+void ComparePointerToMemberVirtualFunctionCheck::registerMatchers(
+MatchFinder *Finder) {
+
+  auto DirectMemberPointer = unaryOperator(
+  allOf(hasOperatorName("&"),
+hasUnaryOperand(declRefExpr(to(cxxMethodDecl(isVirtual()));
+  auto IndirectMemberPointer = ignoringImpCasts(declRefExpr());
+
+  auto BinaryOperatorMatcher = [](auto &&Matcher) {
+return binaryOperator(allOf(hasAnyOperatorName("==", "!="),
+hasEitherOperand(hasType(memberPointerType(
+pointee(functionType(),
+hasEitherOperand(Matcher)),
+  unless(hasEitherOperand(
+  castExpr(hasCastKind(CK_NullToMemberPointer);
+  };
+
+  Finder->addMatcher(
+  BinaryOperatorMatcher(DirectMemberPointer).bind("direct_member_pointer"),
+  this);
+
+  Finder->addMatcher(BinaryOperatorMatcher(IndirectMemberPointer)
+ .bind("indirect_member_pointer")

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits


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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Congcong Cai via cfe-commits


https://github.com/HerrCai0907 updated 
https://github.com/llvm/llvm-project/pull/66055:

>From ed5150a69925dc3b6557796026a2820ac5c2e2f5 Mon Sep 17 00:00:00 2001
From: Congcong Cai 
Date: Tue, 12 Sep 2023 14:41:57 +0800
Subject: [PATCH 1/2] add

---
 .../bugprone/BugproneTidyModule.cpp   |  3 +
 .../clang-tidy/bugprone/CMakeLists.txt|  1 +
 ...arePointerToMemberVirtualFunctionCheck.cpp | 90 +++
 ...mparePointerToMemberVirtualFunctionCheck.h | 30 +++
 clang-tools-extra/docs/ReleaseNotes.rst   |  6 ++
 ...are-pointer-to-member-virtual-function.rst | 44 +
 .../docs/clang-tidy/checks/list.rst   |  1 +
 ...are-pointer-to-member-virtual-function.cpp | 73 +++
 8 files changed, 248 insertions(+)
 create mode 100644 
clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
 create mode 100644 
clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.h
 create mode 100644 
clang-tools-extra/docs/clang-tidy/checks/bugprone/compare-pointer-to-member-virtual-function.rst
 create mode 100644 
clang-tools-extra/test/clang-tidy/checkers/bugprone/compare-pointer-to-member-virtual-function.cpp

diff --git a/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp 
b/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
index a67a91eedd10482..543c522899d7a52 100644
--- a/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
@@ -16,6 +16,7 @@
 #include "BadSignalToKillThreadCheck.h"
 #include "BoolPointerImplicitConversionCheck.h"
 #include "BranchCloneCheck.h"
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
 #include "CopyConstructorInitCheck.h"
 #include "DanglingHandleCheck.h"
 #include "DynamicStaticInitializersCheck.h"
@@ -103,6 +104,8 @@ class BugproneModule : public ClangTidyModule {
 CheckFactories.registerCheck(
 "bugprone-bool-pointer-implicit-conversion");
 CheckFactories.registerCheck("bugprone-branch-clone");
+CheckFactories.registerCheck(
+"bugprone-compare-pointer-to-member-virtual-function");
 CheckFactories.registerCheck(
 "bugprone-copy-constructor-init");
 CheckFactories.registerCheck(
diff --git a/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
index 3c768021feb1502..0df9e439b715e5a 100644
--- a/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
@@ -11,6 +11,7 @@ add_clang_library(clangTidyBugproneModule
   BoolPointerImplicitConversionCheck.cpp
   BranchCloneCheck.cpp
   BugproneTidyModule.cpp
+  ComparePointerToMemberVirtualFunctionCheck.cpp
   CopyConstructorInitCheck.cpp
   DanglingHandleCheck.cpp
   DynamicStaticInitializersCheck.cpp
diff --git 
a/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
 
b/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
new file mode 100644
index 000..fed5825dfdbde23
--- /dev/null
+++ 
b/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
@@ -0,0 +1,90 @@
+//===--- ComparePointerToMemberVirtualFunctionCheck.cpp - clang-tidy 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/OperationKinds.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticIDs.h"
+#include "llvm/ADT/SmallVector.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::bugprone {
+
+// Matches a `UnaryOperator` whose operator is pre-increment:
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
+
+void ComparePointerToMemberVirtualFunctionCheck::registerMatchers(
+MatchFinder *Finder) {
+
+  auto DirectMemberPointer = unaryOperator(
+  allOf(hasOperatorName("&"),
+hasUnaryOperand(declRefExpr(to(cxxMethodDecl(isVirtual()));
+  auto IndirectMemberPointer = ignoringImpCasts(declRefExpr());
+
+  auto BinaryOperatorMatcher = [](auto &&Matcher) {
+return binaryOperator(allOf(hasAnyOperatorName("==", "!="),
+hasEitherOperand(hasType(memberPointerType(
+pointee(functionType(),
+hasEitherOperand(Matcher)),
+  unless(hasEitherOpe

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread via cfe-commits


llvmbot wrote:


>@llvm/pr-subscribers-clang-tidy
>
>
>Changes
>
>None
>--
>Full diff: https://github.com/llvm/llvm-project/pull/66055.diff
>
>8 Files Affected:
>
>- (modified) clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp (+3) 
>- (modified) clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt (+1) 
>- (added) 
>clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
> (+90) 
>- (added) 
>clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.h
> (+30) 
>- (modified) clang-tools-extra/docs/ReleaseNotes.rst (+6) 
>- (added) 
>clang-tools-extra/docs/clang-tidy/checks/bugprone/compare-pointer-to-member-virtual-function.rst
> (+44) 
>- (modified) clang-tools-extra/docs/clang-tidy/checks/list.rst (+1) 
>- (added) 
>clang-tools-extra/test/clang-tidy/checkers/bugprone/compare-pointer-to-member-virtual-function.cpp
> (+73) 
>
>
>
>diff --git a/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp 
>b/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
>index a67a91eedd10482..543c522899d7a52 100644
>--- a/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
>+++ b/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
>@@ -16,6 +16,7 @@
> #include "BadSignalToKillThreadCheck.h"
> #include "BoolPointerImplicitConversionCheck.h"
> #include "BranchCloneCheck.h"
>+#include "ComparePointerToMemberVirtualFunctionCheck.h"
> #include "CopyConstructorInitCheck.h"
> #include "DanglingHandleCheck.h"
> #include "DynamicStaticInitializersCheck.h"
>@@ -103,6 +104,8 @@ class BugproneModule : public ClangTidyModule {
> CheckFactories.registerCheck(
> "bugprone-bool-pointer-implicit-conversion");
> CheckFactories.registerCheck("bugprone-branch-clone");
>+CheckFactories.registerCheck(
>+"bugprone-compare-pointer-to-member-virtual-function");
> CheckFactories.registerCheck(
> "bugprone-copy-constructor-init");
> CheckFactories.registerCheck(
>diff --git a/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt 
>b/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
>index 3c768021feb1502..0df9e439b715e5a 100644
>--- a/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
>+++ b/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
>@@ -11,6 +11,7 @@ add_clang_library(clangTidyBugproneModule
>   BoolPointerImplicitConversionCheck.cpp
>   BranchCloneCheck.cpp
>   BugproneTidyModule.cpp
>+  ComparePointerToMemberVirtualFunctionCheck.cpp
>   CopyConstructorInitCheck.cpp
>   DanglingHandleCheck.cpp
>   DynamicStaticInitializersCheck.cpp
>diff --git 
>a/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
> 
>b/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
>new file mode 100644
>index 000..fed5825dfdbde23
>--- /dev/null
>+++ 
>b/clang-tools-extra/clang-tidy/bugprone/ComparePointerToMemberVirtualFunctionCheck.cpp
>@@ -0,0 +1,90 @@
>+//===--- ComparePointerToMemberVirtualFunctionCheck.cpp - clang-tidy 
>--===//
>+//
>+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
>Exceptions.
>+// See https://llvm.org/LICENSE.txt for license information.
>+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
>+//
>+//===--===//
>+
>+#include "ComparePointerToMemberVirtualFunctionCheck.h"
>+#include "clang/AST/ASTContext.h"
>+#include "clang/AST/ASTTypeTraits.h"
>+#include "clang/AST/DeclCXX.h"
>+#include "clang/AST/OperationKinds.h"
>+#include "clang/AST/Type.h"
>+#include "clang/ASTMatchers/ASTMatchFinder.h"
>+#include "clang/ASTMatchers/ASTMatchers.h"
>+#include "clang/ASTMatchers/ASTMatchersMacros.h"
>+#include "clang/Basic/Diagnostic.h"
>+#include "clang/Basic/DiagnosticIDs.h"
>+#include "llvm/ADT/SmallVector.h"
>+
>+using namespace clang::ast_matchers;
>+
>+namespace clang::tidy::bugprone {
>+
>+// Matches a `UnaryOperator` whose operator is pre-increment:
>+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
>+
>+void ComparePointerToMemberVirtualFunctionCheck::registerMatchers(
>+MatchFinder *Finder) {
>+
>+  auto DirectMemberPointer = unaryOperator(
>+  allOf(hasOperatorName("&"),
>+hasUnaryOperand(declRefExpr(to(cxxMethodDecl(isVirtual()));
>+  auto IndirectMemberPointer = ignoringImpCasts(declRefExpr());
>+
>+  auto BinaryOperatorMatcher = [](auto &&Matcher) {
>+return binaryOperator(allOf(hasAnyOperatorName("==", "!="),
>+hasEitherOperand(hasType(memberPointerType(
>+pointee(functionType(),
>+hasEitherOperand(Matcher)),
>+  unless(hasEitherOperand(
>+  
>castExpr(hasCastKind(CK_NullToMemberPointer);
>+  };
>+
>+  Finder->addMatcher(
>+  
>BinaryOperatorMatcher(DirectMemberPointer).bind("direct_member_pointer"),
>+  this

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits


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

[clang] [Documentation] Replace recommonmark by myst-parser (PR #65664)

2023-09-12 Thread Tobias Hieta via cfe-commits


tru wrote:

Instead of updating the module manually on the bot, I still think it's a good 
idea to add a requirements.txt that should be installed before running the 
build, ideally in a virtualenv. WDYT @andreil99 

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

[clang] [Driver] Also respect SysRoot for the system library paths on DragonFly (PR #66056)

2023-09-12 Thread Brad Smith via cfe-commits


https://github.com/brad0 created 
https://github.com/llvm/llvm-project/pull/66056:

None

>From df6d22fb217837a0b0d00b8905b077347fca6143 Mon Sep 17 00:00:00 2001
From: Brad Smith 
Date: Tue, 12 Sep 2023 04:43:49 -0400
Subject: [PATCH] [Driver] Also respect SysRoot for the system library paths on
 DragonFly

---
 clang/lib/Driver/ToolChains/DragonFly.cpp |  8 ---
 .../basic_dragonfly_tree/usr/lib/crt1.o   |  0
 .../basic_dragonfly_tree/usr/lib/crti.o   |  0
 .../basic_dragonfly_tree/usr/lib/crtn.o   |  0
 .../usr/lib/gcc80/crtbegin.o  |  0
 .../usr/lib/gcc80/crtbeginS.o |  0
 .../usr/lib/gcc80/crtend.o|  0
 .../usr/lib/gcc80/crtendS.o   |  0
 clang/test/Driver/dragonfly.c | 21 +++
 9 files changed, 26 insertions(+), 3 deletions(-)
 create mode 100644 clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crt1.o
 create mode 100644 clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crti.o
 create mode 100644 clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crtn.o
 create mode 100644 
clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbegin.o
 create mode 100644 
clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbeginS.o
 create mode 100644 
clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtend.o
 create mode 100644 
clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtendS.o

diff --git a/clang/lib/Driver/ToolChains/DragonFly.cpp 
b/clang/lib/Driver/ToolChains/DragonFly.cpp
index 46f98f9efca2330..82c975990a32511 100644
--- a/clang/lib/Driver/ToolChains/DragonFly.cpp
+++ b/clang/lib/Driver/ToolChains/DragonFly.cpp
@@ -123,7 +123,9 @@ void dragonfly::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 
   if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs,
options::OPT_r)) {
-CmdArgs.push_back("-L/usr/lib/gcc80");
+SmallString<128> Dir(D.SysRoot);
+llvm::sys::path::append(Dir, "/usr/lib/gcc80");
+CmdArgs.push_back(Args.MakeArgString("-L" + Dir));
 
 if (!Args.hasArg(options::OPT_static)) {
   CmdArgs.push_back("-rpath");
@@ -192,8 +194,8 @@ DragonFly::DragonFly(const Driver &D, const llvm::Triple 
&Triple,
 getProgramPaths().push_back(getDriver().Dir);
 
   getFilePaths().push_back(getDriver().Dir + "/../lib");
-  getFilePaths().push_back("/usr/lib");
-  getFilePaths().push_back("/usr/lib/gcc80");
+  getFilePaths().push_back(concat(getDriver().SysRoot, "/usr/lib"));
+  getFilePaths().push_back(concat(getDriver().SysRoot, "/usr/lib/gcc80"));
 }
 
 void DragonFly::AddClangSystemIncludeArgs(
diff --git a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crt1.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crt1.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crti.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crti.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crtn.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crtn.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbegin.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbegin.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbeginS.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbeginS.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtend.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtend.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtendS.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtendS.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git a/clang/test/Driver/dragonfly.c b/clang/test/Driver/dragonfly.c
index 477dbfe6abf43fa..a826addd7ef8015 100644
--- a/clang/test/Driver/dragonfly.c
+++ b/clang/test/Driver/dragonfly.c
@@ -4,6 +4,27 @@
 // CHECK: "-cc1" "-triple" "x86_64-pc-dragonfly"
 // CHECK: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" 
"/usr/libexec/ld-elf.so.{{.*}}" "--hash-style=gnu" "--enable-new-dtags" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" "{{.*}}.o" 
"-L{{.*}}gcc{{.*}}" "-rpath" "{{.*}}gcc{{.*}}" "-lc" "-lgcc" "{{.*}}crtend.o" 
"{{.*}}crtn.o"
 
+// Check x86_64-unknown-dragonfly, X86_64
+// RUN: %clang -### %s 2>&1 --target=x86_64-unknown-dragonfly \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/basic_dragonfly_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-X86_64 %s
+// CHECK-LD-X86_64: "-cc1" "-triple" "x86

[clang] [Driver] Also respect SysRoot for the system library paths on DragonFly (PR #66056)

2023-09-12 Thread Brad Smith via cfe-commits


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

[clang] [Driver] Also respect SysRoot for the system library paths on DragonFly (PR #66056)

2023-09-12 Thread via cfe-commits


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

[clang] [Driver] Also respect SysRoot for the system library paths on DragonFly (PR #66056)

2023-09-12 Thread via cfe-commits


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

[clang] [Driver] Also respect SysRoot for the system library paths on DragonFly (PR #66056)

2023-09-12 Thread via cfe-commits


llvmbot wrote:

@llvm/pr-subscribers-clang-driver


Changes

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

9 Files Affected:

- (modified) clang/lib/Driver/ToolChains/DragonFly.cpp (+5-3) 
- (added) clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crt1.o () 
- (added) clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crti.o () 
- (added) clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crtn.o () 
- (added) 
clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbegin.o () 
- (added) 
clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbeginS.o () 
- (added) clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtend.o 
() 
- (added) clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtendS.o 
() 
- (modified) clang/test/Driver/dragonfly.c (+21) 



diff --git a/clang/lib/Driver/ToolChains/DragonFly.cpp 
b/clang/lib/Driver/ToolChains/DragonFly.cpp
index 46f98f9efca2330..82c975990a32511 100644
--- a/clang/lib/Driver/ToolChains/DragonFly.cpp
+++ b/clang/lib/Driver/ToolChains/DragonFly.cpp
@@ -123,7 +123,9 @@ void dragonfly::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 
   if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs,
options::OPT_r)) {
-CmdArgs.push_back("-L/usr/lib/gcc80");
+SmallString<128> Dir(D.SysRoot);
+llvm::sys::path::append(Dir, "/usr/lib/gcc80");
+CmdArgs.push_back(Args.MakeArgString("-L" + Dir));
 
 if (!Args.hasArg(options::OPT_static)) {
   CmdArgs.push_back("-rpath");
@@ -192,8 +194,8 @@ DragonFly::DragonFly(const Driver &D, const llvm::Triple 
&Triple,
 getProgramPaths().push_back(getDriver().Dir);
 
   getFilePaths().push_back(getDriver().Dir + "/../lib");
-  getFilePaths().push_back("/usr/lib");
-  getFilePaths().push_back("/usr/lib/gcc80");
+  getFilePaths().push_back(concat(getDriver().SysRoot, "/usr/lib"));
+  getFilePaths().push_back(concat(getDriver().SysRoot, "/usr/lib/gcc80"));
 }
 
 void DragonFly::AddClangSystemIncludeArgs(
diff --git a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crt1.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crt1.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crti.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crti.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crtn.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crtn.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbegin.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbegin.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbeginS.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbeginS.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtend.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtend.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtendS.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtendS.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git a/clang/test/Driver/dragonfly.c b/clang/test/Driver/dragonfly.c
index 477dbfe6abf43fa..a826addd7ef8015 100644
--- a/clang/test/Driver/dragonfly.c
+++ b/clang/test/Driver/dragonfly.c
@@ -4,6 +4,27 @@
 // CHECK: "-cc1" "-triple" "x86_64-pc-dragonfly"
 // CHECK: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" 
"/usr/libexec/ld-elf.so.{{.*}}" "--hash-style=gnu" "--enable-new-dtags" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" "{{.*}}.o" 
"-L{{.*}}gcc{{.*}}" "-rpath" "{{.*}}gcc{{.*}}" "-lc" "-lgcc" "{{.*}}crtend.o" 
"{{.*}}crtn.o"
 
+// Check x86_64-unknown-dragonfly, X86_64
+// RUN: %clang -### %s 2>&1 --target=x86_64-unknown-dragonfly \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/basic_dragonfly_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-X86_64 %s
+// CHECK-LD-X86_64: "-cc1" "-triple" "x86_64-unknown-dragonfly"
+// CHECK-LD-X86_64-SAME: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-LD-X86_64: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD-X86_64-SAME: "[[SYSROOT]]/usr/lib/crt1.o"
+// CHECK-LD-X86_64-SAME: "[[SYSROOT]]/usr/lib/crti.o"
+// CHECK-LD-X86_64-SAME: "[[SYSROOT]]/usr/lib/gcc80/crtbegin.o"
+// CHECK-LD-X86_64-SAME: "-L[[SYSROOT]]/usr/lib/gcc80"
+// CHECK-LD-X86_64-SAME: "-rpath" "/usr/lib/gcc80"
+// CHECK-LD-X86_64-SAME: "-lc"
+// CHECK-LD-X86_64-SAME: "-lgcc"
+// CHECK-LD-X86_64-SAME: "--as-needed"
+// CHECK-LD-X86_64-SAME: "-lgcc_pic"
+// CHECK-LD-X86_64-SAME: "--no-as-needed"
+// CHECK-LD-X86_64-SAME: "[[SYSROOT]]/u

[clang] [Driver] Also respect SysRoot for the system library paths on DragonFly (PR #66056)

2023-09-12 Thread via cfe-commits


llvmbot wrote:

@llvm/pr-subscribers-clang


Changes

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

9 Files Affected:

- (modified) clang/lib/Driver/ToolChains/DragonFly.cpp (+5-3) 
- (added) clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crt1.o () 
- (added) clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crti.o () 
- (added) clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crtn.o () 
- (added) 
clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbegin.o () 
- (added) 
clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbeginS.o () 
- (added) clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtend.o 
() 
- (added) clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtendS.o 
() 
- (modified) clang/test/Driver/dragonfly.c (+21) 



diff --git a/clang/lib/Driver/ToolChains/DragonFly.cpp 
b/clang/lib/Driver/ToolChains/DragonFly.cpp
index 46f98f9efca2330..82c975990a32511 100644
--- a/clang/lib/Driver/ToolChains/DragonFly.cpp
+++ b/clang/lib/Driver/ToolChains/DragonFly.cpp
@@ -123,7 +123,9 @@ void dragonfly::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 
   if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs,
options::OPT_r)) {
-CmdArgs.push_back("-L/usr/lib/gcc80");
+SmallString<128> Dir(D.SysRoot);
+llvm::sys::path::append(Dir, "/usr/lib/gcc80");
+CmdArgs.push_back(Args.MakeArgString("-L" + Dir));
 
 if (!Args.hasArg(options::OPT_static)) {
   CmdArgs.push_back("-rpath");
@@ -192,8 +194,8 @@ DragonFly::DragonFly(const Driver &D, const llvm::Triple 
&Triple,
 getProgramPaths().push_back(getDriver().Dir);
 
   getFilePaths().push_back(getDriver().Dir + "/../lib");
-  getFilePaths().push_back("/usr/lib");
-  getFilePaths().push_back("/usr/lib/gcc80");
+  getFilePaths().push_back(concat(getDriver().SysRoot, "/usr/lib"));
+  getFilePaths().push_back(concat(getDriver().SysRoot, "/usr/lib/gcc80"));
 }
 
 void DragonFly::AddClangSystemIncludeArgs(
diff --git a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crt1.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crt1.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crti.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crti.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crtn.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/crtn.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbegin.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbegin.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbeginS.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtbeginS.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtend.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtend.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git 
a/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtendS.o 
b/clang/test/Driver/Inputs/basic_dragonfly_tree/usr/lib/gcc80/crtendS.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git a/clang/test/Driver/dragonfly.c b/clang/test/Driver/dragonfly.c
index 477dbfe6abf43fa..a826addd7ef8015 100644
--- a/clang/test/Driver/dragonfly.c
+++ b/clang/test/Driver/dragonfly.c
@@ -4,6 +4,27 @@
 // CHECK: "-cc1" "-triple" "x86_64-pc-dragonfly"
 // CHECK: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" 
"/usr/libexec/ld-elf.so.{{.*}}" "--hash-style=gnu" "--enable-new-dtags" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" "{{.*}}.o" 
"-L{{.*}}gcc{{.*}}" "-rpath" "{{.*}}gcc{{.*}}" "-lc" "-lgcc" "{{.*}}crtend.o" 
"{{.*}}crtn.o"
 
+// Check x86_64-unknown-dragonfly, X86_64
+// RUN: %clang -### %s 2>&1 --target=x86_64-unknown-dragonfly \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/basic_dragonfly_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-X86_64 %s
+// CHECK-LD-X86_64: "-cc1" "-triple" "x86_64-unknown-dragonfly"
+// CHECK-LD-X86_64-SAME: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-LD-X86_64: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD-X86_64-SAME: "[[SYSROOT]]/usr/lib/crt1.o"
+// CHECK-LD-X86_64-SAME: "[[SYSROOT]]/usr/lib/crti.o"
+// CHECK-LD-X86_64-SAME: "[[SYSROOT]]/usr/lib/gcc80/crtbegin.o"
+// CHECK-LD-X86_64-SAME: "-L[[SYSROOT]]/usr/lib/gcc80"
+// CHECK-LD-X86_64-SAME: "-rpath" "/usr/lib/gcc80"
+// CHECK-LD-X86_64-SAME: "-lc"
+// CHECK-LD-X86_64-SAME: "-lgcc"
+// CHECK-LD-X86_64-SAME: "--as-needed"
+// CHECK-LD-X86_64-SAME: "-lgcc_pic"
+// CHECK-LD-X86_64-SAME: "--no-as-needed"
+// CHECK-LD-X86_64-SAME: "[[SYSROOT]]/usr/lib/

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits


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

[PATCH] D126960: [clang][sema] Unary not boolean to int conversion

2023-09-12 Thread Ashley Roll via Phabricator via cfe-commits

AshleyRoll added a comment.

I've not been able to get the time for a while, I hope to be able to spend some 
more time on it, but I'd probably do that through a GitHub PR now.  If someone 
else wants to take it on, I'd be fine with that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126960

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

[PATCH] D152504: [clang][ThreadSafety] Analyze cleanup functions

2023-09-12 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder updated this revision to Diff 556535.
tbaeder marked 3 inline comments as done.

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

https://reviews.llvm.org/D152504

Files:
  clang/include/clang/Analysis/Analyses/ThreadSafetyCommon.h
  clang/lib/Analysis/ThreadSafety.cpp
  clang/lib/Analysis/ThreadSafetyCommon.cpp
  clang/test/Sema/warn-thread-safety-analysis.c

Index: clang/test/Sema/warn-thread-safety-analysis.c
===
--- clang/test/Sema/warn-thread-safety-analysis.c
+++ clang/test/Sema/warn-thread-safety-analysis.c
@@ -23,6 +23,7 @@
   __attribute__ ((shared_locks_required(__VA_ARGS__)))
 #define NO_THREAD_SAFETY_ANALYSIS  __attribute__ ((no_thread_safety_analysis))
 
+
 // Define the mutex struct.
 // Simplified only for test purpose.
 struct LOCKABLE Mutex {};
@@ -72,6 +73,8 @@
   return *p;
 }
 
+void unlock_scope(struct Mutex *const *mu) __attribute__((release_capability(**mu)));
+
 int main(void) {
 
   Foo_fun1(1); // expected-warning{{calling function 'Foo_fun1' requires holding mutex 'mu2'}} \
@@ -127,6 +130,13 @@
 // expected-note@-1{{mutex released here}}
   mutex_shared_unlock(&mu1);// expected-warning {{releasing mutex 'mu1' that was not held}}
 
+  /// Cleanup functions
+  {
+struct Mutex* const __attribute__((cleanup(unlock_scope))) scope = &mu1;
+mutex_exclusive_lock(scope);  // Note that we have to lock through scope, because no alias analysis!
+// Cleanup happens automatically -> no warning.
+  }
+
   return 0;
 }
 
Index: clang/lib/Analysis/ThreadSafetyCommon.cpp
===
--- clang/lib/Analysis/ThreadSafetyCommon.cpp
+++ clang/lib/Analysis/ThreadSafetyCommon.cpp
@@ -110,7 +110,8 @@
 /// \param D   The declaration to which the attribute is attached.
 /// \param DeclExp An expression involving the Decl to which the attribute
 ///is attached.  E.g. the call to a function.
-/// \param SelfS-expression to substitute for a \ref CXXThisExpr.
+/// \param SelfS-expression to substitute for a \ref CXXThisExpr in a call,
+///or argument to a cleanup function.
 CapabilityExpr SExprBuilder::translateAttrExpr(const Expr *AttrExp,
const NamedDecl *D,
const Expr *DeclExp,
@@ -144,7 +145,11 @@
 
   if (Self) {
 assert(!Ctx.SelfArg && "Ambiguous self argument");
-Ctx.SelfArg = Self;
+assert(isa(D) && "Self argument requires function");
+if (isa(D))
+  Ctx.SelfArg = Self;
+else
+  Ctx.FunArgs = Self;
 
 // If the attribute has no arguments, then assume the argument is "this".
 if (!AttrExp)
@@ -312,8 +317,14 @@
   ? (cast(D)->getCanonicalDecl() == Canonical)
   : (cast(D)->getCanonicalDecl() == Canonical)) {
 // Substitute call arguments for references to function parameters
-assert(I < Ctx->NumArgs);
-return translate(Ctx->FunArgs[I], Ctx->Prev);
+if (const Expr *const *FunArgs =
+Ctx->FunArgs.dyn_cast()) {
+  assert(I < Ctx->NumArgs);
+  return translate(FunArgs[I], Ctx->Prev);
+}
+
+assert(I == 0);
+return Ctx->FunArgs.get();
   }
 }
 // Map the param back to the param of the original function declaration
Index: clang/lib/Analysis/ThreadSafety.cpp
===
--- clang/lib/Analysis/ThreadSafety.cpp
+++ clang/lib/Analysis/ThreadSafety.cpp
@@ -2414,6 +2414,15 @@
 AD.getTriggerStmt()->getEndLoc());
   break;
 }
+
+case CFGElement::CleanupFunction: {
+  const CFGCleanupFunction &CF = BI.castAs();
+  LocksetBuilder.handleCall(/*Exp=*/nullptr, CF.getFunctionDecl(),
+SxBuilder.createVariable(CF.getVarDecl()),
+CF.getVarDecl()->getLocation());
+  break;
+}
+
 case CFGElement::TemporaryDtor: {
   auto TD = BI.castAs();
 
Index: clang/include/clang/Analysis/Analyses/ThreadSafetyCommon.h
===
--- clang/include/clang/Analysis/Analyses/ThreadSafetyCommon.h
+++ clang/include/clang/Analysis/Analyses/ThreadSafetyCommon.h
@@ -361,7 +361,7 @@
 unsigned NumArgs = 0;
 
 // Function arguments
-const Expr *const *FunArgs = nullptr;
+llvm::PointerUnion FunArgs = nullptr;
 
 // is Self referred to with -> or .?
 bool SelfArrow = false;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Piotr Zegar via cfe-commits



@@ -0,0 +1,89 @@
+//===--- ComparePointerToMemberVirtualFunctionCheck.cpp - clang-tidy 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/OperationKinds.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticIDs.h"
+#include "llvm/ADT/SmallVector.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::bugprone {
+
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }

PiotrZSL wrote:

Put into anonymous namespace to avoid ODR issues

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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Piotr Zegar via cfe-commits



@@ -0,0 +1,89 @@
+//===--- ComparePointerToMemberVirtualFunctionCheck.cpp - clang-tidy 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/OperationKinds.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticIDs.h"
+#include "llvm/ADT/SmallVector.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::bugprone {
+
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
+
+void ComparePointerToMemberVirtualFunctionCheck::registerMatchers(
+MatchFinder *Finder) {
+
+  auto DirectMemberPointer = unaryOperator(
+  allOf(hasOperatorName("&"),
+hasUnaryOperand(declRefExpr(to(cxxMethodDecl(isVirtual()));
+  auto IndirectMemberPointer = ignoringImpCasts(declRefExpr());
+
+  auto BinaryOperatorMatcher = [](auto &&Matcher) {

PiotrZSL wrote:

Avoid matching same thing twice, this can be writeln as:
```
binaryOperator(hasAnyOperatorName("==", "!="),
   
hasEitherOperand(hasType(memberPointerType(pointee(functionType(),
   
anyOf(binaryOperator(hasEitherOperand(DirectMemberPointer)).bind("direct_member_pointer"),
 
binaryOperator(hasEitherOperand(IndirectMemberPointer)).bind("indirect_member_pointer")),
   
unless(hasEitherOperand(castExpr(hasCastKind(CK_NullToMemberPointer
  )
```

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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Piotr Zegar via cfe-commits



@@ -0,0 +1,89 @@
+//===--- ComparePointerToMemberVirtualFunctionCheck.cpp - clang-tidy 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/OperationKinds.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticIDs.h"
+#include "llvm/ADT/SmallVector.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::bugprone {
+
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
+
+void ComparePointerToMemberVirtualFunctionCheck::registerMatchers(
+MatchFinder *Finder) {
+
+  auto DirectMemberPointer = unaryOperator(
+  allOf(hasOperatorName("&"),
+hasUnaryOperand(declRefExpr(to(cxxMethodDecl(isVirtual()));
+  auto IndirectMemberPointer = ignoringImpCasts(declRefExpr());
+
+  auto BinaryOperatorMatcher = [](auto &&Matcher) {
+return binaryOperator(allOf(hasAnyOperatorName("==", "!="),
+hasEitherOperand(hasType(memberPointerType(
+pointee(functionType(),
+hasEitherOperand(Matcher)),
+  unless(hasEitherOperand(
+  castExpr(hasCastKind(CK_NullToMemberPointer);
+  };
+
+  Finder->addMatcher(
+  BinaryOperatorMatcher(DirectMemberPointer).bind("direct_member_pointer"),
+  this);
+
+  Finder->addMatcher(BinaryOperatorMatcher(IndirectMemberPointer)
+ .bind("indirect_member_pointer"),
+ this);
+}
+
+static const char *const ErrorMsg =
+"A pointer to member virtual function shall only be tested for equality "
+"with null-pointer-constant.";
+
+static const Expr *removeImplicitCast(const Expr *E) {

PiotrZSL wrote:

Looks like 
E->[IgnoreImpCasts](https://clang.llvm.org/doxygen/classclang_1_1Expr.html#a9bc38e2b86894a980f9663076a180907)
 ()

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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Piotr Zegar via cfe-commits



@@ -0,0 +1,89 @@
+//===--- ComparePointerToMemberVirtualFunctionCheck.cpp - clang-tidy 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/OperationKinds.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticIDs.h"
+#include "llvm/ADT/SmallVector.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::bugprone {
+
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
+
+void ComparePointerToMemberVirtualFunctionCheck::registerMatchers(
+MatchFinder *Finder) {
+
+  auto DirectMemberPointer = unaryOperator(
+  allOf(hasOperatorName("&"),
+hasUnaryOperand(declRefExpr(to(cxxMethodDecl(isVirtual()));
+  auto IndirectMemberPointer = ignoringImpCasts(declRefExpr());
+
+  auto BinaryOperatorMatcher = [](auto &&Matcher) {
+return binaryOperator(allOf(hasAnyOperatorName("==", "!="),
+hasEitherOperand(hasType(memberPointerType(
+pointee(functionType(),
+hasEitherOperand(Matcher)),
+  unless(hasEitherOperand(
+  castExpr(hasCastKind(CK_NullToMemberPointer);
+  };
+
+  Finder->addMatcher(
+  BinaryOperatorMatcher(DirectMemberPointer).bind("direct_member_pointer"),
+  this);
+
+  Finder->addMatcher(BinaryOperatorMatcher(IndirectMemberPointer)
+ .bind("indirect_member_pointer"),
+ this);
+}
+
+static const char *const ErrorMsg =
+"A pointer to member virtual function shall only be tested for equality "
+"with null-pointer-constant.";
+
+static const Expr *removeImplicitCast(const Expr *E) {
+  while (const auto *ICE = dyn_cast(E))
+E = ICE->getSubExpr();
+  return E;
+}
+
+void ComparePointerToMemberVirtualFunctionCheck::check(
+const MatchFinder::MatchResult &Result) {
+  if (const auto *DirectCompare =
+  Result.Nodes.getNodeAs("direct_member_pointer")) {
+diag(DirectCompare->getOperatorLoc(), ErrorMsg);
+  } else if (const auto *IndirectCompare =

PiotrZSL wrote:

no need for else, just put return

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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Piotr Zegar via cfe-commits



@@ -0,0 +1,89 @@
+//===--- ComparePointerToMemberVirtualFunctionCheck.cpp - clang-tidy 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/OperationKinds.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticIDs.h"
+#include "llvm/ADT/SmallVector.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::bugprone {
+
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
+
+void ComparePointerToMemberVirtualFunctionCheck::registerMatchers(
+MatchFinder *Finder) {
+
+  auto DirectMemberPointer = unaryOperator(
+  allOf(hasOperatorName("&"),
+hasUnaryOperand(declRefExpr(to(cxxMethodDecl(isVirtual()));
+  auto IndirectMemberPointer = ignoringImpCasts(declRefExpr());
+
+  auto BinaryOperatorMatcher = [](auto &&Matcher) {
+return binaryOperator(allOf(hasAnyOperatorName("==", "!="),
+hasEitherOperand(hasType(memberPointerType(
+pointee(functionType(),
+hasEitherOperand(Matcher)),
+  unless(hasEitherOperand(
+  castExpr(hasCastKind(CK_NullToMemberPointer);
+  };
+
+  Finder->addMatcher(
+  BinaryOperatorMatcher(DirectMemberPointer).bind("direct_member_pointer"),
+  this);
+
+  Finder->addMatcher(BinaryOperatorMatcher(IndirectMemberPointer)
+ .bind("indirect_member_pointer"),
+ this);
+}
+
+static const char *const ErrorMsg =
+"A pointer to member virtual function shall only be tested for equality "
+"with null-pointer-constant.";
+
+static const Expr *removeImplicitCast(const Expr *E) {
+  while (const auto *ICE = dyn_cast(E))
+E = ICE->getSubExpr();
+  return E;
+}
+
+void ComparePointerToMemberVirtualFunctionCheck::check(
+const MatchFinder::MatchResult &Result) {
+  if (const auto *DirectCompare =
+  Result.Nodes.getNodeAs("direct_member_pointer")) {
+diag(DirectCompare->getOperatorLoc(), ErrorMsg);
+  } else if (const auto *IndirectCompare =
+ Result.Nodes.getNodeAs(
+ "indirect_member_pointer")) {
+const Expr *E = removeImplicitCast(IndirectCompare->getLHS());
+if (!isa(E))
+  E = removeImplicitCast(IndirectCompare->getRHS());
+const auto *MPT = cast(E->getType().getCanonicalType());
+llvm::SmallVector SameSignatureVirtualMethods{};
+for (const auto *D : MPT->getClass()->getAsCXXRecordDecl()->decls())

PiotrZSL wrote:

what if getAsCXXRecordDecl or getClass will return nullptr ?

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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Piotr Zegar via cfe-commits



@@ -0,0 +1,29 @@
+//===--- ComparePointerToMemberVirtualFunctionCheck.h - clang-tidy *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef 
LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_BUGPRONE_COMPAREPOINTERTOMEMBERVIRTUALFUNCTIONCHECK_H
+#define 
LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_BUGPRONE_COMPAREPOINTERTOMEMBERVIRTUALFUNCTIONCHECK_H
+
+#include "../ClangTidyCheck.h"
+
+namespace clang::tidy::bugprone {
+
+/// [expr.eq] If either is a pointer to a virtual member function, the result 
is unspecified.
+/// For the user-facing documentation see:
+/// 
http://clang.llvm.org/extra/clang-tidy/checks/bugprone/compare-pointer-to-member-virtual-function.html
+class ComparePointerToMemberVirtualFunctionCheck : public ClangTidyCheck {
+public:
+  ComparePointerToMemberVirtualFunctionCheck(StringRef Name, ClangTidyContext 
*Context)
+  : ClangTidyCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult &Result) override;

PiotrZSL wrote:

Specify supported language and traversal mode (like in other checks), consider 
using TK_IgnoreUnlessSpelledInSource to skip implicit code (may also skip 
template instances).

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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Piotr Zegar via cfe-commits



@@ -0,0 +1,29 @@
+//===--- ComparePointerToMemberVirtualFunctionCheck.h - clang-tidy *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef 
LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_BUGPRONE_COMPAREPOINTERTOMEMBERVIRTUALFUNCTIONCHECK_H
+#define 
LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_BUGPRONE_COMPAREPOINTERTOMEMBERVIRTUALFUNCTIONCHECK_H
+
+#include "../ClangTidyCheck.h"
+
+namespace clang::tidy::bugprone {
+
+/// [expr.eq] If either is a pointer to a virtual member function, the result 
is unspecified.

PiotrZSL wrote:

Should be in sync with release notes and documentation: "Detects unspecified 
behavior about equality comparison between pointer to member virtual function 
and anything other than null-pointer-constant."

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

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits


https://github.com/mzyKi updated 
https://github.com/llvm/llvm-project/pull/66041:

>From 0ddd5dbb2e2a9097e762334a0d903e4043721cc2 Mon Sep 17 00:00:00 2001
From: miaozhiyuan 
Date: Tue, 12 Sep 2023 10:51:35 +0800
Subject: [PATCH] [clang] fix lack comparison of declRefExpr in
 ASTStructuralEquivalence

---
 clang/docs/ReleaseNotes.rst   |  2 ++
 clang/lib/AST/ASTStructuralEquivalence.cpp| 10 ++
 clang/unittests/AST/StructuralEquivalenceTest.cpp |  9 +
 3 files changed, 21 insertions(+)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index cc8b2c3808933cb..7a3c573f4f25500 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -218,6 +218,8 @@ Bug Fixes in This Version
   (`#65156 `_`)
 - Clang no longer considers the loss of ``__unaligned`` qualifier from objects 
as
   an invalid conversion during method function overload resolution.
+- Fix lack of comparison of declRefExpr in ASTStructuralEquivalence
+  (`#66047 `_`)
 
 Bug Fixes to Compiler Builtins
 ^^
diff --git a/clang/lib/AST/ASTStructuralEquivalence.cpp 
b/clang/lib/AST/ASTStructuralEquivalence.cpp
index 544420234ef0eb0..31c006a263fd7cd 100644
--- a/clang/lib/AST/ASTStructuralEquivalence.cpp
+++ b/clang/lib/AST/ASTStructuralEquivalence.cpp
@@ -214,6 +214,16 @@ class StmtComparer {
 return E1->size() == E2->size();
   }
 
+  bool IsStmtEquivalent(const DeclRefExpr *DRE1, const DeclRefExpr *DRE2) {
+auto *Decl1 = DRE1->getDecl();
+auto *Decl2 = DRE2->getDecl();
+if (!Decl1 || !Decl2) {
+  return false;
+}
+return IsStructurallyEquivalent(Context, const_cast(Decl1),
+const_cast(Decl2));
+  }
+
   bool IsStmtEquivalent(const DependentScopeDeclRefExpr *DE1,
 const DependentScopeDeclRefExpr *DE2) {
 if (!IsStructurallyEquivalent(Context, DE1->getDeclName(),
diff --git a/clang/unittests/AST/StructuralEquivalenceTest.cpp 
b/clang/unittests/AST/StructuralEquivalenceTest.cpp
index 4e9f476659b9ee6..5787fc5a6566617 100644
--- a/clang/unittests/AST/StructuralEquivalenceTest.cpp
+++ b/clang/unittests/AST/StructuralEquivalenceTest.cpp
@@ -2320,5 +2320,14 @@ TEST_F(StructuralEquivalenceStmtTest, UnresolvedLookup) {
   EXPECT_TRUE(testStructuralMatch(t));
 }
 
+TEST_F(StructuralEquivalenceStmtTest, DeclRefENoEq) {
+  std::string Prefix = "enum Test { AAA, BBB };";
+  auto t = makeStmts(
+  Prefix + "void foo(int i) {if (i > 0) {i = AAA;} else {i = BBB;}}",
+  Prefix + "void foo(int i) {if (i > 0) {i = BBB;} else {i = AAA;}}",
+  Lang_CXX03, ifStmt());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
 } // end namespace ast_matchers
 } // end namespace clang

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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Piotr Zegar via cfe-commits


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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Piotr Zegar via cfe-commits


https://github.com/PiotrZSL commented:

Not bad, just basic nits.

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

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits


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

[PATCH] D158156: [analyzer] Add C++ array delete checker

2023-09-12 Thread Donát Nagy via Phabricator via cfe-commits

donat.nagy added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/CXXDeleteChecker.cpp:47
+protected:
+  class PtrCastVisitor : public BugReporterVisitor {
   public:

I like that yo switched to a more descriptive class name :)



Comment at: clang/test/Analysis/ArrayDelete.cpp:85-88
+Derived *d3 = new DoubleDerived[10];
+Base *b3 = d3; // expected-note{{Conversion from derived to base happened 
here}}
+delete[] b3; // expected-warning{{Deleting an array of polymorphic objects 
is undefined}}
+// expected-note@-1{{Deleting an array of polymorphic objects is 
undefined}}

steakhal wrote:
> Hmm, the static type of `d3` doesn't tell us much about how it refers to an 
> object of type `DoubleDerived`.
> To me, it would make sense to have multiple `Conversion from derived to base 
> happened here`, even telling us what static type it converted to what other 
> static type in the message.
> And it should add a new visitor of the same kind tracking the castee.
> 
> ```
> Derived *d3 = new DoubleDerived[10]; // note: `DoubleDerived` -> `Derived` 
> here
> Base *b3 = d3; // note: `Derived` -> `Base` here
> delete[] b3; // warn: Deleting `Derived` objects as `Base` objects.
> ```
> WDYT @donat.nagy ?
I agree that it would be good to be good to mention the class names in the 
message.



Comment at: clang/test/Analysis/ArrayDelete.cpp:90-93
+Base *b4 = new DoubleDerived[10];
+Derived *d4 = reinterpret_cast(b4);
+DoubleDerived *dd4 = reinterpret_cast(d4);
+delete[] dd4; // no-warning

steakhal wrote:
> I think in such cases a `static_cast` should suffice; unless you 
> intentionally wanted to test `reinterpret_cast` of course.
Note that the effects of `reinterpret_cast` and `static_cast` are different 
[1]: `static_cast(BasePtr)` adjusts the pointer value to ensure that 
it points to the derived object whose Base ancestor object would be located at 
BasePtr, while a `reinterpret_cast` keeps the raw pointer value (which is 
complete nonsense from an object-oriented point-of-view, but could be relevant 
in some low-level hacks).

I'd guess that this part is directly testing the strange behavior of 
`reinterpret_cast`; but it'd be good to add a comment that clarifies this.

[1]: 
https://stackoverflow.com/questions/9138730/why-is-it-important-to-use-static-cast-instead-of-reinterpret-cast-here


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

https://reviews.llvm.org/D158156

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

[clang] [clang][dataflow] Remove RecordValue.getLog() usage in HTMLLogger (PR #65645)

2023-09-12 Thread via cfe-commits


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

[clang] e791535 - [clang][dataflow] Remove RecordValue.getLog() usage in HTMLLogger (#65645)

2023-09-12 Thread via cfe-commits


Author: Kinuko Yasuda
Date: 2023-09-12T11:25:40+02:00
New Revision: e791535b1333898abef0d30cbccce8c788006414

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

LOG: [clang][dataflow] Remove RecordValue.getLog() usage in HTMLLogger (#65645)

We can dump the same information from RecordStorageLocation.

Tested the behavior before and after patch, that generates the field
values in the HTML
in both cases (and also made sure that removing the relevant code makes
the field values
in the HTML go away)

Added: 


Modified: 
clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp

Removed: 




diff  --git a/clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp 
b/clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp
index b1bfe10db202435..a5f64021eb6ba4b 100644
--- a/clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp
+++ b/clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp
@@ -95,6 +95,7 @@ class ModelDumper {
 
 switch (V.getKind()) {
 case Value::Kind::Integer:
+case Value::Kind::Record:
 case Value::Kind::TopBool:
 case Value::Kind::AtomicBool:
 case Value::Kind::FormulaBool:
@@ -103,14 +104,6 @@ class ModelDumper {
   JOS.attributeObject(
   "pointee", [&] { dump(cast(V).getPointeeLoc()); });
   break;
-case Value::Kind::Record:
-  for (const auto &Child : cast(V).getLoc().children())
-JOS.attributeObject("f:" + Child.first->getNameAsString(), [&] {
-  if (Child.second)
-if (Value *Val = Env.getValue(*Child.second))
-  dump(*Val);
-});
-  break;
 }
 
 for (const auto& Prop : V.properties())
@@ -136,6 +129,15 @@ class ModelDumper {
 JOS.attribute("type", L.getType().getAsString());
 if (auto *V = Env.getValue(L))
   dump(*V);
+
+if (auto *RLoc = dyn_cast(&L)) {
+  for (const auto &Child : RLoc->children())
+JOS.attributeObject("f:" + Child.first->getNameAsString(), [&] {
+  if (Child.second)
+if (Value *Val = Env.getValue(*Child.second))
+  dump(*Val);
+});
+}
   }
 
   llvm::DenseSet Visited;



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

[clang-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

2023-09-12 Thread Congcong Cai via cfe-commits



@@ -0,0 +1,89 @@
+//===--- ComparePointerToMemberVirtualFunctionCheck.cpp - clang-tidy 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "ComparePointerToMemberVirtualFunctionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/OperationKinds.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticIDs.h"
+#include "llvm/ADT/SmallVector.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::bugprone {
+
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
+
+void ComparePointerToMemberVirtualFunctionCheck::registerMatchers(
+MatchFinder *Finder) {
+
+  auto DirectMemberPointer = unaryOperator(
+  allOf(hasOperatorName("&"),
+hasUnaryOperand(declRefExpr(to(cxxMethodDecl(isVirtual()));
+  auto IndirectMemberPointer = ignoringImpCasts(declRefExpr());
+
+  auto BinaryOperatorMatcher = [](auto &&Matcher) {

HerrCai0907 wrote:

binaryOperator duplicate in this matcher. Is there any way to get parent node 
in later check? Then I can bind to operand and get operator location?

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

[clang] [clang] fix lack comparison of declRefExpr in ASTStructuralEquivalence (PR #66041)

2023-09-12 Thread via cfe-commits


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

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

2023-09-12 Thread David Spickett via cfe-commits



@@ -0,0 +1,548 @@
+Pointer Authentication
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic 
protection against exploiting a broad class of memory bugs to take control of 
program execution.  When adopted consistently in a language ABI, it provides a 
form of relatively fine-grained control flow integrity (CFI) check that resists 
both return-oriented programming (ROP) and jump-oriented programming (JOP) 
attacks.
+
+While pointer authentication can be implemented purely in software, direct 
hardware support (e.g. as provided by ARMv8.3) can dramatically lower the 
execution speed and code size costs.  Similarly, while pointer authentication 
can be implemented on any architecture, taking advantage of the (typically) 
excess addressing range of a target with 64-bit pointers minimizes the impact 
on memory performance and can allow interoperation with existing code (by 
disabling pointer authentication dynamically).  This document will generally 
attempt to present the pointer authentication feature independent of any 
hardware implementation or ABI.  Considerations that are 
implementation-specific are clearly identified throughout.
+
+Note that there are several different terms in use:
+
+- **Pointer authentication** is a target-independent language technology.
+
+- **ARMv8.3** is an AArch64 architecture revision of that provides hardware 
support for pointer authentication.  It is implemented on several shipping 
processors, including the Apple A12 and later.
+
+* **arm64e** is a specific ABI for (not yet fully stable) for implementing 
pointer authentication on ARMv8.3 on certain Apple operating systems.
+
+This document serves four purposes:
+
+- It describes the basic ideas of pointer authentication.
+
+- It documents several language extensions that are useful on targets using 
pointer authentication.
+
+- It presents a theory of operation for the security mitigation, describing 
the basic requirements for correctness, various weaknesses in the mechanism, 
and ways in which programmers can strengthen its protections (including 
recommendations for language implementors).
+
+- It will eventually document the language ABIs currently used for C, C++, 
Objective-C, and Swift on arm64e, although these are not yet stable on any 
target.
+
+Basic Concepts
+--
+
+The simple address of an object or function is a **raw pointer**.  A raw 
pointer can be **signed** to produce a **signed pointer**.  A signed pointer 
can be then **authenticated** in order to verify that it was **validly signed** 
and extract the original raw pointer.  These terms reflect the most likely 
implementation technique: computing and storing a cryptographic signature along 
with the pointer.  The security of pointer authentication does not rely on 
attackers not being able to separately overwrite the signature.
+
+An **abstract signing key** is a name which refers to a secret key which can 
used to sign and authenticate pointers.  The key value for a particular name is 
consistent throughout a process.
+
+A **discriminator** is an arbitrary value used to **diversify** signed 
pointers so that one validly-signed pointer cannot simply be copied over 
another.  A discriminator is simply opaque data of some implementation-defined 
size that is included in the signature as a salt.
+
+Nearly all aspects of pointer authentication use just these two primary 
operations:
+
+- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a 
raw pointer, an abstract signing key, and a discriminator.
+
+- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a 
signed pointer, an abstract signing key, and a discriminator.
+
+``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must 
succeed and produce ``raw_pointer``.  ``auth`` applied to a value that was 
ultimately produced in any other way is expected to immediately halt the 
program.  However, it is permitted for ``auth`` to fail to detect that a signed 
pointer was not produced in this way, in which case it may return anything; 
this is what makes pointer authentication a probabilistic mitigation rather 
than a perfect one.
+
+There are two secondary operations which are required only to implement 
certain intrinsics in :
+
+- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer 
and a key it was presumptively signed with.  This is useful for certain kinds 
of tooling, such as crash backtraces; it should generally not be used in the 
basic language ABI except in very careful ways.
+
+- ``sign_generic(value)`` produces a cryptographic signature for arbitrary 
data, not necessarily a pointer.  This is useful for efficiently verifying that 
non-pointer data has not been tampered with.
+
+Whenever any of these operations is called for, the key value must be known 
statically.  This is b

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

2023-09-12 Thread David Spickett via cfe-commits



@@ -0,0 +1,548 @@
+Pointer Authentication
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic 
protection against exploiting a broad class of memory bugs to take control of 
program execution.  When adopted consistently in a language ABI, it provides a 
form of relatively fine-grained control flow integrity (CFI) check that resists 
both return-oriented programming (ROP) and jump-oriented programming (JOP) 
attacks.
+
+While pointer authentication can be implemented purely in software, direct 
hardware support (e.g. as provided by ARMv8.3) can dramatically lower the 
execution speed and code size costs.  Similarly, while pointer authentication 
can be implemented on any architecture, taking advantage of the (typically) 
excess addressing range of a target with 64-bit pointers minimizes the impact 
on memory performance and can allow interoperation with existing code (by 
disabling pointer authentication dynamically).  This document will generally 
attempt to present the pointer authentication feature independent of any 
hardware implementation or ABI.  Considerations that are 
implementation-specific are clearly identified throughout.
+
+Note that there are several different terms in use:
+
+- **Pointer authentication** is a target-independent language technology.
+
+- **ARMv8.3** is an AArch64 architecture revision of that provides hardware 
support for pointer authentication.  It is implemented on several shipping 
processors, including the Apple A12 and later.
+
+* **arm64e** is a specific ABI for (not yet fully stable) for implementing 
pointer authentication on ARMv8.3 on certain Apple operating systems.
+
+This document serves four purposes:
+
+- It describes the basic ideas of pointer authentication.
+
+- It documents several language extensions that are useful on targets using 
pointer authentication.
+
+- It presents a theory of operation for the security mitigation, describing 
the basic requirements for correctness, various weaknesses in the mechanism, 
and ways in which programmers can strengthen its protections (including 
recommendations for language implementors).
+
+- It will eventually document the language ABIs currently used for C, C++, 
Objective-C, and Swift on arm64e, although these are not yet stable on any 
target.
+
+Basic Concepts
+--
+
+The simple address of an object or function is a **raw pointer**.  A raw 
pointer can be **signed** to produce a **signed pointer**.  A signed pointer 
can be then **authenticated** in order to verify that it was **validly signed** 
and extract the original raw pointer.  These terms reflect the most likely 
implementation technique: computing and storing a cryptographic signature along 
with the pointer.  The security of pointer authentication does not rely on 
attackers not being able to separately overwrite the signature.
+
+An **abstract signing key** is a name which refers to a secret key which can 
used to sign and authenticate pointers.  The key value for a particular name is 
consistent throughout a process.
+
+A **discriminator** is an arbitrary value used to **diversify** signed 
pointers so that one validly-signed pointer cannot simply be copied over 
another.  A discriminator is simply opaque data of some implementation-defined 
size that is included in the signature as a salt.
+
+Nearly all aspects of pointer authentication use just these two primary 
operations:
+
+- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a 
raw pointer, an abstract signing key, and a discriminator.
+
+- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a 
signed pointer, an abstract signing key, and a discriminator.
+
+``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must 
succeed and produce ``raw_pointer``.  ``auth`` applied to a value that was 
ultimately produced in any other way is expected to immediately halt the 
program.  However, it is permitted for ``auth`` to fail to detect that a signed 
pointer was not produced in this way, in which case it may return anything; 
this is what makes pointer authentication a probabilistic mitigation rather 
than a perfect one.
+
+There are two secondary operations which are required only to implement 
certain intrinsics in :
+
+- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer 
and a key it was presumptively signed with.  This is useful for certain kinds 
of tooling, such as crash backtraces; it should generally not be used in the 
basic language ABI except in very careful ways.
+
+- ``sign_generic(value)`` produces a cryptographic signature for arbitrary 
data, not necessarily a pointer.  This is useful for efficiently verifying that 
non-pointer data has not been tampered with.
+
+Whenever any of these operations is called for, the key value must be known 
statically.  This is b

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

2023-09-12 Thread David Spickett via cfe-commits



@@ -0,0 +1,548 @@
+Pointer Authentication
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic 
protection against exploiting a broad class of memory bugs to take control of 
program execution.  When adopted consistently in a language ABI, it provides a 
form of relatively fine-grained control flow integrity (CFI) check that resists 
both return-oriented programming (ROP) and jump-oriented programming (JOP) 
attacks.
+
+While pointer authentication can be implemented purely in software, direct 
hardware support (e.g. as provided by ARMv8.3) can dramatically lower the 
execution speed and code size costs.  Similarly, while pointer authentication 
can be implemented on any architecture, taking advantage of the (typically) 
excess addressing range of a target with 64-bit pointers minimizes the impact 
on memory performance and can allow interoperation with existing code (by 
disabling pointer authentication dynamically).  This document will generally 
attempt to present the pointer authentication feature independent of any 
hardware implementation or ABI.  Considerations that are 
implementation-specific are clearly identified throughout.
+
+Note that there are several different terms in use:
+
+- **Pointer authentication** is a target-independent language technology.
+
+- **ARMv8.3** is an AArch64 architecture revision of that provides hardware 
support for pointer authentication.  It is implemented on several shipping 
processors, including the Apple A12 and later.
+
+* **arm64e** is a specific ABI for (not yet fully stable) for implementing 
pointer authentication on ARMv8.3 on certain Apple operating systems.
+
+This document serves four purposes:
+
+- It describes the basic ideas of pointer authentication.
+
+- It documents several language extensions that are useful on targets using 
pointer authentication.
+
+- It presents a theory of operation for the security mitigation, describing 
the basic requirements for correctness, various weaknesses in the mechanism, 
and ways in which programmers can strengthen its protections (including 
recommendations for language implementors).
+
+- It will eventually document the language ABIs currently used for C, C++, 
Objective-C, and Swift on arm64e, although these are not yet stable on any 
target.
+
+Basic Concepts
+--
+
+The simple address of an object or function is a **raw pointer**.  A raw 
pointer can be **signed** to produce a **signed pointer**.  A signed pointer 
can be then **authenticated** in order to verify that it was **validly signed** 
and extract the original raw pointer.  These terms reflect the most likely 
implementation technique: computing and storing a cryptographic signature along 
with the pointer.  The security of pointer authentication does not rely on 
attackers not being able to separately overwrite the signature.
+
+An **abstract signing key** is a name which refers to a secret key which can 
used to sign and authenticate pointers.  The key value for a particular name is 
consistent throughout a process.
+
+A **discriminator** is an arbitrary value used to **diversify** signed 
pointers so that one validly-signed pointer cannot simply be copied over 
another.  A discriminator is simply opaque data of some implementation-defined 
size that is included in the signature as a salt.
+
+Nearly all aspects of pointer authentication use just these two primary 
operations:
+
+- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a 
raw pointer, an abstract signing key, and a discriminator.
+
+- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a 
signed pointer, an abstract signing key, and a discriminator.
+
+``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must 
succeed and produce ``raw_pointer``.  ``auth`` applied to a value that was 
ultimately produced in any other way is expected to immediately halt the 
program.  However, it is permitted for ``auth`` to fail to detect that a signed 
pointer was not produced in this way, in which case it may return anything; 
this is what makes pointer authentication a probabilistic mitigation rather 
than a perfect one.
+
+There are two secondary operations which are required only to implement 
certain intrinsics in :
+
+- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer 
and a key it was presumptively signed with.  This is useful for certain kinds 
of tooling, such as crash backtraces; it should generally not be used in the 
basic language ABI except in very careful ways.
+
+- ``sign_generic(value)`` produces a cryptographic signature for arbitrary 
data, not necessarily a pointer.  This is useful for efficiently verifying that 
non-pointer data has not been tampered with.
+
+Whenever any of these operations is called for, the key value must be known 
statically.  This is b

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

2023-09-12 Thread David Spickett via cfe-commits



@@ -0,0 +1,548 @@
+Pointer Authentication
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic 
protection against exploiting a broad class of memory bugs to take control of 
program execution.  When adopted consistently in a language ABI, it provides a 
form of relatively fine-grained control flow integrity (CFI) check that resists 
both return-oriented programming (ROP) and jump-oriented programming (JOP) 
attacks.
+
+While pointer authentication can be implemented purely in software, direct 
hardware support (e.g. as provided by ARMv8.3) can dramatically lower the 
execution speed and code size costs.  Similarly, while pointer authentication 
can be implemented on any architecture, taking advantage of the (typically) 
excess addressing range of a target with 64-bit pointers minimizes the impact 
on memory performance and can allow interoperation with existing code (by 
disabling pointer authentication dynamically).  This document will generally 
attempt to present the pointer authentication feature independent of any 
hardware implementation or ABI.  Considerations that are 
implementation-specific are clearly identified throughout.
+
+Note that there are several different terms in use:
+
+- **Pointer authentication** is a target-independent language technology.
+
+- **ARMv8.3** is an AArch64 architecture revision of that provides hardware 
support for pointer authentication.  It is implemented on several shipping 
processors, including the Apple A12 and later.
+
+* **arm64e** is a specific ABI for (not yet fully stable) for implementing 
pointer authentication on ARMv8.3 on certain Apple operating systems.
+
+This document serves four purposes:
+
+- It describes the basic ideas of pointer authentication.
+
+- It documents several language extensions that are useful on targets using 
pointer authentication.
+
+- It presents a theory of operation for the security mitigation, describing 
the basic requirements for correctness, various weaknesses in the mechanism, 
and ways in which programmers can strengthen its protections (including 
recommendations for language implementors).
+
+- It will eventually document the language ABIs currently used for C, C++, 
Objective-C, and Swift on arm64e, although these are not yet stable on any 
target.
+
+Basic Concepts
+--
+
+The simple address of an object or function is a **raw pointer**.  A raw 
pointer can be **signed** to produce a **signed pointer**.  A signed pointer 
can be then **authenticated** in order to verify that it was **validly signed** 
and extract the original raw pointer.  These terms reflect the most likely 
implementation technique: computing and storing a cryptographic signature along 
with the pointer.  The security of pointer authentication does not rely on 
attackers not being able to separately overwrite the signature.
+
+An **abstract signing key** is a name which refers to a secret key which can 
used to sign and authenticate pointers.  The key value for a particular name is 
consistent throughout a process.
+
+A **discriminator** is an arbitrary value used to **diversify** signed 
pointers so that one validly-signed pointer cannot simply be copied over 
another.  A discriminator is simply opaque data of some implementation-defined 
size that is included in the signature as a salt.
+
+Nearly all aspects of pointer authentication use just these two primary 
operations:
+
+- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a 
raw pointer, an abstract signing key, and a discriminator.
+
+- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a 
signed pointer, an abstract signing key, and a discriminator.
+
+``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must 
succeed and produce ``raw_pointer``.  ``auth`` applied to a value that was 
ultimately produced in any other way is expected to immediately halt the 
program.  However, it is permitted for ``auth`` to fail to detect that a signed 
pointer was not produced in this way, in which case it may return anything; 
this is what makes pointer authentication a probabilistic mitigation rather 
than a perfect one.
+
+There are two secondary operations which are required only to implement 
certain intrinsics in :
+
+- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer 
and a key it was presumptively signed with.  This is useful for certain kinds 
of tooling, such as crash backtraces; it should generally not be used in the 
basic language ABI except in very careful ways.
+
+- ``sign_generic(value)`` produces a cryptographic signature for arbitrary 
data, not necessarily a pointer.  This is useful for efficiently verifying that 
non-pointer data has not been tampered with.
+
+Whenever any of these operations is called for, the key value must be known 
statically.  This is b

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

2023-09-12 Thread David Spickett via cfe-commits



@@ -0,0 +1,548 @@
+Pointer Authentication
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic 
protection against exploiting a broad class of memory bugs to take control of 
program execution.  When adopted consistently in a language ABI, it provides a 
form of relatively fine-grained control flow integrity (CFI) check that resists 
both return-oriented programming (ROP) and jump-oriented programming (JOP) 
attacks.
+
+While pointer authentication can be implemented purely in software, direct 
hardware support (e.g. as provided by ARMv8.3) can dramatically lower the 
execution speed and code size costs.  Similarly, while pointer authentication 
can be implemented on any architecture, taking advantage of the (typically) 
excess addressing range of a target with 64-bit pointers minimizes the impact 
on memory performance and can allow interoperation with existing code (by 
disabling pointer authentication dynamically).  This document will generally 
attempt to present the pointer authentication feature independent of any 
hardware implementation or ABI.  Considerations that are 
implementation-specific are clearly identified throughout.
+
+Note that there are several different terms in use:
+
+- **Pointer authentication** is a target-independent language technology.
+
+- **ARMv8.3** is an AArch64 architecture revision of that provides hardware 
support for pointer authentication.  It is implemented on several shipping 
processors, including the Apple A12 and later.
+
+* **arm64e** is a specific ABI for (not yet fully stable) for implementing 
pointer authentication on ARMv8.3 on certain Apple operating systems.
+
+This document serves four purposes:
+
+- It describes the basic ideas of pointer authentication.
+
+- It documents several language extensions that are useful on targets using 
pointer authentication.
+
+- It presents a theory of operation for the security mitigation, describing 
the basic requirements for correctness, various weaknesses in the mechanism, 
and ways in which programmers can strengthen its protections (including 
recommendations for language implementors).
+
+- It will eventually document the language ABIs currently used for C, C++, 
Objective-C, and Swift on arm64e, although these are not yet stable on any 
target.
+
+Basic Concepts
+--
+
+The simple address of an object or function is a **raw pointer**.  A raw 
pointer can be **signed** to produce a **signed pointer**.  A signed pointer 
can be then **authenticated** in order to verify that it was **validly signed** 
and extract the original raw pointer.  These terms reflect the most likely 
implementation technique: computing and storing a cryptographic signature along 
with the pointer.  The security of pointer authentication does not rely on 
attackers not being able to separately overwrite the signature.
+
+An **abstract signing key** is a name which refers to a secret key which can 
used to sign and authenticate pointers.  The key value for a particular name is 
consistent throughout a process.
+
+A **discriminator** is an arbitrary value used to **diversify** signed 
pointers so that one validly-signed pointer cannot simply be copied over 
another.  A discriminator is simply opaque data of some implementation-defined 
size that is included in the signature as a salt.
+
+Nearly all aspects of pointer authentication use just these two primary 
operations:
+
+- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a 
raw pointer, an abstract signing key, and a discriminator.
+
+- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a 
signed pointer, an abstract signing key, and a discriminator.
+
+``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must 
succeed and produce ``raw_pointer``.  ``auth`` applied to a value that was 
ultimately produced in any other way is expected to immediately halt the 
program.  However, it is permitted for ``auth`` to fail to detect that a signed 
pointer was not produced in this way, in which case it may return anything; 
this is what makes pointer authentication a probabilistic mitigation rather 
than a perfect one.

DavidSpickett wrote:

"was originally produced" seems to make more sense here.

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

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

2023-09-12 Thread David Spickett via cfe-commits



@@ -0,0 +1,548 @@
+Pointer Authentication
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic 
protection against exploiting a broad class of memory bugs to take control of 
program execution.  When adopted consistently in a language ABI, it provides a 
form of relatively fine-grained control flow integrity (CFI) check that resists 
both return-oriented programming (ROP) and jump-oriented programming (JOP) 
attacks.
+
+While pointer authentication can be implemented purely in software, direct 
hardware support (e.g. as provided by ARMv8.3) can dramatically lower the 
execution speed and code size costs.  Similarly, while pointer authentication 
can be implemented on any architecture, taking advantage of the (typically) 
excess addressing range of a target with 64-bit pointers minimizes the impact 
on memory performance and can allow interoperation with existing code (by 
disabling pointer authentication dynamically).  This document will generally 
attempt to present the pointer authentication feature independent of any 
hardware implementation or ABI.  Considerations that are 
implementation-specific are clearly identified throughout.
+
+Note that there are several different terms in use:
+
+- **Pointer authentication** is a target-independent language technology.
+
+- **ARMv8.3** is an AArch64 architecture revision of that provides hardware 
support for pointer authentication.  It is implemented on several shipping 
processors, including the Apple A12 and later.
+
+* **arm64e** is a specific ABI for (not yet fully stable) for implementing 
pointer authentication on ARMv8.3 on certain Apple operating systems.
+
+This document serves four purposes:
+
+- It describes the basic ideas of pointer authentication.
+
+- It documents several language extensions that are useful on targets using 
pointer authentication.
+
+- It presents a theory of operation for the security mitigation, describing 
the basic requirements for correctness, various weaknesses in the mechanism, 
and ways in which programmers can strengthen its protections (including 
recommendations for language implementors).
+
+- It will eventually document the language ABIs currently used for C, C++, 
Objective-C, and Swift on arm64e, although these are not yet stable on any 
target.
+
+Basic Concepts
+--
+
+The simple address of an object or function is a **raw pointer**.  A raw 
pointer can be **signed** to produce a **signed pointer**.  A signed pointer 
can be then **authenticated** in order to verify that it was **validly signed** 
and extract the original raw pointer.  These terms reflect the most likely 
implementation technique: computing and storing a cryptographic signature along 
with the pointer.  The security of pointer authentication does not rely on 
attackers not being able to separately overwrite the signature.
+
+An **abstract signing key** is a name which refers to a secret key which can 
used to sign and authenticate pointers.  The key value for a particular name is 
consistent throughout a process.
+
+A **discriminator** is an arbitrary value used to **diversify** signed 
pointers so that one validly-signed pointer cannot simply be copied over 
another.  A discriminator is simply opaque data of some implementation-defined 
size that is included in the signature as a salt.
+
+Nearly all aspects of pointer authentication use just these two primary 
operations:
+
+- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a 
raw pointer, an abstract signing key, and a discriminator.
+
+- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a 
signed pointer, an abstract signing key, and a discriminator.
+
+``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must 
succeed and produce ``raw_pointer``.  ``auth`` applied to a value that was 
ultimately produced in any other way is expected to immediately halt the 
program.  However, it is permitted for ``auth`` to fail to detect that a signed 
pointer was not produced in this way, in which case it may return anything; 
this is what makes pointer authentication a probabilistic mitigation rather 
than a perfect one.
+
+There are two secondary operations which are required only to implement 
certain intrinsics in :
+
+- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer 
and a key it was presumptively signed with.  This is useful for certain kinds 
of tooling, such as crash backtraces; it should generally not be used in the 
basic language ABI except in very careful ways.
+
+- ``sign_generic(value)`` produces a cryptographic signature for arbitrary 
data, not necessarily a pointer.  This is useful for efficiently verifying that 
non-pointer data has not been tampered with.
+
+Whenever any of these operations is called for, the key value must be known 
statically.  This is b

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

2023-09-12 Thread David Spickett via cfe-commits



@@ -0,0 +1,548 @@
+Pointer Authentication
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic 
protection against exploiting a broad class of memory bugs to take control of 
program execution.  When adopted consistently in a language ABI, it provides a 
form of relatively fine-grained control flow integrity (CFI) check that resists 
both return-oriented programming (ROP) and jump-oriented programming (JOP) 
attacks.
+
+While pointer authentication can be implemented purely in software, direct 
hardware support (e.g. as provided by ARMv8.3) can dramatically lower the 
execution speed and code size costs.  Similarly, while pointer authentication 
can be implemented on any architecture, taking advantage of the (typically) 
excess addressing range of a target with 64-bit pointers minimizes the impact 
on memory performance and can allow interoperation with existing code (by 
disabling pointer authentication dynamically).  This document will generally 
attempt to present the pointer authentication feature independent of any 
hardware implementation or ABI.  Considerations that are 
implementation-specific are clearly identified throughout.
+
+Note that there are several different terms in use:
+
+- **Pointer authentication** is a target-independent language technology.
+
+- **ARMv8.3** is an AArch64 architecture revision of that provides hardware 
support for pointer authentication.  It is implemented on several shipping 
processors, including the Apple A12 and later.
+
+* **arm64e** is a specific ABI for (not yet fully stable) for implementing 
pointer authentication on ARMv8.3 on certain Apple operating systems.
+
+This document serves four purposes:
+
+- It describes the basic ideas of pointer authentication.
+
+- It documents several language extensions that are useful on targets using 
pointer authentication.
+
+- It presents a theory of operation for the security mitigation, describing 
the basic requirements for correctness, various weaknesses in the mechanism, 
and ways in which programmers can strengthen its protections (including 
recommendations for language implementors).
+
+- It will eventually document the language ABIs currently used for C, C++, 
Objective-C, and Swift on arm64e, although these are not yet stable on any 
target.
+
+Basic Concepts
+--
+
+The simple address of an object or function is a **raw pointer**.  A raw 
pointer can be **signed** to produce a **signed pointer**.  A signed pointer 
can be then **authenticated** in order to verify that it was **validly signed** 
and extract the original raw pointer.  These terms reflect the most likely 
implementation technique: computing and storing a cryptographic signature along 
with the pointer.  The security of pointer authentication does not rely on 
attackers not being able to separately overwrite the signature.
+
+An **abstract signing key** is a name which refers to a secret key which can 
used to sign and authenticate pointers.  The key value for a particular name is 
consistent throughout a process.
+
+A **discriminator** is an arbitrary value used to **diversify** signed 
pointers so that one validly-signed pointer cannot simply be copied over 
another.  A discriminator is simply opaque data of some implementation-defined 
size that is included in the signature as a salt.
+
+Nearly all aspects of pointer authentication use just these two primary 
operations:
+
+- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a 
raw pointer, an abstract signing key, and a discriminator.
+
+- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a 
signed pointer, an abstract signing key, and a discriminator.
+
+``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must 
succeed and produce ``raw_pointer``.  ``auth`` applied to a value that was 
ultimately produced in any other way is expected to immediately halt the 
program.  However, it is permitted for ``auth`` to fail to detect that a signed 
pointer was not produced in this way, in which case it may return anything; 
this is what makes pointer authentication a probabilistic mitigation rather 
than a perfect one.
+
+There are two secondary operations which are required only to implement 
certain intrinsics in :
+
+- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer 
and a key it was presumptively signed with.  This is useful for certain kinds 
of tooling, such as crash backtraces; it should generally not be used in the 
basic language ABI except in very careful ways.
+
+- ``sign_generic(value)`` produces a cryptographic signature for arbitrary 
data, not necessarily a pointer.  This is useful for efficiently verifying that 
non-pointer data has not been tampered with.
+
+Whenever any of these operations is called for, the key value must be known 
statically.  This is b

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

2023-09-12 Thread David Spickett via cfe-commits



@@ -0,0 +1,548 @@
+Pointer Authentication
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic 
protection against exploiting a broad class of memory bugs to take control of 
program execution.  When adopted consistently in a language ABI, it provides a 
form of relatively fine-grained control flow integrity (CFI) check that resists 
both return-oriented programming (ROP) and jump-oriented programming (JOP) 
attacks.
+
+While pointer authentication can be implemented purely in software, direct 
hardware support (e.g. as provided by ARMv8.3) can dramatically lower the 
execution speed and code size costs.  Similarly, while pointer authentication 
can be implemented on any architecture, taking advantage of the (typically) 
excess addressing range of a target with 64-bit pointers minimizes the impact 
on memory performance and can allow interoperation with existing code (by 
disabling pointer authentication dynamically).  This document will generally 
attempt to present the pointer authentication feature independent of any 
hardware implementation or ABI.  Considerations that are 
implementation-specific are clearly identified throughout.
+
+Note that there are several different terms in use:
+
+- **Pointer authentication** is a target-independent language technology.
+
+- **ARMv8.3** is an AArch64 architecture revision of that provides hardware 
support for pointer authentication.  It is implemented on several shipping 
processors, including the Apple A12 and later.
+
+* **arm64e** is a specific ABI for (not yet fully stable) for implementing 
pointer authentication on ARMv8.3 on certain Apple operating systems.
+
+This document serves four purposes:
+
+- It describes the basic ideas of pointer authentication.
+
+- It documents several language extensions that are useful on targets using 
pointer authentication.
+
+- It presents a theory of operation for the security mitigation, describing 
the basic requirements for correctness, various weaknesses in the mechanism, 
and ways in which programmers can strengthen its protections (including 
recommendations for language implementors).
+
+- It will eventually document the language ABIs currently used for C, C++, 
Objective-C, and Swift on arm64e, although these are not yet stable on any 
target.
+
+Basic Concepts
+--
+
+The simple address of an object or function is a **raw pointer**.  A raw 
pointer can be **signed** to produce a **signed pointer**.  A signed pointer 
can be then **authenticated** in order to verify that it was **validly signed** 
and extract the original raw pointer.  These terms reflect the most likely 
implementation technique: computing and storing a cryptographic signature along 
with the pointer.  The security of pointer authentication does not rely on 
attackers not being able to separately overwrite the signature.
+
+An **abstract signing key** is a name which refers to a secret key which can 
used to sign and authenticate pointers.  The key value for a particular name is 
consistent throughout a process.
+
+A **discriminator** is an arbitrary value used to **diversify** signed 
pointers so that one validly-signed pointer cannot simply be copied over 
another.  A discriminator is simply opaque data of some implementation-defined 
size that is included in the signature as a salt.
+
+Nearly all aspects of pointer authentication use just these two primary 
operations:
+
+- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a 
raw pointer, an abstract signing key, and a discriminator.
+
+- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a 
signed pointer, an abstract signing key, and a discriminator.
+
+``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must 
succeed and produce ``raw_pointer``.  ``auth`` applied to a value that was 
ultimately produced in any other way is expected to immediately halt the 
program.  However, it is permitted for ``auth`` to fail to detect that a signed 
pointer was not produced in this way, in which case it may return anything; 
this is what makes pointer authentication a probabilistic mitigation rather 
than a perfect one.
+
+There are two secondary operations which are required only to implement 
certain intrinsics in :
+
+- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer 
and a key it was presumptively signed with.  This is useful for certain kinds 
of tooling, such as crash backtraces; it should generally not be used in the 
basic language ABI except in very careful ways.
+
+- ``sign_generic(value)`` produces a cryptographic signature for arbitrary 
data, not necessarily a pointer.  This is useful for efficiently verifying that 
non-pointer data has not been tampered with.
+
+Whenever any of these operations is called for, the key value must be known 
statically.  This is b

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

2023-09-12 Thread David Spickett via cfe-commits



@@ -0,0 +1,548 @@
+Pointer Authentication
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic 
protection against exploiting a broad class of memory bugs to take control of 
program execution.  When adopted consistently in a language ABI, it provides a 
form of relatively fine-grained control flow integrity (CFI) check that resists 
both return-oriented programming (ROP) and jump-oriented programming (JOP) 
attacks.
+
+While pointer authentication can be implemented purely in software, direct 
hardware support (e.g. as provided by ARMv8.3) can dramatically lower the 
execution speed and code size costs.  Similarly, while pointer authentication 
can be implemented on any architecture, taking advantage of the (typically) 
excess addressing range of a target with 64-bit pointers minimizes the impact 
on memory performance and can allow interoperation with existing code (by 
disabling pointer authentication dynamically).  This document will generally 
attempt to present the pointer authentication feature independent of any 
hardware implementation or ABI.  Considerations that are 
implementation-specific are clearly identified throughout.
+
+Note that there are several different terms in use:
+
+- **Pointer authentication** is a target-independent language technology.
+
+- **ARMv8.3** is an AArch64 architecture revision of that provides hardware 
support for pointer authentication.  It is implemented on several shipping 
processors, including the Apple A12 and later.
+
+* **arm64e** is a specific ABI for (not yet fully stable) for implementing 
pointer authentication on ARMv8.3 on certain Apple operating systems.
+
+This document serves four purposes:
+
+- It describes the basic ideas of pointer authentication.
+
+- It documents several language extensions that are useful on targets using 
pointer authentication.
+
+- It presents a theory of operation for the security mitigation, describing 
the basic requirements for correctness, various weaknesses in the mechanism, 
and ways in which programmers can strengthen its protections (including 
recommendations for language implementors).
+
+- It will eventually document the language ABIs currently used for C, C++, 
Objective-C, and Swift on arm64e, although these are not yet stable on any 
target.
+
+Basic Concepts
+--
+
+The simple address of an object or function is a **raw pointer**.  A raw 
pointer can be **signed** to produce a **signed pointer**.  A signed pointer 
can be then **authenticated** in order to verify that it was **validly signed** 
and extract the original raw pointer.  These terms reflect the most likely 
implementation technique: computing and storing a cryptographic signature along 
with the pointer.  The security of pointer authentication does not rely on 
attackers not being able to separately overwrite the signature.
+
+An **abstract signing key** is a name which refers to a secret key which can 
used to sign and authenticate pointers.  The key value for a particular name is 
consistent throughout a process.
+
+A **discriminator** is an arbitrary value used to **diversify** signed 
pointers so that one validly-signed pointer cannot simply be copied over 
another.  A discriminator is simply opaque data of some implementation-defined 
size that is included in the signature as a salt.
+
+Nearly all aspects of pointer authentication use just these two primary 
operations:
+
+- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a 
raw pointer, an abstract signing key, and a discriminator.
+
+- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a 
signed pointer, an abstract signing key, and a discriminator.
+
+``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must 
succeed and produce ``raw_pointer``.  ``auth`` applied to a value that was 
ultimately produced in any other way is expected to immediately halt the 
program.  However, it is permitted for ``auth`` to fail to detect that a signed 
pointer was not produced in this way, in which case it may return anything; 
this is what makes pointer authentication a probabilistic mitigation rather 
than a perfect one.
+
+There are two secondary operations which are required only to implement 
certain intrinsics in :
+
+- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer 
and a key it was presumptively signed with.  This is useful for certain kinds 
of tooling, such as crash backtraces; it should generally not be used in the 
basic language ABI except in very careful ways.
+
+- ``sign_generic(value)`` produces a cryptographic signature for arbitrary 
data, not necessarily a pointer.  This is useful for efficiently verifying that 
non-pointer data has not been tampered with.
+
+Whenever any of these operations is called for, the key value must be known 
statically.  This is b

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

2023-09-12 Thread David Spickett via cfe-commits



@@ -0,0 +1,548 @@
+Pointer Authentication
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic 
protection against exploiting a broad class of memory bugs to take control of 
program execution.  When adopted consistently in a language ABI, it provides a 
form of relatively fine-grained control flow integrity (CFI) check that resists 
both return-oriented programming (ROP) and jump-oriented programming (JOP) 
attacks.
+
+While pointer authentication can be implemented purely in software, direct 
hardware support (e.g. as provided by ARMv8.3) can dramatically lower the 
execution speed and code size costs.  Similarly, while pointer authentication 
can be implemented on any architecture, taking advantage of the (typically) 
excess addressing range of a target with 64-bit pointers minimizes the impact 
on memory performance and can allow interoperation with existing code (by 
disabling pointer authentication dynamically).  This document will generally 
attempt to present the pointer authentication feature independent of any 
hardware implementation or ABI.  Considerations that are 
implementation-specific are clearly identified throughout.
+
+Note that there are several different terms in use:
+
+- **Pointer authentication** is a target-independent language technology.
+
+- **ARMv8.3** is an AArch64 architecture revision of that provides hardware 
support for pointer authentication.  It is implemented on several shipping 
processors, including the Apple A12 and later.
+
+* **arm64e** is a specific ABI for (not yet fully stable) for implementing 
pointer authentication on ARMv8.3 on certain Apple operating systems.
+
+This document serves four purposes:
+
+- It describes the basic ideas of pointer authentication.
+
+- It documents several language extensions that are useful on targets using 
pointer authentication.
+
+- It presents a theory of operation for the security mitigation, describing 
the basic requirements for correctness, various weaknesses in the mechanism, 
and ways in which programmers can strengthen its protections (including 
recommendations for language implementors).
+
+- It will eventually document the language ABIs currently used for C, C++, 
Objective-C, and Swift on arm64e, although these are not yet stable on any 
target.
+
+Basic Concepts
+--
+
+The simple address of an object or function is a **raw pointer**.  A raw 
pointer can be **signed** to produce a **signed pointer**.  A signed pointer 
can be then **authenticated** in order to verify that it was **validly signed** 
and extract the original raw pointer.  These terms reflect the most likely 
implementation technique: computing and storing a cryptographic signature along 
with the pointer.  The security of pointer authentication does not rely on 
attackers not being able to separately overwrite the signature.
+
+An **abstract signing key** is a name which refers to a secret key which can 
used to sign and authenticate pointers.  The key value for a particular name is 
consistent throughout a process.
+
+A **discriminator** is an arbitrary value used to **diversify** signed 
pointers so that one validly-signed pointer cannot simply be copied over 
another.  A discriminator is simply opaque data of some implementation-defined 
size that is included in the signature as a salt.
+
+Nearly all aspects of pointer authentication use just these two primary 
operations:
+
+- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a 
raw pointer, an abstract signing key, and a discriminator.
+
+- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a 
signed pointer, an abstract signing key, and a discriminator.
+
+``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must 
succeed and produce ``raw_pointer``.  ``auth`` applied to a value that was 
ultimately produced in any other way is expected to immediately halt the 
program.  However, it is permitted for ``auth`` to fail to detect that a signed 
pointer was not produced in this way, in which case it may return anything; 
this is what makes pointer authentication a probabilistic mitigation rather 
than a perfect one.
+
+There are two secondary operations which are required only to implement 
certain intrinsics in :
+
+- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer 
and a key it was presumptively signed with.  This is useful for certain kinds 
of tooling, such as crash backtraces; it should generally not be used in the 
basic language ABI except in very careful ways.
+
+- ``sign_generic(value)`` produces a cryptographic signature for arbitrary 
data, not necessarily a pointer.  This is useful for efficiently verifying that 
non-pointer data has not been tampered with.
+
+Whenever any of these operations is called for, the key value must be known 
statically.  This is b

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

2023-09-12 Thread David Spickett via cfe-commits



@@ -0,0 +1,548 @@
+Pointer Authentication
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic 
protection against exploiting a broad class of memory bugs to take control of 
program execution.  When adopted consistently in a language ABI, it provides a 
form of relatively fine-grained control flow integrity (CFI) check that resists 
both return-oriented programming (ROP) and jump-oriented programming (JOP) 
attacks.
+
+While pointer authentication can be implemented purely in software, direct 
hardware support (e.g. as provided by ARMv8.3) can dramatically lower the 
execution speed and code size costs.  Similarly, while pointer authentication 
can be implemented on any architecture, taking advantage of the (typically) 
excess addressing range of a target with 64-bit pointers minimizes the impact 
on memory performance and can allow interoperation with existing code (by 
disabling pointer authentication dynamically).  This document will generally 
attempt to present the pointer authentication feature independent of any 
hardware implementation or ABI.  Considerations that are 
implementation-specific are clearly identified throughout.
+
+Note that there are several different terms in use:
+
+- **Pointer authentication** is a target-independent language technology.
+
+- **ARMv8.3** is an AArch64 architecture revision of that provides hardware 
support for pointer authentication.  It is implemented on several shipping 
processors, including the Apple A12 and later.
+
+* **arm64e** is a specific ABI for (not yet fully stable) for implementing 
pointer authentication on ARMv8.3 on certain Apple operating systems.
+
+This document serves four purposes:
+
+- It describes the basic ideas of pointer authentication.
+
+- It documents several language extensions that are useful on targets using 
pointer authentication.
+
+- It presents a theory of operation for the security mitigation, describing 
the basic requirements for correctness, various weaknesses in the mechanism, 
and ways in which programmers can strengthen its protections (including 
recommendations for language implementors).
+
+- It will eventually document the language ABIs currently used for C, C++, 
Objective-C, and Swift on arm64e, although these are not yet stable on any 
target.
+
+Basic Concepts
+--
+
+The simple address of an object or function is a **raw pointer**.  A raw 
pointer can be **signed** to produce a **signed pointer**.  A signed pointer 
can be then **authenticated** in order to verify that it was **validly signed** 
and extract the original raw pointer.  These terms reflect the most likely 
implementation technique: computing and storing a cryptographic signature along 
with the pointer.  The security of pointer authentication does not rely on 
attackers not being able to separately overwrite the signature.
+
+An **abstract signing key** is a name which refers to a secret key which can 
used to sign and authenticate pointers.  The key value for a particular name is 
consistent throughout a process.
+
+A **discriminator** is an arbitrary value used to **diversify** signed 
pointers so that one validly-signed pointer cannot simply be copied over 
another.  A discriminator is simply opaque data of some implementation-defined 
size that is included in the signature as a salt.
+
+Nearly all aspects of pointer authentication use just these two primary 
operations:
+
+- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a 
raw pointer, an abstract signing key, and a discriminator.
+
+- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a 
signed pointer, an abstract signing key, and a discriminator.
+
+``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must 
succeed and produce ``raw_pointer``.  ``auth`` applied to a value that was 
ultimately produced in any other way is expected to immediately halt the 
program.  However, it is permitted for ``auth`` to fail to detect that a signed 
pointer was not produced in this way, in which case it may return anything; 
this is what makes pointer authentication a probabilistic mitigation rather 
than a perfect one.
+
+There are two secondary operations which are required only to implement 
certain intrinsics in :
+
+- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer 
and a key it was presumptively signed with.  This is useful for certain kinds 
of tooling, such as crash backtraces; it should generally not be used in the 
basic language ABI except in very careful ways.
+
+- ``sign_generic(value)`` produces a cryptographic signature for arbitrary 
data, not necessarily a pointer.  This is useful for efficiently verifying that 
non-pointer data has not been tampered with.
+
+Whenever any of these operations is called for, the key value must be known 
statically.  This is b

[PATCH] D156743: clang/OpenCL: Add inline implementations of sqrt in builtin header

2023-09-12 Thread Matt Arsenault via Phabricator via cfe-commits

arsenm added a comment.

ping


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

https://reviews.llvm.org/D156743

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

[PATCH] D156989: FloatingPointMode: Use -1 for "Dynamic"

2023-09-12 Thread Matt Arsenault via Phabricator via cfe-commits

arsenm added a comment.

ping. This enum should just match FLT_ROUNDS and designing ABI around whatever 
this was doing doesn't really make sense


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

https://reviews.llvm.org/D156989

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

[PATCH] D147218: [OpenMP][Flang][MLIR] Lowering of OpenMP requires directive from parse tree to MLIR

2023-09-12 Thread Sergio Afonso via Phabricator via cfe-commits

skatrak updated this revision to Diff 556542.
skatrak marked 3 inline comments as done.
skatrak added a comment.

Address review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147218

Files:
  flang/include/flang/Lower/OpenMP.h
  flang/lib/Lower/Bridge.cpp
  flang/lib/Lower/OpenMP.cpp
  flang/test/Lower/OpenMP/Todo/requires-unnamed-common.f90
  flang/test/Lower/OpenMP/requires-common.f90
  flang/test/Lower/OpenMP/requires-notarget.f90
  flang/test/Lower/OpenMP/requires.f90

Index: flang/test/Lower/OpenMP/requires.f90
===
--- /dev/null
+++ flang/test/Lower/OpenMP/requires.f90
@@ -0,0 +1,14 @@
+! RUN: %flang_fc1 -emit-fir -fopenmp %s -o - | FileCheck %s
+! RUN: %flang_fc1 -emit-fir -fopenmp -fopenmp-is-target-device %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -emit-fir %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -fopenmp-is-target-device -emit-fir %s -o - | FileCheck %s
+
+! This test checks the lowering of requires into MLIR
+
+!CHECK:  module attributes {
+!CHECK-SAME: omp.requires = #omp
+program requires
+  !$omp requires unified_shared_memory reverse_offload atomic_default_mem_order(seq_cst)
+  !$omp target
+  !$omp end target
+end program requires
Index: flang/test/Lower/OpenMP/requires-notarget.f90
===
--- /dev/null
+++ flang/test/Lower/OpenMP/requires-notarget.f90
@@ -0,0 +1,14 @@
+! RUN: %flang_fc1 -emit-fir -fopenmp %s -o - | FileCheck %s
+! RUN: %flang_fc1 -emit-fir -fopenmp -fopenmp-is-target-device %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -emit-fir %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -fopenmp-is-target-device -emit-fir %s -o - | FileCheck %s
+
+! This test checks that requires lowering into MLIR skips creating the
+! omp.requires attribute with target-related clauses if there are no device
+! functions in the compilation unit
+
+!CHECK:  module attributes {
+!CHECK-NOT:  omp.requires
+program requires
+  !$omp requires unified_shared_memory reverse_offload atomic_default_mem_order(seq_cst)
+end program requires
Index: flang/test/Lower/OpenMP/requires-common.f90
===
--- /dev/null
+++ flang/test/Lower/OpenMP/requires-common.f90
@@ -0,0 +1,19 @@
+! RUN: %flang_fc1 -emit-fir -fopenmp %s -o - | FileCheck %s
+! RUN: %flang_fc1 -emit-fir -fopenmp -fopenmp-is-target-device %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -emit-fir %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -fopenmp-is-target-device -emit-fir %s -o - | FileCheck %s
+
+! This test checks the lowering of requires into MLIR
+
+!CHECK:  module attributes {
+!CHECK-SAME: omp.requires = #omp
+block data init
+  !$omp requires unified_shared_memory
+  integer :: x
+  common /block/ x
+  data x / 10 /
+end
+
+subroutine f
+  !$omp declare target
+end subroutine f
Index: flang/test/Lower/OpenMP/Todo/requires-unnamed-common.f90
===
--- /dev/null
+++ flang/test/Lower/OpenMP/Todo/requires-unnamed-common.f90
@@ -0,0 +1,25 @@
+! This test checks the lowering of REQUIRES inside of an unnamed BLOCK DATA.
+! The symbol of the `symTab` scope of the `BlockDataUnit` PFT node is null in
+! this case, resulting in the inability to store the REQUIRES flags gathered in
+! it.
+
+! RUN: %flang_fc1 -emit-fir -fopenmp %s -o - | FileCheck %s
+! RUN: %flang_fc1 -emit-fir -fopenmp -fopenmp-is-target-device %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -emit-fir %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -fopenmp-is-target-device -emit-fir %s -o - | FileCheck %s
+! XFAIL: *
+
+! The string "EXPECTED" denotes the expected FIR
+
+!CHECK: module attributes {
+!CHECK-SAME:omp.requires = #omp
+block data
+  !$omp requires unified_shared_memory
+  integer :: x
+  common /block/ x
+  data x / 10 /
+end
+
+subroutine f
+  !$omp declare target
+end subroutine f
Index: flang/lib/Lower/OpenMP.cpp
===
--- flang/lib/Lower/OpenMP.cpp
+++ flang/lib/Lower/OpenMP.cpp
@@ -78,9 +78,7 @@
 static void gatherFuncAndVarSyms(
 const Fortran::parser::OmpObjectList &objList,
 mlir::omp::DeclareTargetCaptureClause clause,
-llvm::SmallVectorImpl>
-&symbolAndClause) {
+llvm::SmallVectorImpl &symbolAndClause) {
   for (const Fortran::parser::OmpObject &ompObject : objList.v) {
 Fortran::common::visit(
 Fortran::common::visitors{
@@ -2474,6 +2472,71 @@
  reductionDeclSymbols));
 }
 
+/// Extract the list of function and variable symbols affected by the given
+/// 'declare target' directive and return the intended device type for them.
+static mlir::omp::DeclareTargetDeviceType getDeclareTargetInfo(
+Fortran::lower::AbstractConverter &converter,
+Fortran::lower::pft::Evaluation &eval,
+

[PATCH] D147218: [OpenMP][Flang][MLIR] Lowering of OpenMP requires directive from parse tree to MLIR

2023-09-12 Thread Sergio Afonso via Phabricator via cfe-commits

skatrak added a comment.

Thank you Kiran for having a look at this!

In D147218#4643257 , 
@kiranchandramohan wrote:

> Could you add to the summary that the `atomic` related handling is done 
> elsewhere.

Done.

> Could you expand the tests to cover the various `if` conditions that are used 
> in the code?

I created a test to gather the flags from the symbol for a `FunctionLikeUnit` 
and for a `BlockDataUnit`, and checked that these flags are only added for the 
module when there's a device construct in the compilation unit, regardless of 
whether we're compiling for host or device and whether the device construct is 
a target region or a declare target subroutine. I think that covers all main 
aspects of this patch.

I have also detected that there is a situation where this approach doesn't 
currently work, so I created an expected-fail test for unnamed block data. The 
issue is that there is no symbol created for those, so there's nowhere to 
store/find these flags. I have seen this happen for main programs as well, but 
I've not been able to create a reproducer for which that happened that 
contained device constructs. In my opinion, this edge case should be addressed 
as its own patch.

Comment at: flang/include/flang/Lower/OpenMP.h:16

+#include "mlir/Dialect/OpenMP/OpenMPDialect.h"
 #include 

kiranchandramohan wrote:
> Is this include required here?
It was, but only because I had made public a function that wasn't supposed to 
be, thanks for noticing.

Comment at: flang/lib/Lower/Bridge.cpp:4779
+if (ompDeviceCodeFound)
+  Fortran::lower::genOpenMPRequires(getModuleOp().getOperation(),
+globalOmpRequiresSymbol);

kiranchandramohan wrote:
> If this is specific for device code, might be worth renaming it to something 
> specific to device.
This is for both host and device, it's just that it's only generated if there 
are device constructs in the compilation unit. Let me know if you still suggest 
renaming it to something else.

I modified the unit tests to run them for the target device as well, so that 
it's clear that the same behavior is expected.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147218

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

[PATCH] D158156: [analyzer] Add C++ array delete checker

2023-09-12 Thread Balázs Benics via Phabricator via cfe-commits

steakhal added inline comments.



Comment at: clang/test/Analysis/ArrayDelete.cpp:85-88
+Derived *d3 = new DoubleDerived[10];
+Base *b3 = d3; // expected-note{{Conversion from derived to base happened 
here}}
+delete[] b3; // expected-warning{{Deleting an array of polymorphic objects 
is undefined}}
+// expected-note@-1{{Deleting an array of polymorphic objects is 
undefined}}

donat.nagy wrote:
> steakhal wrote:
> > Hmm, the static type of `d3` doesn't tell us much about how it refers to an 
> > object of type `DoubleDerived`.
> > To me, it would make sense to have multiple `Conversion from derived to 
> > base happened here`, even telling us what static type it converted to what 
> > other static type in the message.
> > And it should add a new visitor of the same kind tracking the castee.
> > 
> > ```
> > Derived *d3 = new DoubleDerived[10]; // note: `DoubleDerived` -> `Derived` 
> > here
> > Base *b3 = d3; // note: `Derived` -> `Base` here
> > delete[] b3; // warn: Deleting `Derived` objects as `Base` objects.
> > ```
> > WDYT @donat.nagy ?
> I agree that it would be good to be good to mention the class names in the 
> message.
Do you also agree that we should have all steps where such a conversion 
happened?
Notice the 2 `note:` markers in my example. @donat.nagy 


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

https://reviews.llvm.org/D158156

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

[PATCH] D147218: [OpenMP][Flang][MLIR] Lowering of OpenMP requires directive from parse tree to MLIR

2023-09-12 Thread Sergio Afonso via Phabricator via cfe-commits

skatrak updated this revision to Diff 556543.
skatrak added a comment.

Remove leftover comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147218

Files:
  flang/include/flang/Lower/OpenMP.h
  flang/lib/Lower/Bridge.cpp
  flang/lib/Lower/OpenMP.cpp
  flang/test/Lower/OpenMP/Todo/requires-unnamed-common.f90
  flang/test/Lower/OpenMP/requires-common.f90
  flang/test/Lower/OpenMP/requires-notarget.f90
  flang/test/Lower/OpenMP/requires.f90

Index: flang/test/Lower/OpenMP/requires.f90
===
--- /dev/null
+++ flang/test/Lower/OpenMP/requires.f90
@@ -0,0 +1,14 @@
+! RUN: %flang_fc1 -emit-fir -fopenmp %s -o - | FileCheck %s
+! RUN: %flang_fc1 -emit-fir -fopenmp -fopenmp-is-target-device %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -emit-fir %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -fopenmp-is-target-device -emit-fir %s -o - | FileCheck %s
+
+! This test checks the lowering of requires into MLIR
+
+!CHECK:  module attributes {
+!CHECK-SAME: omp.requires = #omp
+program requires
+  !$omp requires unified_shared_memory reverse_offload atomic_default_mem_order(seq_cst)
+  !$omp target
+  !$omp end target
+end program requires
Index: flang/test/Lower/OpenMP/requires-notarget.f90
===
--- /dev/null
+++ flang/test/Lower/OpenMP/requires-notarget.f90
@@ -0,0 +1,14 @@
+! RUN: %flang_fc1 -emit-fir -fopenmp %s -o - | FileCheck %s
+! RUN: %flang_fc1 -emit-fir -fopenmp -fopenmp-is-target-device %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -emit-fir %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -fopenmp-is-target-device -emit-fir %s -o - | FileCheck %s
+
+! This test checks that requires lowering into MLIR skips creating the
+! omp.requires attribute with target-related clauses if there are no device
+! functions in the compilation unit
+
+!CHECK:  module attributes {
+!CHECK-NOT:  omp.requires
+program requires
+  !$omp requires unified_shared_memory reverse_offload atomic_default_mem_order(seq_cst)
+end program requires
Index: flang/test/Lower/OpenMP/requires-common.f90
===
--- /dev/null
+++ flang/test/Lower/OpenMP/requires-common.f90
@@ -0,0 +1,19 @@
+! RUN: %flang_fc1 -emit-fir -fopenmp %s -o - | FileCheck %s
+! RUN: %flang_fc1 -emit-fir -fopenmp -fopenmp-is-target-device %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -emit-fir %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -fopenmp-is-target-device -emit-fir %s -o - | FileCheck %s
+
+! This test checks the lowering of requires into MLIR
+
+!CHECK:  module attributes {
+!CHECK-SAME: omp.requires = #omp
+block data init
+  !$omp requires unified_shared_memory
+  integer :: x
+  common /block/ x
+  data x / 10 /
+end
+
+subroutine f
+  !$omp declare target
+end subroutine f
Index: flang/test/Lower/OpenMP/Todo/requires-unnamed-common.f90
===
--- /dev/null
+++ flang/test/Lower/OpenMP/Todo/requires-unnamed-common.f90
@@ -0,0 +1,23 @@
+! This test checks the lowering of REQUIRES inside of an unnamed BLOCK DATA.
+! The symbol of the `symTab` scope of the `BlockDataUnit` PFT node is null in
+! this case, resulting in the inability to store the REQUIRES flags gathered in
+! it.
+
+! RUN: %flang_fc1 -emit-fir -fopenmp %s -o - | FileCheck %s
+! RUN: %flang_fc1 -emit-fir -fopenmp -fopenmp-is-target-device %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -emit-fir %s -o - | FileCheck %s
+! RUN: bbc -fopenmp -fopenmp-is-target-device -emit-fir %s -o - | FileCheck %s
+! XFAIL: *
+
+!CHECK: module attributes {
+!CHECK-SAME:omp.requires = #omp
+block data
+  !$omp requires unified_shared_memory
+  integer :: x
+  common /block/ x
+  data x / 10 /
+end
+
+subroutine f
+  !$omp declare target
+end subroutine f
Index: flang/lib/Lower/OpenMP.cpp
===
--- flang/lib/Lower/OpenMP.cpp
+++ flang/lib/Lower/OpenMP.cpp
@@ -78,9 +78,7 @@
 static void gatherFuncAndVarSyms(
 const Fortran::parser::OmpObjectList &objList,
 mlir::omp::DeclareTargetCaptureClause clause,
-llvm::SmallVectorImpl>
-&symbolAndClause) {
+llvm::SmallVectorImpl &symbolAndClause) {
   for (const Fortran::parser::OmpObject &ompObject : objList.v) {
 Fortran::common::visit(
 Fortran::common::visitors{
@@ -2474,6 +2472,71 @@
  reductionDeclSymbols));
 }
 
+/// Extract the list of function and variable symbols affected by the given
+/// 'declare target' directive and return the intended device type for them.
+static mlir::omp::DeclareTargetDeviceType getDeclareTargetInfo(
+Fortran::lower::AbstractConverter &converter,
+Fortran::lower::pft::Evaluation &eval,
+const Fortran::parser::OpenMPDeclareTargetConstruct &declareTargetConstruct,
+llvm::Sm

[PATCH] D151730: [RISCV] Support target attribute for function

2023-09-12 Thread Piyou Chen via Phabricator via cfe-commits

BeMg updated this revision to Diff 556544.
BeMg added a comment.

Update to lastest spec

1. When it exist the duplicate target attribute, select the lastest one.
2. arch's features will override cpu's features. TargetFeature will override 
commandline feature.
3. enhence the testcase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151730

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Basic/Targets/RISCV.h
  clang/test/CodeGen/RISCV/riscv-func-attr-target.c

Index: clang/test/CodeGen/RISCV/riscv-func-attr-target.c
===
--- /dev/null
+++ clang/test/CodeGen/RISCV/riscv-func-attr-target.c
@@ -0,0 +1,55 @@
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -triple riscv64 -target-feature +zifencei -target-feature +m -target-feature +a \
+// RUN:  -emit-llvm %s -o - | FileCheck %s
+
+// CHECK-LABEL: define dso_local void @testDefault
+// CHECK-SAME: () #0 {
+void testDefault() {}
+// CHECK-LABEL: define dso_local void @testMultiAttrStr
+// CHECK-SAME: () #1 {
+__attribute__((target("cpu=rocket-rv64;tune=generic-rv64;arch=+v"))) void
+testMultiAttrStr() {}
+// CHECK-LABEL: define dso_local void @testSingleExtension
+// CHECK-SAME: () #2 {
+__attribute__((target("arch=+zbb"))) void testSingleExtension() {}
+// CHECK-LABEL: define dso_local void @testMultiExtension
+// CHECK-SAME: () #3 {
+__attribute__((target("arch=+zbb,+v,+zicond"))) void testMultiExtension() {}
+// CHECK-LABEL: define dso_local void @testFullArch
+// CHECK-SAME: () #4 {
+__attribute__((target("arch=rv64gc_zbb"))) void testFullArch() {}
+// CHECK-LABEL: define dso_local void @testFullArchButSmallThanCmdArch
+// CHECK-SAME: () #5 {
+__attribute__((target("arch=rv64im"))) void testFullArchButSmallThanCmdArch() {}
+// CHECK-LABEL: define dso_local void @testAttrArchAndAttrCpu
+// CHECK-SAME: () #6 {
+__attribute__((target("cpu=sifive-u54;arch=+zbb"))) void
+testAttrArchAndAttrCpu() {}
+// CHECK-LABEL: define dso_local void @testAttrFullArchAndAttrCpu
+// CHECK-SAME: () #7 {
+__attribute__((target("cpu=sifive-u54;arch=rv64im"))) void
+testAttrFullArchAndAttrCpu() {}
+// CHECK-LABEL: define dso_local void @testAttrCpuOnly
+// CHECK-SAME: () #8 {
+__attribute__((target("cpu=sifive-u54"))) void testAttrCpuOnly() {}
+// CHECK-LABEL: define dso_local void @testMultiArchSelectLast
+// CHECK-SAME: () #4 {
+__attribute__((target("arch=rv64gc;arch=rv64gc_zbb"))) void testMultiArchSelectLast() {}
+// CHECK-LABEL: define dso_local void @testMultiCpuSelectLast
+// CHECK-SAME: () #8 {
+__attribute__((target("cpu=sifive-u74;cpu=sifive-u54"))) void testMultiCpuSelectLast() {}
+// CHECK-LABEL: define dso_local void @testMultiTuneSelectLast
+// CHECK-SAME: () #9 {
+__attribute__((target("tune=sifive-u74;tune=sifive-u54"))) void testMultiTuneSelectLast() {}
+
+//.
+// CHECK: attributes #0 = { {{.*}}"target-features"="+64bit,+a,+m,+zifencei" }
+// CHECK: attributes #1 = { {{.*}}"target-cpu"="rocket-rv64" "target-features"="+64bit,+a,+d,+f,+m,+v,+zicsr,+zifencei,+zve32f,+zve32x,+zve64d,+zve64f,+zve64x,+zvl128b,+zvl32b,+zvl64b" "tune-cpu"="generic-rv64" }
+// CHECK: attributes #2 = { {{.*}}"target-features"="+64bit,+a,+m,+zbb,+zifencei" }
+// CHECK: attributes #3 = { {{.*}}"target-features"="+64bit,+a,+d,+experimental-zicond,+f,+m,+v,+zbb,+zicsr,+zifencei,+zve32f,+zve32x,+zve64d,+zve64f,+zve64x,+zvl128b,+zvl32b,+zvl64b" }
+// CHECK: attributes #4 = { {{.*}}"target-features"="+64bit,+a,+c,+d,+f,+m,+zbb,+zicsr,+zifencei" }
+// CHECK: attributes #5 = { {{.*}}"target-features"="+64bit,+m" }
+// CHECK: attributes #6 = { {{.*}}"target-cpu"="sifive-u54" "target-features"="+64bit,+a,+m,+zbb,+zifencei" }
+// CHECK: attributes #7 = { {{.*}}"target-cpu"="sifive-u54" "target-features"="+64bit,+m" }
+// CHECK: attributes #8 = { {{.*}}"target-cpu"="sifive-u54" "target-features"="+64bit,+a,+c,+d,+f,+m,+zicsr,+zifencei" }
+// CHECK: attributes #9 = { {{.*}}"target-features"="+64bit,+a,+m,+zifencei" "tune-cpu"="sifive-u54" }
Index: clang/lib/Basic/Targets/RISCV.h
===
--- clang/lib/Basic/Targets/RISCV.h
+++ clang/lib/Basic/Targets/RISCV.h
@@ -114,6 +114,8 @@
   void fillValidCPUList(SmallVectorImpl &Values) const override;
   bool isValidTuneCPUName(StringRef Name) const override;
   void fillValidTuneCPUList(SmallVectorImpl &Values) const override;
+  bool supportsTargetAttributeTune() const override { return true; }
+  ParsedTargetAttr parseTargetAttr(StringRef Str) const override;
 };
 class LLVM_LIBRARY_VISIBILITY RISCV32TargetInfo : public RISCVTargetInfo {
 public:
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -224,6 +224,21 @@
 clang::RISCV::LastTSBuiltin - Builtin::FirstTSBuiltin);
 }
 
+sta

[PATCH] D158156: [analyzer] Add C++ array delete checker

2023-09-12 Thread Donát Nagy via Phabricator via cfe-commits

donat.nagy added inline comments.



Comment at: clang/test/Analysis/ArrayDelete.cpp:85-88
+Derived *d3 = new DoubleDerived[10];
+Base *b3 = d3; // expected-note{{Conversion from derived to base happened 
here}}
+delete[] b3; // expected-warning{{Deleting an array of polymorphic objects 
is undefined}}
+// expected-note@-1{{Deleting an array of polymorphic objects is 
undefined}}

steakhal wrote:
> donat.nagy wrote:
> > steakhal wrote:
> > > Hmm, the static type of `d3` doesn't tell us much about how it refers to 
> > > an object of type `DoubleDerived`.
> > > To me, it would make sense to have multiple `Conversion from derived to 
> > > base happened here`, even telling us what static type it converted to 
> > > what other static type in the message.
> > > And it should add a new visitor of the same kind tracking the castee.
> > > 
> > > ```
> > > Derived *d3 = new DoubleDerived[10]; // note: `DoubleDerived` -> 
> > > `Derived` here
> > > Base *b3 = d3; // note: `Derived` -> `Base` here
> > > delete[] b3; // warn: Deleting `Derived` objects as `Base` objects.
> > > ```
> > > WDYT @donat.nagy ?
> > I agree that it would be good to be good to mention the class names in the 
> > message.
> Do you also agree that we should have all steps where such a conversion 
> happened?
> Notice the 2 `note:` markers in my example. @donat.nagy 
It would be a nice addition if it wouldn't seriously complicate the 
implementation.

If we want to report multiple/all conversions, then we would need to create 
messages for back-and-forth conversions (e.g. allocating Derived, converting it 
to Base, back to Derived, back to Base, then deleting it illegally).


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

https://reviews.llvm.org/D158156

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

[clang] [clang][Interp] Add IntegralAP for arbitrary-precision integers (PR #65844)

2023-09-12 Thread Timm Baeder via cfe-commits


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

[clang] [clang][Interp] Add IntegralAP for arbitrary-precision integers (PR #65844)

2023-09-12 Thread Timm Baeder via cfe-commits


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

[clang] [clang][Interp] Add IntegralAP for arbitrary-precision integers (PR #65844)

2023-09-12 Thread Timm Baeder via cfe-commits


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

1 2 3 4 5 6 >

1 - 100 of 552 matches

Mail list logo