[PATCH] D159064: [Modules] Make clang modules for the C standard library headers

[Ian Anderson via Phabricator via cfe-commits]

iana updated this revision to Diff 556629.
iana added a comment.

Adjust for the changes in D159483 .

Mostly the header guards that were added in that review have moved to this one, 
the stdarg module needs to always be allowed, and a few tests needed to adjust 
for the stdarg/stddef implemenetation header being always modular.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159064

Files:
  clang/lib/Basic/Module.cpp
  clang/lib/Headers/__stddef_max_align_t.h
  clang/lib/Headers/__stddef_null.h
  clang/lib/Headers/__stddef_nullptr_t.h
  clang/lib/Headers/__stddef_offsetof.h
  clang/lib/Headers/__stddef_ptrdiff_t.h
  clang/lib/Headers/__stddef_rsize_t.h
  clang/lib/Headers/__stddef_size_t.h
  clang/lib/Headers/__stddef_unreachable.h
  clang/lib/Headers/__stddef_wchar_t.h
  clang/lib/Headers/__stddef_wint_t.h
  clang/lib/Headers/module.modulemap
  clang/lib/Headers/stdarg.h
  clang/lib/Headers/stddef.h
  clang/test/Headers/stdarg.c
  clang/test/Headers/stdargneeds.c
  clang/test/Headers/stddef.c
  clang/test/Headers/stddefneeds.c
  clang/test/Modules/Inputs/System/usr/include/complex.h
  clang/test/Modules/Inputs/System/usr/include/inttypes.h
  clang/test/Modules/Inputs/System/usr/include/math.h
  clang/test/Modules/Inputs/System/usr/include/module.map
  clang/test/Modules/Inputs/System/usr/include/stdint.h
  clang/test/Modules/compiler_builtins.m
  clang/test/Modules/stddef.c
  clang/test/Modules/stddef.m

Index: clang/test/Modules/stddef.m
===
--- clang/test/Modules/stddef.m
+++ clang/test/Modules/stddef.m
@@ -4,4 +4,6 @@
 
 // RUN: rm -rf %t
 // RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fbuiltin-headers-in-system-modules -fmodules-cache-path=%t -I %S/Inputs/StdDef %s -verify
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -I %S/Inputs/StdDef %s -verify
 // expected-no-diagnostics
Index: clang/test/Modules/stddef.c
===
--- clang/test/Modules/stddef.c
+++ clang/test/Modules/stddef.c
@@ -1,12 +1,22 @@
 // RUN: rm -rf %t
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fbuiltin-headers-in-system-modules -fmodules-cache-path=%t -I%S/Inputs/StdDef %s -verify -fno-modules-error-recovery
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fbuiltin-headers-in-system-modules -fmodules-cache-path=%t -I%S/Inputs/StdDef %s -verify=no-stddef-module -fno-modules-error-recovery
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -I%S/Inputs/StdDef %s -verify=yes-stddef-module -fno-modules-error-recovery
 
 #include "ptrdiff_t.h"
 
 ptrdiff_t pdt;
 
-size_t st; // expected-error {{missing '#include "include_again.h"'; 'size_t' must be declared before it is used}}
-// expected-note@__stddef_size_t.h:* {{here}}
+// size_t is declared in both size_t.h and __stddef_size_t.h, both of which are
+// modular headers. Regardless of whether stddef.h joins the StdDef test module
+// or is in its _Builtin_stddef module, __stddef_size_t.h will be in
+// _Builtin_stddef.size_t. It's not defined which module will win as the expected
+// provider of size_t. For the purposes of this test it doesn't matter which header
+// gets reported, just as long as it isn't other.h or include_again.h.
+size_t st; // no-stddef-module-error {{missing '#include "size_t.h"'; 'size_t' must be declared before it is used}} \
+  yes-stddef-module-error {{missing '#include "size_t.h"'; 'size_t' must be declared before it is used}}
+// no-stddef-module-note@size_t.h:* {{here}}
+// yes-stddef-module-note@size_t.h:* {{here}}
 
 #include "include_again.h"
 
Index: clang/test/Modules/compiler_builtins.m
===
--- clang/test/Modules/compiler_builtins.m
+++ clang/test/Modules/compiler_builtins.m
@@ -1,7 +1,7 @@
 // RUN: rm -rf %t
-// RUN: %clang_cc1 -fsyntax-only -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -I%S/Inputs/System/usr/include -verify
-// RUN: %clang_cc1 -fsyntax-only -std=c99 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -I%S/Inputs/System/usr/include -verify
-// RUN: %clang_cc1 -fsyntax-only -fmodules -fmodule-map-file=%resource_dir/module.modulemap -fmodules-cache-path=%t %s -I%S/Inputs/System/usr/include -verify
+// RUN: %clang_cc1 -fsyntax-only -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -internal-isystem %S/Inputs/System/usr/include -verify
+// RUN: %clang_cc1 -fsyntax-only -std=c99 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -internal-isystem %S/Inputs/System/usr/include -verify
+// RUN: %clang_cc1 -fsyntax-only -fmodules -fmodule-map-file=%resource_dir/module.modulemap -fmodules-cache-path=%t %s -I%S/Inputs/System/usr/include -DNO_SYSTEM_MODULES -verify
 // expected

[PATCH] D159064: [Modules] Make clang modules for the C standard library headers

[Ian Anderson via Phabricator via cfe-commits]

iana updated this revision to Diff 556630.
iana added a comment.

Actually allow the stdarg module


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159064

Files:
  clang/lib/Basic/Module.cpp
  clang/lib/Headers/__stddef_max_align_t.h
  clang/lib/Headers/__stddef_null.h
  clang/lib/Headers/__stddef_nullptr_t.h
  clang/lib/Headers/__stddef_offsetof.h
  clang/lib/Headers/__stddef_ptrdiff_t.h
  clang/lib/Headers/__stddef_rsize_t.h
  clang/lib/Headers/__stddef_size_t.h
  clang/lib/Headers/__stddef_unreachable.h
  clang/lib/Headers/__stddef_wchar_t.h
  clang/lib/Headers/__stddef_wint_t.h
  clang/lib/Headers/module.modulemap
  clang/lib/Headers/stdarg.h
  clang/lib/Headers/stddef.h
  clang/test/Headers/stdarg.c
  clang/test/Headers/stdargneeds.c
  clang/test/Headers/stddef.c
  clang/test/Headers/stddefneeds.c
  clang/test/Modules/Inputs/System/usr/include/complex.h
  clang/test/Modules/Inputs/System/usr/include/inttypes.h
  clang/test/Modules/Inputs/System/usr/include/math.h
  clang/test/Modules/Inputs/System/usr/include/module.map
  clang/test/Modules/Inputs/System/usr/include/stdint.h
  clang/test/Modules/compiler_builtins.m
  clang/test/Modules/stddef.c
  clang/test/Modules/stddef.m

Index: clang/test/Modules/stddef.m
===
--- clang/test/Modules/stddef.m
+++ clang/test/Modules/stddef.m
@@ -4,4 +4,6 @@
 
 // RUN: rm -rf %t
 // RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fbuiltin-headers-in-system-modules -fmodules-cache-path=%t -I %S/Inputs/StdDef %s -verify
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -I %S/Inputs/StdDef %s -verify
 // expected-no-diagnostics
Index: clang/test/Modules/stddef.c
===
--- clang/test/Modules/stddef.c
+++ clang/test/Modules/stddef.c
@@ -1,12 +1,22 @@
 // RUN: rm -rf %t
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fbuiltin-headers-in-system-modules -fmodules-cache-path=%t -I%S/Inputs/StdDef %s -verify -fno-modules-error-recovery
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fbuiltin-headers-in-system-modules -fmodules-cache-path=%t -I%S/Inputs/StdDef %s -verify=no-stddef-module -fno-modules-error-recovery
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -I%S/Inputs/StdDef %s -verify=yes-stddef-module -fno-modules-error-recovery
 
 #include "ptrdiff_t.h"
 
 ptrdiff_t pdt;
 
-size_t st; // expected-error {{missing '#include "include_again.h"'; 'size_t' must be declared before it is used}}
-// expected-note@__stddef_size_t.h:* {{here}}
+// size_t is declared in both size_t.h and __stddef_size_t.h, both of which are
+// modular headers. Regardless of whether stddef.h joins the StdDef test module
+// or is in its _Builtin_stddef module, __stddef_size_t.h will be in
+// _Builtin_stddef.size_t. It's not defined which module will win as the expected
+// provider of size_t. For the purposes of this test it doesn't matter which header
+// gets reported, just as long as it isn't other.h or include_again.h.
+size_t st; // no-stddef-module-error {{missing '#include "size_t.h"'; 'size_t' must be declared before it is used}} \
+  yes-stddef-module-error {{missing '#include "size_t.h"'; 'size_t' must be declared before it is used}}
+// no-stddef-module-note@size_t.h:* {{here}}
+// yes-stddef-module-note@size_t.h:* {{here}}
 
 #include "include_again.h"
 
Index: clang/test/Modules/compiler_builtins.m
===
--- clang/test/Modules/compiler_builtins.m
+++ clang/test/Modules/compiler_builtins.m
@@ -1,7 +1,7 @@
 // RUN: rm -rf %t
-// RUN: %clang_cc1 -fsyntax-only -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -I%S/Inputs/System/usr/include -verify
-// RUN: %clang_cc1 -fsyntax-only -std=c99 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -I%S/Inputs/System/usr/include -verify
-// RUN: %clang_cc1 -fsyntax-only -fmodules -fmodule-map-file=%resource_dir/module.modulemap -fmodules-cache-path=%t %s -I%S/Inputs/System/usr/include -verify
+// RUN: %clang_cc1 -fsyntax-only -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -internal-isystem %S/Inputs/System/usr/include -verify
+// RUN: %clang_cc1 -fsyntax-only -std=c99 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -internal-isystem %S/Inputs/System/usr/include -verify
+// RUN: %clang_cc1 -fsyntax-only -fmodules -fmodule-map-file=%resource_dir/module.modulemap -fmodules-cache-path=%t %s -I%S/Inputs/System/usr/include -DNO_SYSTEM_MODULES -verify
 // expected-no-diagnostics
 
 #ifdef __SSE__
@@ -11,3 +11,19 @@
 #ifdef __AVX2__
 @import _Builtin_intrinsics.intel.avx2;
 #endif
+
+#ifndef NO_SYSTEM_MODULES
+@import _Builtin_float;
+@import _Builtin_inttypes;
+@import _Builtin_iso646;
+@import _Builtin_limits;
+@import _Bui

[clang] [clang][Sema] Stop format size estimator upon %p to adapt to linux kernel's extension (PR #65969)

[Takuya Shimizu via cfe-commits]

hazohelet wrote:

Thanks for the detailed suggestion! I agree it's the appropriate approach.

I was planning to separate `Wformat-truncation` from `Wfortify-source` sometime 
after this PR (as was requested in the same issue), but now that we are going 
to introduce a new warning group, we should finish the separation before 
proceeding further on this.
Sadly we don't have any way to make stacked patches as of now, so I'll merge 
the separation change to this PR. If reviewers think it's unreasonable, let's 
make another PR for the separation then.

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

[clang-tools-extra] [clang-tidy] Fix bug in modernize-use-emplace (PR #66169)

[Piotr Zegar via cfe-commits]

@@ -247,6 +247,10 @@ Changes in existing checks
   ` to support for-loops with
   iterators initialized by free functions like ``begin``, ``end``, or ``size``.
 
+- Improved :doc:`modernize-use-emplace
+  ` to not replace aggregates that
+  ``emplace_back`` cannot construct with aggregate initialization.

PiotrZSL wrote:

use just ``emplace``, as this looks to be generic code

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

[clang-tools-extra] [clang-tidy] Fix bug in modernize-use-emplace (PR #66169)

[Piotr Zegar via cfe-commits]

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

Overall LGTM, check comments, and verify if check shouldn't be made more strict.

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

[clang-tools-extra] [clang-tidy] Fix bug in modernize-use-emplace (PR #66169)

[Piotr Zegar via cfe-commits]

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

[clang-tools-extra] [clang-tidy] Fix bug in modernize-use-emplace (PR #66169)

[Piotr Zegar via cfe-commits]

@@ -1332,6 +1337,17 @@ void testBracedInitTemporaries() {
   v3.push_back(NonTrivialWithCtor{{}});
   v3.push_back({{0}});
   v3.push_back({{}});
+
+  std::vector v4;
+
+  // These should not be noticed or fixed; after the correction, the code won't
+  // compile.
+  v4.push_back(NonTrivialWithIntAndVector{1, {}});
+  // CHECK-FIXES: v4.push_back(NonTrivialWithIntAndVector{1, {}});
+  v4.push_back(NonTrivialWithIntAndVector{});
+  // CHECK-FIXES: v4.push_back(NonTrivialWithIntAndVector{});
+  v4.push_back({});

PiotrZSL wrote:

Would be good to check if zero-initialization is involved, if it is, then it's 
may not be safe to change this into emplace_back as default constructor may not 
initialize members of class, when `{}` will zero them.

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

[clang-tools-extra] [clang-tidy] Fix bug in modernize-use-emplace (PR #66169)

[Piotr Zegar via cfe-commits]

@@ -207,11 +211,13 @@ void UseEmplaceCheck::registerMatchers(MatchFinder 
*Finder) {
   auto HasConstructExpr = has(ignoringImplicit(SoughtConstructExpr));
 
   // allow for T{} to be replaced, even if no CTOR is declared
-  auto HasConstructInitListExpr = has(initListExpr(anyOf(
-  allOf(has(SoughtConstructExpr),
-has(cxxConstructExpr(argumentCountIs(0,
-  has(cxxBindTemporaryExpr(has(SoughtConstructExpr),
-   has(cxxConstructExpr(argumentCountIs(0;
+  auto HasConstructInitListExpr =
+  has(initListExpr(anyOf(initCountIs(0), initCountIs(1)),

PiotrZSL wrote:

`initCountIs(1)` will work only if we got constructor that take that argument.

```
#include 

struct test { int a; };

int main()
{
std::vector aa;
aa.emplace_back(1);

return 0;
}
```

Code like this does not compile.

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

[clang] [clang][Sema] Rename ActOnIVar parameter (PR #66181)

[Timm Baeder via cfe-commits]

https://github.com/tbaederr created 
https://github.com/llvm/llvm-project/pull/66181:

I don't now squat about Objective C, but the extra variable (and cast) seemed 
unnecessary and this is a good opportunity to re-format that ugly parameter 
list.

>From 37501edc47aea61b09ab775dbbc36b801cc0994e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Timm=20B=C3=A4der?= 
Date: Wed, 13 Sep 2023 09:54:36 +0200
Subject: [PATCH] [clang][Sema] Rename ActOnIVar parameter

---
 clang/include/clang/Sema/Sema.h |  5 ++---
 clang/lib/Sema/SemaDecl.cpp | 12 
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 304108df9f8d029..47379e00a7445e3 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -3499,9 +3499,8 @@ class Sema final {
 
   void ActOnLastBitfield(SourceLocation DeclStart,
  SmallVectorImpl &AllIvarDecls);
-  Decl *ActOnIvar(Scope *S, SourceLocation DeclStart,
-  Declarator &D, Expr *BitfieldWidth,
-  tok::ObjCKeywordKind visibility);
+  Decl *ActOnIvar(Scope *S, SourceLocation DeclStart, Declarator &D,
+  Expr *BitWidth, tok::ObjCKeywordKind visibility);
 
   // This is used for both record definitions and ObjC interface declarations.
   void ActOnFields(Scope *S, SourceLocation RecLoc, Decl *TagDecl,
diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 59c7ce36fbff452..7fdef9ab5514757 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -18556,13 +18556,10 @@ TranslateIvarVisibility(tok::ObjCKeywordKind 
ivarVisibility) {
 
 /// ActOnIvar - Each ivar field of an objective-c class is passed into this
 /// in order to create an IvarDecl object for it.
-Decl *Sema::ActOnIvar(Scope *S,
-SourceLocation DeclStart,
-Declarator &D, Expr *BitfieldWidth,
-tok::ObjCKeywordKind Visibility) {
+Decl *Sema::ActOnIvar(Scope *S, SourceLocation DeclStart, Declarator &D,
+  Expr *BitWidth, tok::ObjCKeywordKind Visibility) {
 
   IdentifierInfo *II = D.getIdentifier();
-  Expr *BitWidth = (Expr*)BitfieldWidth;
   SourceLocation Loc = DeclStart;
   if (II) Loc = D.getIdentifierLoc();
 
@@ -18625,9 +18622,8 @@ Decl *Sema::ActOnIvar(Scope *S,
   }
 
   // Construct the decl.
-  ObjCIvarDecl *NewID = ObjCIvarDecl::Create(Context, EnclosingContext,
- DeclStart, Loc, II, T,
- TInfo, ac, (Expr *)BitfieldWidth);
+  ObjCIvarDecl *NewID = ObjCIvarDecl::Create(
+  Context, EnclosingContext, DeclStart, Loc, II, T, TInfo, ac, BitWidth);
 
   if (II) {
 NamedDecl *PrevDecl = LookupSingleName(S, II, Loc, LookupMemberName,

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

[clang] [clang][Sema] Rename ActOnIVar parameter (PR #66181)

[Timm Baeder via cfe-commits]

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

[clang] [clang][Sema] Rename ActOnIVar parameter (PR #66181)

[via cfe-commits]

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

[clang] [clang][Sema] Rename ActOnIVar parameter (PR #66181)

[via cfe-commits]

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

[clang] [clang][Sema] Rename ActOnIVar parameter (PR #66181)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang


Changes
I don't now squat about Objective C, but the extra variable (and cast) seemed 
unnecessary and this is a good opportunity to re-format that ugly parameter 
list.
--
Full diff: https://github.com/llvm/llvm-project/pull/66181.diff

2 Files Affected:

- (modified) clang/include/clang/Sema/Sema.h (+2-3) 
- (modified) clang/lib/Sema/SemaDecl.cpp (+4-8) 



diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 304108df9f8d029..47379e00a7445e3 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -3499,9 +3499,8 @@ class Sema final {
 
   void ActOnLastBitfield(SourceLocation DeclStart,
  SmallVectorImpl &AllIvarDecls);
-  Decl *ActOnIvar(Scope *S, SourceLocation DeclStart,
-  Declarator &D, Expr *BitfieldWidth,
-  tok::ObjCKeywordKind visibility);
+  Decl *ActOnIvar(Scope *S, SourceLocation DeclStart, Declarator &D,
+  Expr *BitWidth, tok::ObjCKeywordKind visibility);
 
   // This is used for both record definitions and ObjC interface declarations.
   void ActOnFields(Scope *S, SourceLocation RecLoc, Decl *TagDecl,
diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 59c7ce36fbff452..7fdef9ab5514757 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -18556,13 +18556,10 @@ TranslateIvarVisibility(tok::ObjCKeywordKind 
ivarVisibility) {
 
 /// ActOnIvar - Each ivar field of an objective-c class is passed into this
 /// in order to create an IvarDecl object for it.
-Decl *Sema::ActOnIvar(Scope *S,
-SourceLocation DeclStart,
-Declarator &D, Expr *BitfieldWidth,
-tok::ObjCKeywordKind Visibility) {
+Decl *Sema::ActOnIvar(Scope *S, SourceLocation DeclStart, Declarator &D,
+  Expr *BitWidth, tok::ObjCKeywordKind Visibility) {
 
   IdentifierInfo *II = D.getIdentifier();
-  Expr *BitWidth = (Expr*)BitfieldWidth;
   SourceLocation Loc = DeclStart;
   if (II) Loc = D.getIdentifierLoc();
 
@@ -18625,9 +18622,8 @@ Decl *Sema::ActOnIvar(Scope *S,
   }
 
   // Construct the decl.
-  ObjCIvarDecl *NewID = ObjCIvarDecl::Create(Context, EnclosingContext,
- DeclStart, Loc, II, T,
- TInfo, ac, (Expr *)BitfieldWidth);
+  ObjCIvarDecl *NewID = ObjCIvarDecl::Create(
+  Context, EnclosingContext, DeclStart, Loc, II, T, TInfo, ac, BitWidth);
 
   if (II) {
 NamedDecl *PrevDecl = LookupSingleName(S, II, Loc, LookupMemberName,




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

[clang] Implement ACLE rintn and rintnf intrinsics (PR #66112)

[David Green via cfe-commits]

https://github.com/davemgreen commented:

Could this use __builtin_roundeven directly, avoiding the need for 
__builtin_arm_rintnf?

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

[clang] [Clang] Static member initializers are not immediate escalating context. (PR #66021)

[via cfe-commits]

https://github.com/cor3ntin updated 
https://github.com/llvm/llvm-project/pull/66021:

>From a3390c4ac8bba43e73ea41f4af85b37df97b1098 Mon Sep 17 00:00:00 2001
From: Corentin Jabot 
Date: Mon, 11 Sep 2023 23:40:38 +0200
Subject: [PATCH 1/2] [Clang] Static member initializers are not immediate
 escalating context.

Per CWG2760, default members initializers should be consider
part the body of consstructors, which mean they are evaluated
in an immediate escalating context.

However, this does not apply to static members.

This patch produces some extraneous diagnostics, unfortunately
we do not have a good way to report an error back to the
initializer and this is a preexisting issue

Fixes #65985
---
 clang/docs/ReleaseNotes.rst   |  4 
 clang/lib/Parse/ParseDeclCXX.cpp  | 12 --
 .../SemaCXX/cxx2b-consteval-propagate.cpp | 23 +++
 3 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 3cdad2f7b9f0e5a..8c8ec0e11e3dd7d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -281,6 +281,10 @@ Bug Fixes to C++ Support
   a non-template inner-class between the function and the class template.
   (`#65810 `_)
 
+- Fix a crash when calling a non-constant immediate function
+  in the initializer of a static data member.
+  (`#65985 _`).
+
 Bug Fixes to AST Handling
 ^
 - Fixed an import failure of recursive friend class template.
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index 730b6e55246d6b7..b4a72d599da6655 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -3230,13 +3230,21 @@ ExprResult Parser::ParseCXXMemberInitializer(Decl *D, 
bool IsFunction,
   assert(Tok.isOneOf(tok::equal, tok::l_brace) &&
  "Data member initializer not starting with '=' or '{'");
 
+  bool IsFieldInitialization = isa_and_present(D);
+
   EnterExpressionEvaluationContext Context(
   Actions,
-  isa_and_present(D)
+  IsFieldInitialization
   ? Sema::ExpressionEvaluationContext::PotentiallyEvaluatedIfUsed
   : Sema::ExpressionEvaluationContext::PotentiallyEvaluated,
   D);
-  Actions.ExprEvalContexts.back().InImmediateEscalatingFunctionContext = true;
+
+  // CWG2760
+  // Default member initializers used to initialize a base or member subobject
+  // [...] are considered to be part of the function body
+  Actions.ExprEvalContexts.back().InImmediateEscalatingFunctionContext =
+  IsFieldInitialization;
+
   if (TryConsumeToken(tok::equal, EqualLoc)) {
 if (Tok.is(tok::kw_delete)) {
   // In principle, an initializer of '= delete p;' is legal, but it will
diff --git a/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp 
b/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp
index c5eb7f139327505..f967ce6554d777c 100644
--- a/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp
+++ b/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp
@@ -330,3 +330,26 @@ struct S {
 S s(0); // expected-note {{in the default initializer of 'j'}}
 
 }
+
+namespace GH65985 {
+
+int consteval operator""_foo(unsigned long long V) {
+return 0;
+}
+int consteval operator""_bar(unsigned long long V); // expected-note 3{{here}}
+
+struct C {
+static const int a = 1_foo;
+static constexpr int b = 1_foo;
+static const int c = 1_bar; // expected-error {{call to consteval function 
'GH65985::operator""_bar' is not a constant expression}} \
+// expected-note {{undefined function 
'operator""_bar' cannot be used in a constant expression}} \
+// expected-error {{in-class initializer for 
static data member is not a constant expression}}
+
+// FIXME: remove duplicate diagnostics
+static constexpr int d = 1_bar; // expected-error {{call to consteval 
function 'GH65985::operator""_bar' is not a constant expression}} \
+// expected-note {{undefined function 
'operator""_bar' cannot be used in a constant expression}} \
+// expected-error {{constexpr variable 'd' 
must be initialized by a constant expression}}  \
+// expected-note {{undefined function 
'operator""_bar' cannot be used in a constant expression}}
+};
+
+}

>From 12e04c8bd51d1f4e0d77969642f115b554b3a589 Mon Sep 17 00:00:00 2001
From: Corentin Jabot 
Date: Wed, 13 Sep 2023 10:10:28 +0200
Subject: [PATCH 2/2] Add more tests

---
 clang/test/SemaCXX/cxx2a-consteval.cpp| 35 +++
 .../SemaCXX/cxx2b-consteval-propagate.cpp | 23 
 2 files changed, 35 insertions(+), 23 deletions(-)

diff --git a/clang/test/SemaCXX/cxx2a-consteval.cpp 
b/clang/test/SemaCXX/cxx2a-consteval.cpp
index d98ec8048c32466..82d3212ed81

[clang] [clang][Sema] Rename ActOnIVar parameter (PR #66181)

[via cfe-commits]

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


https://github.com/llvm/llvm-project/pull/66181
___
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)

[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.

DavidSpickett wrote:

Agreed. PAuth in a generic context looks too much like a typo or abbreviation 
for the generic technique, especially in this document which points out that 
distinction.

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)

[David Spickett via cfe-commits]

https://github.com/DavidSpickett resolved 
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)

[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-tools-extra] [clang-tidy]add new check `bugprone-compare-pointer-to-member-virtual-function` (PR #66055)

[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] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

[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:

Well let me put my perspective and you can take or leave it, it's not actually 
that important overall :)

If I read "a conforming implementation is expected to", I could substitute that 
with "must do". In fact, I'd probably just write it the second way to be 100% 
clear.

Also I'm used to dealing with PAuth without supporting ABIs and at an 
architecture level no exception is raised, so I'm biased. Any real user will 
likely be seeing this via an ABI that does raise exceptions.

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

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

[David Spickett via cfe-commits]

https://github.com/DavidSpickett resolved 
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)

[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)

[David Spickett via cfe-commits]

https://github.com/DavidSpickett resolved 
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)

[David Spickett via cfe-commits]

https://github.com/DavidSpickett resolved 
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)

[David Spickett via cfe-commits]

DavidSpickett wrote:

Maybe I just need to learn how to use Github, but did half the document 
disappear?

I see a reference to the attacks section `See the section on `Attacks on 
pointer authentication`_ for more information.` but the section is gone from 
the diff even in a private window.

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][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[via cfe-commits]

https://github.com/CarolineConcatto updated 
https://github.com/llvm/llvm-project/pull/65582:

>From ae2f1bee2d912895cecb002c2434ef11da7ba3a7 Mon Sep 17 00:00:00 2001
From: Caroline Concatto 
Date: Wed, 6 Sep 2023 14:16:17 +
Subject: [PATCH] [AArch64][SME]Update intrinsic interface for ld1/st1

The new ACLE PR#225[1] now combines the slice parameters for some builtins.
This patch is the #1 of 3 patches to update the interface.

Slice specifies the ZA slice number directly and needs to be
explicity implemented by the "user" with the base register plus the
immediate offset

[1]https://github.com/ARM-software/acle/pull/225/files
---
 clang/include/clang/Basic/arm_sme.td  |  36 +++
 clang/lib/CodeGen/CGBuiltin.cpp   |  16 +--
 .../aarch64-sme-intrinsics/acle_sme_ld1.c |  58 ++
 .../acle_sme_ld1_vnum.c   |  58 ++
 .../aarch64-sme-intrinsics/acle_sme_st1.c |  58 ++
 .../acle_sme_st1_vnum.c   |  58 ++
 .../aarch64-sme-intrinsics/acle_sme_imm.cpp   | 102 +-
 .../aarch64-sme-intrinsics/acle_sme_target.c  |   8 +-
 8 files changed, 211 insertions(+), 183 deletions(-)

diff --git a/clang/include/clang/Basic/arm_sme.td 
b/clang/include/clang/Basic/arm_sme.td
index f747ccde38a3a15..58471c3dc8dd0d5 100644
--- a/clang/include/clang/Basic/arm_sme.td
+++ b/clang/include/clang/Basic/arm_sme.td
@@ -20,29 +20,29 @@ include "arm_sve_sme_incl.td"
 
 multiclass ZALoad 
ch> {
   let TargetGuard = "sme" in {
-def NAME # _H : MInst<"svld1_hor_" # n_suffix, "vimiPQ", t,
+def NAME # _H : MInst<"svld1_hor_" # n_suffix, "vimPQ", t,
   [IsLoad, IsOverloadNone, IsStreaming, IsSharedZA],
   MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _H_VNUM : MInst<"svld1_hor_vnum_" # n_suffix, "vimiPQl", t,
+def NAME # _H_VNUM : MInst<"svld1_hor_vnum_" # n_suffix, "vimPQl", t,
[IsLoad, IsOverloadNone, IsStreaming, 
IsSharedZA],
MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _V : MInst<"svld1_ver_" # n_suffix, "vimiPQ", t,
+def NAME # _V : MInst<"svld1_ver_" # n_suffix, "vimPQ", t,
   [IsLoad, IsOverloadNone, IsStreaming, IsSharedZA],
   MemEltTyDefault, i_prefix # "_vert", ch>;
 
-def NAME # _V_VNUM : MInst<"svld1_ver_vnum_" # n_suffix, "vimiPQl", t,
+def NAME # _V_VNUM : MInst<"svld1_ver_vnum_" # n_suffix, "vimPQl", t,
[IsLoad, IsOverloadNone, IsStreaming, 
IsSharedZA],
MemEltTyDefault, i_prefix # "_vert", ch>;
   }
 }
 
-defm SVLD1_ZA8 : ZALoad<"za8", "c", "aarch64_sme_ld1b", [ImmCheck<0, 
ImmCheck0_0>, ImmCheck<2, ImmCheck0_15>]>;
-defm SVLD1_ZA16 : ZALoad<"za16", "s", "aarch64_sme_ld1h", [ImmCheck<0, 
ImmCheck0_1>, ImmCheck<2, ImmCheck0_7>]>;
-defm SVLD1_ZA32 : ZALoad<"za32", "i", "aarch64_sme_ld1w", [ImmCheck<0, 
ImmCheck0_3>, ImmCheck<2, ImmCheck0_3>]>;
-defm SVLD1_ZA64 : ZALoad<"za64", "l", "aarch64_sme_ld1d", [ImmCheck<0, 
ImmCheck0_7>, ImmCheck<2, ImmCheck0_1>]>;
-defm SVLD1_ZA128 : ZALoad<"za128", "q", "aarch64_sme_ld1q", [ImmCheck<0, 
ImmCheck0_15>, ImmCheck<2, ImmCheck0_0>]>;
+defm SVLD1_ZA8 : ZALoad<"za8", "c", "aarch64_sme_ld1b", [ImmCheck<0, 
ImmCheck0_0>]>;
+defm SVLD1_ZA16 : ZALoad<"za16", "s", "aarch64_sme_ld1h", [ImmCheck<0, 
ImmCheck0_1>]>;
+defm SVLD1_ZA32 : ZALoad<"za32", "i", "aarch64_sme_ld1w", [ImmCheck<0, 
ImmCheck0_3>]>;
+defm SVLD1_ZA64 : ZALoad<"za64", "l", "aarch64_sme_ld1d", [ImmCheck<0, 
ImmCheck0_7>]>;
+defm SVLD1_ZA128 : ZALoad<"za128", "q", "aarch64_sme_ld1q", [ImmCheck<0, 
ImmCheck0_15>]>;
 
 def SVLDR_VNUM_ZA : MInst<"svldr_vnum_za", "vmiQ", "",
   [IsOverloadNone, IsStreamingCompatible, IsSharedZA],
@@ -54,29 +54,29 @@ def SVLDR_VNUM_ZA : MInst<"svldr_vnum_za", "vmiQ", "",
 
 multiclass ZAStore 
ch> {
   let TargetGuard = "sme" in {
-def NAME # _H : MInst<"svst1_hor_" # n_suffix, "vimiP%", t,
+def NAME # _H : MInst<"svst1_hor_" # n_suffix, "vimP%", t,
   [IsStore, IsOverloadNone, IsStreaming, IsSharedZA, 
IsPreservesZA],
   MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _H_VNUM : MInst<"svst1_hor_vnum_" # n_suffix, "vimiP%l", t,
+def NAME # _H_VNUM : MInst<"svst1_hor_vnum_" # n_suffix, "vimP%l", t,
[IsStore, IsOverloadNone, IsStreaming, 
IsSharedZA, IsPreservesZA],
MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _V : MInst<"svst1_ver_" # n_suffix, "vimiP%", t,
+def NAME # _V : MInst<"svst1_ver_" # n_suffix, "vimP%", t,
   [IsStore, IsOverloadNone, IsStreaming, IsSharedZA, 
IsPreservesZA],
   MemEltTyDefault, i_prefix # "_vert", ch>;
 
-def NAME # _V_VNUM : MInst<"svst1_ver_vnum_" # n_suffix, "

[libunwind] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[via cfe-commits]

https://github.com/CarolineConcatto updated 
https://github.com/llvm/llvm-project/pull/65582:

>From ae2f1bee2d912895cecb002c2434ef11da7ba3a7 Mon Sep 17 00:00:00 2001
From: Caroline Concatto 
Date: Wed, 6 Sep 2023 14:16:17 +
Subject: [PATCH] [AArch64][SME]Update intrinsic interface for ld1/st1

The new ACLE PR#225[1] now combines the slice parameters for some builtins.
This patch is the #1 of 3 patches to update the interface.

Slice specifies the ZA slice number directly and needs to be
explicity implemented by the "user" with the base register plus the
immediate offset

[1]https://github.com/ARM-software/acle/pull/225/files
---
 clang/include/clang/Basic/arm_sme.td  |  36 +++
 clang/lib/CodeGen/CGBuiltin.cpp   |  16 +--
 .../aarch64-sme-intrinsics/acle_sme_ld1.c |  58 ++
 .../acle_sme_ld1_vnum.c   |  58 ++
 .../aarch64-sme-intrinsics/acle_sme_st1.c |  58 ++
 .../acle_sme_st1_vnum.c   |  58 ++
 .../aarch64-sme-intrinsics/acle_sme_imm.cpp   | 102 +-
 .../aarch64-sme-intrinsics/acle_sme_target.c  |   8 +-
 8 files changed, 211 insertions(+), 183 deletions(-)

diff --git a/clang/include/clang/Basic/arm_sme.td 
b/clang/include/clang/Basic/arm_sme.td
index f747ccde38a3a15..58471c3dc8dd0d5 100644
--- a/clang/include/clang/Basic/arm_sme.td
+++ b/clang/include/clang/Basic/arm_sme.td
@@ -20,29 +20,29 @@ include "arm_sve_sme_incl.td"
 
 multiclass ZALoad 
ch> {
   let TargetGuard = "sme" in {
-def NAME # _H : MInst<"svld1_hor_" # n_suffix, "vimiPQ", t,
+def NAME # _H : MInst<"svld1_hor_" # n_suffix, "vimPQ", t,
   [IsLoad, IsOverloadNone, IsStreaming, IsSharedZA],
   MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _H_VNUM : MInst<"svld1_hor_vnum_" # n_suffix, "vimiPQl", t,
+def NAME # _H_VNUM : MInst<"svld1_hor_vnum_" # n_suffix, "vimPQl", t,
[IsLoad, IsOverloadNone, IsStreaming, 
IsSharedZA],
MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _V : MInst<"svld1_ver_" # n_suffix, "vimiPQ", t,
+def NAME # _V : MInst<"svld1_ver_" # n_suffix, "vimPQ", t,
   [IsLoad, IsOverloadNone, IsStreaming, IsSharedZA],
   MemEltTyDefault, i_prefix # "_vert", ch>;
 
-def NAME # _V_VNUM : MInst<"svld1_ver_vnum_" # n_suffix, "vimiPQl", t,
+def NAME # _V_VNUM : MInst<"svld1_ver_vnum_" # n_suffix, "vimPQl", t,
[IsLoad, IsOverloadNone, IsStreaming, 
IsSharedZA],
MemEltTyDefault, i_prefix # "_vert", ch>;
   }
 }
 
-defm SVLD1_ZA8 : ZALoad<"za8", "c", "aarch64_sme_ld1b", [ImmCheck<0, 
ImmCheck0_0>, ImmCheck<2, ImmCheck0_15>]>;
-defm SVLD1_ZA16 : ZALoad<"za16", "s", "aarch64_sme_ld1h", [ImmCheck<0, 
ImmCheck0_1>, ImmCheck<2, ImmCheck0_7>]>;
-defm SVLD1_ZA32 : ZALoad<"za32", "i", "aarch64_sme_ld1w", [ImmCheck<0, 
ImmCheck0_3>, ImmCheck<2, ImmCheck0_3>]>;
-defm SVLD1_ZA64 : ZALoad<"za64", "l", "aarch64_sme_ld1d", [ImmCheck<0, 
ImmCheck0_7>, ImmCheck<2, ImmCheck0_1>]>;
-defm SVLD1_ZA128 : ZALoad<"za128", "q", "aarch64_sme_ld1q", [ImmCheck<0, 
ImmCheck0_15>, ImmCheck<2, ImmCheck0_0>]>;
+defm SVLD1_ZA8 : ZALoad<"za8", "c", "aarch64_sme_ld1b", [ImmCheck<0, 
ImmCheck0_0>]>;
+defm SVLD1_ZA16 : ZALoad<"za16", "s", "aarch64_sme_ld1h", [ImmCheck<0, 
ImmCheck0_1>]>;
+defm SVLD1_ZA32 : ZALoad<"za32", "i", "aarch64_sme_ld1w", [ImmCheck<0, 
ImmCheck0_3>]>;
+defm SVLD1_ZA64 : ZALoad<"za64", "l", "aarch64_sme_ld1d", [ImmCheck<0, 
ImmCheck0_7>]>;
+defm SVLD1_ZA128 : ZALoad<"za128", "q", "aarch64_sme_ld1q", [ImmCheck<0, 
ImmCheck0_15>]>;
 
 def SVLDR_VNUM_ZA : MInst<"svldr_vnum_za", "vmiQ", "",
   [IsOverloadNone, IsStreamingCompatible, IsSharedZA],
@@ -54,29 +54,29 @@ def SVLDR_VNUM_ZA : MInst<"svldr_vnum_za", "vmiQ", "",
 
 multiclass ZAStore 
ch> {
   let TargetGuard = "sme" in {
-def NAME # _H : MInst<"svst1_hor_" # n_suffix, "vimiP%", t,
+def NAME # _H : MInst<"svst1_hor_" # n_suffix, "vimP%", t,
   [IsStore, IsOverloadNone, IsStreaming, IsSharedZA, 
IsPreservesZA],
   MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _H_VNUM : MInst<"svst1_hor_vnum_" # n_suffix, "vimiP%l", t,
+def NAME # _H_VNUM : MInst<"svst1_hor_vnum_" # n_suffix, "vimP%l", t,
[IsStore, IsOverloadNone, IsStreaming, 
IsSharedZA, IsPreservesZA],
MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _V : MInst<"svst1_ver_" # n_suffix, "vimiP%", t,
+def NAME # _V : MInst<"svst1_ver_" # n_suffix, "vimP%", t,
   [IsStore, IsOverloadNone, IsStreaming, IsSharedZA, 
IsPreservesZA],
   MemEltTyDefault, i_prefix # "_vert", ch>;
 
-def NAME # _V_VNUM : MInst<"svst1_ver_vnum_" # n_suffix, "

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

[Piotr Zegar via cfe-commits]

@@ -0,0 +1,105 @@
+//===--- 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 {
+
+namespace {
+
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
+
+static const char *const ErrorMsg =
+"A pointer to member virtual function shall only be tested for equality "
+"with null-pointer-constant.";
+
+} // namespace
+
+void ComparePointerToMemberVirtualFunctionCheck::registerMatchers(
+MatchFinder *Finder) {
+
+  auto DirectMemberVirtualFunctionPointer = unaryOperator(
+  allOf(hasOperatorName("&"),
+hasUnaryOperand(declRefExpr(to(cxxMethodDecl(isVirtual()));
+  auto IndirectMemberPointer =
+  ignoringImpCasts(declRefExpr().bind("indirect_member_pointer"));
+
+  Finder->addMatcher(
+  binaryOperator(
+  allOf(hasAnyOperatorName("==", "!="),
+hasEitherOperand(
+hasType(memberPointerType(pointee(functionType(),
+anyOf(hasEitherOperand(DirectMemberVirtualFunctionPointer),
+  hasEitherOperand(IndirectMemberPointer)),
+unless(hasEitherOperand(
+castExpr(hasCastKind(CK_NullToMemberPointer))
+  .bind("binary_operator"),
+  this);
+}
+
+void ComparePointerToMemberVirtualFunctionCheck::check(
+const MatchFinder::MatchResult &Result) {
+  const BinaryOperator *BO =
+  Result.Nodes.getNodeAs("binary_operator");
+  const DeclRefExpr *DRE =
+  Result.Nodes.getNodeAs("indirect_member_pointer");
+
+  if (DRE == nullptr) {
+// compare with pointer to member virtual function.
+diag(BO->getOperatorLoc(), ErrorMsg);
+return;
+  }
+  // compare with variable which type is pointer to member function.
+  llvm::SmallVector SameSignatureVirtualMethods{};
+  const auto *MPT = cast(DRE->getType().getCanonicalType());
+  const Type *T = MPT->getClass();
+  if (T == nullptr)
+return;
+  const CXXRecordDecl *RD = T->getAsCXXRecordDecl();
+  if (RD == nullptr)
+return;
+
+  const bool StopVisit = false;
+
+  auto VisitSameSignatureVirtualMethods =
+  [&](const CXXRecordDecl *CurrentRecordDecl) -> bool {
+bool Ret = !StopVisit;
+for (const auto *MD : CurrentRecordDecl->methods()) {
+  if (MD->isVirtual() && MD->getType() == MPT->getPointeeType()) {
+SameSignatureVirtualMethods.push_back(MD->getBeginLoc());
+Ret = StopVisit;
+  }
+}
+return Ret;
+  };
+
+  if (StopVisit != VisitSameSignatureVirtualMethods(RD)) {
+RD->forallBases(VisitSameSignatureVirtualMethods);
+  }
+
+  if (!SameSignatureVirtualMethods.empty()) {
+diag(BO->getOperatorLoc(), ErrorMsg);
+for (const auto Loc : SameSignatureVirtualMethods)
+  diag(Loc, "potential member virtual function.", DiagnosticIDs::Note);

PiotrZSL wrote:

maybe "potential member virtual function is declared here."

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)

[Piotr Zegar via cfe-commits]

@@ -0,0 +1,105 @@
+//===--- 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 {
+
+namespace {
+
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
+
+static const char *const ErrorMsg =
+"A pointer to member virtual function shall only be tested for equality "

PiotrZSL wrote:

start with small letter, maybe something with format like: "what's wrong, how 
should it be done"
like: "comparing a pointer to the virtual method '%0' with other pointer, only 
compare it with a null-pointer constant for equality."

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] f5d41c1 - [clang][Sema] Rename ActOnIVar parameter (#66181)

[via cfe-commits]

Author: Timm Baeder
Date: 2023-09-13T11:00:44+02:00
New Revision: f5d41c1dd4487e87796bf6076f2bf6f23c3f4987

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

LOG: [clang][Sema] Rename ActOnIVar parameter (#66181)

I don't now squat about Objective C, but the extra variable (and cast)
seemed unnecessary and this is a good opportunity to re-format that ugly
parameter list.

Added: 


Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaDecl.cpp

Removed: 




diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 304108df9f8d029..47379e00a7445e3 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -3499,9 +3499,8 @@ class Sema final {
 
   void ActOnLastBitfield(SourceLocation DeclStart,
  SmallVectorImpl &AllIvarDecls);
-  Decl *ActOnIvar(Scope *S, SourceLocation DeclStart,
-  Declarator &D, Expr *BitfieldWidth,
-  tok::ObjCKeywordKind visibility);
+  Decl *ActOnIvar(Scope *S, SourceLocation DeclStart, Declarator &D,
+  Expr *BitWidth, tok::ObjCKeywordKind visibility);
 
   // This is used for both record definitions and ObjC interface declarations.
   void ActOnFields(Scope *S, SourceLocation RecLoc, Decl *TagDecl,

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 59c7ce36fbff452..7fdef9ab5514757 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -18556,13 +18556,10 @@ TranslateIvarVisibility(tok::ObjCKeywordKind 
ivarVisibility) {
 
 /// ActOnIvar - Each ivar field of an objective-c class is passed into this
 /// in order to create an IvarDecl object for it.
-Decl *Sema::ActOnIvar(Scope *S,
-SourceLocation DeclStart,
-Declarator &D, Expr *BitfieldWidth,
-tok::ObjCKeywordKind Visibility) {
+Decl *Sema::ActOnIvar(Scope *S, SourceLocation DeclStart, Declarator &D,
+  Expr *BitWidth, tok::ObjCKeywordKind Visibility) {
 
   IdentifierInfo *II = D.getIdentifier();
-  Expr *BitWidth = (Expr*)BitfieldWidth;
   SourceLocation Loc = DeclStart;
   if (II) Loc = D.getIdentifierLoc();
 
@@ -18625,9 +18622,8 @@ Decl *Sema::ActOnIvar(Scope *S,
   }
 
   // Construct the decl.
-  ObjCIvarDecl *NewID = ObjCIvarDecl::Create(Context, EnclosingContext,
- DeclStart, Loc, II, T,
- TInfo, ac, (Expr *)BitfieldWidth);
+  ObjCIvarDecl *NewID = ObjCIvarDecl::Create(
+  Context, EnclosingContext, DeclStart, Loc, II, T, TInfo, ac, BitWidth);
 
   if (II) {
 NamedDecl *PrevDecl = LookupSingleName(S, II, Loc, LookupMemberName,



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

[clang] [clang][Sema] Rename ActOnIVar parameter (PR #66181)

[Timm Baeder via cfe-commits]

https://github.com/tbaederr closed 
https://github.com/llvm/llvm-project/pull/66181
___
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)

[Piotr Zegar via cfe-commits]

@@ -0,0 +1,105 @@
+//===--- 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 {
+
+namespace {
+
+AST_MATCHER(CXXMethodDecl, isVirtual) { return Node.isVirtual(); }
+
+static const char *const ErrorMsg =
+"A pointer to member virtual function shall only be tested for equality "
+"with null-pointer-constant.";
+
+} // namespace
+
+void ComparePointerToMemberVirtualFunctionCheck::registerMatchers(
+MatchFinder *Finder) {
+
+  auto DirectMemberVirtualFunctionPointer = unaryOperator(
+  allOf(hasOperatorName("&"),
+hasUnaryOperand(declRefExpr(to(cxxMethodDecl(isVirtual()));
+  auto IndirectMemberPointer =
+  ignoringImpCasts(declRefExpr().bind("indirect_member_pointer"));
+
+  Finder->addMatcher(
+  binaryOperator(
+  allOf(hasAnyOperatorName("==", "!="),
+hasEitherOperand(
+hasType(memberPointerType(pointee(functionType(),
+anyOf(hasEitherOperand(DirectMemberVirtualFunctionPointer),
+  hasEitherOperand(IndirectMemberPointer)),
+unless(hasEitherOperand(
+castExpr(hasCastKind(CK_NullToMemberPointer))
+  .bind("binary_operator"),
+  this);
+}
+
+void ComparePointerToMemberVirtualFunctionCheck::check(
+const MatchFinder::MatchResult &Result) {
+  const BinaryOperator *BO =
+  Result.Nodes.getNodeAs("binary_operator");
+  const DeclRefExpr *DRE =
+  Result.Nodes.getNodeAs("indirect_member_pointer");
+
+  if (DRE == nullptr) {
+// compare with pointer to member virtual function.
+diag(BO->getOperatorLoc(), ErrorMsg);
+return;
+  }
+  // compare with variable which type is pointer to member function.
+  llvm::SmallVector SameSignatureVirtualMethods{};
+  const auto *MPT = cast(DRE->getType().getCanonicalType());
+  const Type *T = MPT->getClass();
+  if (T == nullptr)
+return;
+  const CXXRecordDecl *RD = T->getAsCXXRecordDecl();
+  if (RD == nullptr)
+return;
+
+  const bool StopVisit = false;

PiotrZSL wrote:

const -> constexpr

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][ARM] Enable --print-supported-extensions for ARM (PR #66083)

[David Spickett via cfe-commits]

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

[clang] 99594ba - [clang][ARM] Enable --print-supported-extensions for ARM (#66083)

[via cfe-commits]

Author: David Spickett
Date: 2023-09-13T10:10:57+01:00
New Revision: 99594ba30aaba7ad7c0850923bac474e4676af8e

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

LOG: [clang][ARM] Enable --print-supported-extensions for ARM (#66083)

```
$ ./bin/clang --target=arm-linux-gnueabihf --print-supported-extensions
<...>
All available -march extensions for ARM

crc
crypto
sha2
aes
dotprod
<...>
```

This follows the format set by RISC-V and AArch64. As for AArch64, ARM
doesn't have versioned extensions like RISC-V does. So there is only 1
column, which contains the name.

Any extension without a "feature" is hidden as these cannot be used with
-march.

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/test/Driver/print-supported-extensions.c
clang/tools/driver/cc1_main.cpp
llvm/include/llvm/TargetParser/ARMTargetParser.h
llvm/lib/TargetParser/ARMTargetParser.cpp
llvm/unittests/TargetParser/TargetParserTest.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index a5f5ca29053b43b..2d42d05859bc1d3 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5271,7 +5271,7 @@ def print_supported_cpus : Flag<["-", "--"], 
"print-supported-cpus">,
   MarshallingInfoFlag>;
 def print_supported_extensions : Flag<["-", "--"], 
"print-supported-extensions">,
   Visibility<[ClangOption, CC1Option, CLOption]>,
-  HelpText<"Print supported -march extensions (RISC-V and AArch64 only)">,
+  HelpText<"Print supported -march extensions (RISC-V, AArch64 and ARM only)">,
   MarshallingInfoFlag>;
 def : Flag<["-"], "mcpu=help">, Alias;
 def : Flag<["-"], "mtune=help">, Alias;

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 9d30159b4b49cea..84b8fc7685fed42 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -4285,7 +4285,8 @@ void Driver::BuildActions(Compilation &C, DerivedArgList 
&Args,
 if (Arg *A = Args.getLastArg(Opt)) {
   if (Opt == options::OPT_print_supported_extensions &&
   !C.getDefaultToolChain().getTriple().isRISCV() &&
-  !C.getDefaultToolChain().getTriple().isAArch64()) {
+  !C.getDefaultToolChain().getTriple().isAArch64() &&
+  !C.getDefaultToolChain().getTriple().isARM()) {
 C.getDriver().Diag(diag::err_opt_not_valid_on_target)
 << "--print-supported-extensions";
 return;

diff  --git a/clang/test/Driver/print-supported-extensions.c 
b/clang/test/Driver/print-supported-extensions.c
index dcb4328726ab577..8daf4d8a34b8a60 100644
--- a/clang/test/Driver/print-supported-extensions.c
+++ b/clang/test/Driver/print-supported-extensions.c
@@ -9,6 +9,10 @@
 // RUN:   --print-supported-extensions 2>&1 | FileCheck %s --check-prefix 
RISCV %}
 // RISCV: All available -march extensions for RISC-V
 
+// RUN: %if arm-registered-target %{ %clang --target=arm-linux-gnu \
+// RUN:   --print-supported-extensions 2>&1 | FileCheck %s --check-prefix ARM 
%}
+// ARM: All available -march extensions for ARM
+
 // RUN: %if x86-registered-target %{ not %clang --target=x86_64-linux-gnu \
 // RUN:   --print-supported-extensions 2>&1 | FileCheck %s --check-prefix X86 
%}
 // X86: error: option '--print-supported-extensions' cannot be specified on 
this target
\ No newline at end of file

diff  --git a/clang/tools/driver/cc1_main.cpp b/clang/tools/driver/cc1_main.cpp
index ed68a11d0191fc9..f0d7b5c3889dc1f 100644
--- a/clang/tools/driver/cc1_main.cpp
+++ b/clang/tools/driver/cc1_main.cpp
@@ -46,6 +46,7 @@
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/Target/TargetMachine.h"
 #include "llvm/TargetParser/AArch64TargetParser.h"
+#include "llvm/TargetParser/ARMTargetParser.h"
 #include 
 
 #ifdef CLANG_HAVE_RLIMITS
@@ -202,6 +203,8 @@ static int PrintSupportedExtensions(std::string TargetStr) {
 llvm::riscvExtensionsHelp();
   else if (MachineTriple.isAArch64())
 llvm::AArch64::PrintSupportedExtensions();
+  else if (MachineTriple.isARM())
+llvm::ARM::PrintSupportedExtensions();
   else {
 // The option was already checked in Driver::HandleImmediateArgs,
 // so we do not expect to get here if we are not a supported architecture.

diff  --git a/llvm/include/llvm/TargetParser/ARMTargetParser.h 
b/llvm/include/llvm/TargetParser/ARMTargetParser.h
index 9a81415681fdb7a..37a358d1fa415c9 100644
--- a/llvm/include/llvm/TargetParser/ARMTargetParser.h
+++ b/llvm/include/llvm/TargetParser/ARMTargetParser.h
@@ -259,6 +259,8 @@ StringRef computeDefaultTargetABI(const Triple &TT, 
StringRef CPU);
 /// string then the triple's arch name is used.
 StringRef getARMCPUForArch(const llvm:

[clang] [clang][ARM] Enable --print-supported-extensions for ARM (PR #66083)

[David Spickett via cfe-commits]

https://github.com/DavidSpickett closed 
https://github.com/llvm/llvm-project/pull/66083
___
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)

[Piotr Zegar via cfe-commits]

@@ -0,0 +1,44 @@
+.. title:: clang-tidy - bugprone-compare-pointer-to-member-virtual-function
+
+bugprone-compare-pointer-to-member-virtual-function
+===
+
+Detects unspecified behavior about equality comparison between pointer to 
member virtual 
+function and anything other than null-pointer-constant.
+
+

PiotrZSL wrote:

Some information is missing here why this comparation is bad, here is some my 
suggestions:

"This detection mechanism aims to identify instances where equality comparisons 
involve pointers to member virtual functions and any entity other than a 
null-pointer constant. It is essential to highlight this concern within your 
code as it addresses potential pitfalls and risks associated with such 
comparisons.

In certain compilers, virtual function addresses are not conventional pointers 
but instead consist of offsets and indexes within a virtual function table 
(vtable). Consequently, these pointers may vary between base and derived 
classes, leading to unpredictable behavior when compared directly. This issue 
becomes particularly challenging when dealing with pointers to pure virtual 
functions, as they may not even have a valid address, further complicating 
comparisons.

Moreover, when comparing these pointers, it may inadvertently trigger "thunk" 
functions instead of the intended original functions, further compromising code 
reliability. Using this approach for comparing objects introduces a level of 
ambiguity and unpredictability, making it a less reliable choice.

Instead, it is recommended to utilize the typeid operator or other appropriate 
mechanisms for comparing objects to ensure robust and predictable behavior in 
your codebase. By heeding this detection and adopting a more reliable 
comparison method, you can mitigate potential issues related to unspecified 
behavior, especially when dealing with pointers to member virtual functions or 
pure virtual functions, thereby improving the overall stability and 
maintainability of your code."

Pickup whatever you want from it.

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)

[Piotr Zegar via cfe-commits]

@@ -0,0 +1,44 @@
+.. title:: clang-tidy - bugprone-compare-pointer-to-member-virtual-function
+
+bugprone-compare-pointer-to-member-virtual-function
+===
+
+Detects unspecified behavior about equality comparison between pointer to 
member virtual 
+function and anything other than null-pointer-constant.
+
+

PiotrZSL wrote:

Add also entry about nullptr as an solution, for example:

```
In scenarios involving pointers to member virtual functions, it's advisable to 
employ nullptr for comparisons. This approach ensures clarity, reduces 
ambiguity, and promotes code safety by explicitly checking for null pointers, 
mitigating potential issues with unspecified behavior.
```

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)

[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)

[Piotr Zegar via cfe-commits]

https://github.com/PiotrZSL commented:

Few more nits, consider improving documentation & diagnostic message.

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][dataflow] Change `diagnoseFunction` to take type of diagnostic list instead of diagnostic itself. (PR #66014)

[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:

> That's my intuition as well (that `llvm::SmallVector` is likely better). But, 
> who knows? An analysis could expect to have a non-small number of diagnostics 
> per line.

Even then, a `SmallVector` isn't a bad choice -- and potentially a better 
choice than a `std::vector`. (The "small" in `SmallVector` doesn't mean "this 
only performs well if the contents are small" -- it just means "this performs 
particularly well if the contents are small".)

The main cost of a `SmallVector` is that it occupies more memory than a 
`std::vector`. This isn't an issue here since we're allocating only one of 
these vectors at a time, on the stack. In terms of runtime, my understanding is 
that `SmallVector` is typically _faster_ than `std::vector` (for small _and_ 
large sizes). From the [LLVM Programmers' 
Manual](https://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h):

> SmallVector has grown a few other minor advantages over std::vector, causing 
> `SmallVector` to be preferred over `std::vector`."
[...]
> SmallVector understands std::is_trivially_copyable and uses realloc 
> aggressively

This talks about `SmallVector`, but this is just because for this 
general statement they're thinking about the size of the object. In our case, 
that isn't a concern, and we want to take advantage of the "small number of 
elements" optimization, so `SmallVector` seems like the right choice.

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][Sema] Stop format size estimator upon %p to adapt to linux kernel's extension (PR #65969)

[Takuya Shimizu via cfe-commits]

https://github.com/hazohelet updated 
https://github.com/llvm/llvm-project/pull/65969:

>From 5ee1a4f83c69b5e2910ea883dca7f0fa2c1a4bd3 Mon Sep 17 00:00:00 2001
From: Takuya Shimizu 
Date: Wed, 13 Sep 2023 17:43:11 +0900
Subject: [PATCH 1/2] [clang][Diagnostics] Separate Wformat-overflow and
 Wformat-truncation from Wfortify-source

Newly introduces `Wformat-overflow` and `Wformat-truncation` and imports the 
existing warning from `Wfortify-source` that correspond to GCC's counterpart so 
that they can be disabled separately from `Wfortify-source`.
---
 clang/docs/ReleaseNotes.rst   |   5 +-
 .../clang/Basic/DiagnosticSemaKinds.td|   4 +-
 clang/lib/Sema/SemaChecking.cpp   |  12 +-
 .../Sema/warn-format-overflow-truncation.c| 153 ++
 clang/test/Sema/warn-fortify-source.c |  14 +-
 5 files changed, 171 insertions(+), 17 deletions(-)
 create mode 100644 clang/test/Sema/warn-format-overflow-truncation.c

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 3cdad2f7b9f0e5a..628253c730cd1e0 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -160,9 +160,12 @@ Improvements to Clang's diagnostics
 - Clang constexpr evaluator now diagnoses compound assignment operators against
   uninitialized variables as a read of uninitialized object.
   (`#51536 `_)
-- Clang's ``-Wfortify-source`` now diagnoses ``snprintf`` call that is known to
+- Clang's ``-Wformat-truncation`` now diagnoses ``snprintf`` call that is 
known to
   result in string truncation.
   (`#64871: `_).
+  Existing warnings that similarly warn about the overflow in ``sprintf``
+  now falls under its own warning group ```-Wformat-overflow`` so that it can
+  be disabled separately from ``Wfortify-source``.
   Also clang no longer emits false positive warnings about the output length of
   ``%g`` format specifier and about ``%o, %x, %X`` with ``#`` flag.
 - Clang now emits ``-Wcast-qual`` for functional-style cast expressions.
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 0ac4df8edb242f6..7f708a5267e0052 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -857,12 +857,12 @@ def warn_fortify_strlen_overflow: Warning<
 def warn_fortify_source_format_overflow : Warning<
   "'%0' will always overflow; destination buffer has size %1,"
   " but format string expands to at least %2">,
-  InGroup;
+  InGroup>;
 
 def warn_fortify_source_format_truncation: Warning<
   "'%0' will always be truncated; specified size is %1,"
   " but format string expands to at least %2">,
-  InGroup;
+  InGroup>;
 
 def warn_fortify_scanf_overflow : Warning<
   "'%0' may overflow; destination buffer in argument %1 has size "
diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index fad70223362eddd..8260e72bd99e839 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -1350,10 +1350,14 @@ void 
Sema::checkFortifiedBuiltinMemoryFunction(FunctionDecl *FD,
 llvm::APSInt::getUnsigned(H.getSizeLowerBound())
 .extOrTrunc(SizeTypeWidth);
 if (FormatSize > *SourceSize && *SourceSize != 0) {
-  DiagID = diag::warn_fortify_source_format_truncation;
-  DestinationSize = SourceSize;
-  SourceSize = FormatSize;
-  break;
+  SmallString<16> SpecifiedSizeStr;
+  SmallString<16> FormatSizeStr;
+  SourceSize->toString(SpecifiedSizeStr, /*Radix=*/10);
+  FormatSize.toString(FormatSizeStr, /*Radix=*/10);
+  DiagRuntimeBehavior(TheCall->getBeginLoc(), TheCall,
+  
PDiag(diag::warn_fortify_source_format_truncation)
+  << GetFunctionName() << SpecifiedSizeStr
+  << FormatSizeStr);
 }
   }
 }
diff --git a/clang/test/Sema/warn-format-overflow-truncation.c 
b/clang/test/Sema/warn-format-overflow-truncation.c
new file mode 100644
index 000..dada1f9355afe07
--- /dev/null
+++ b/clang/test/Sema/warn-format-overflow-truncation.c
@@ -0,0 +1,153 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify -DUSE_BUILTINS
+// RUN: %clang_cc1 -xc++ -triple x86_64-apple-macosx10.14.0 %s -verify
+// RUN: %clang_cc1 -xc++ -triple x86_64-apple-macosx10.14.0 %s -verify 
-DUSE_BUILTINS
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 -Wno-format-truncation 
-Wno-format-overflow %s -verify=off
+// RUN: %clang_cc1 -xc++ -triple x86_64-apple-macosx10.14.0 
-Wno-format-truncation -Wno-format-overflow %s -verify=off
+
+typedef unsigned long size_t;
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+extern int sprintf(cha

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

[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:

> > That's my intuition as well (that `llvm::SmallVector` is likely better). 
> > But, who knows? An analysis could expect to have a non-small number of 
> > diagnostics per line.
> 
> Even then, a `SmallVector` isn't a bad choice -- and potentially a better 
> choice than a `std::vector`. (The "small" in `SmallVector` doesn't mean "this 
> only performs well if the contents are small" -- it just means "this performs 
> particularly well if the contents are small".)
> 
> The main cost of a `SmallVector` is that it occupies more memory than a 
> `std::vector`. This isn't an issue here since we're allocating only one of 
> these vectors at a time, on the stack. In terms of runtime, my understanding 
> is that `SmallVector` is typically _faster_ than `std::vector` (for small 
> _and_ large sizes). From the [LLVM Programmers' 
> Manual](https://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h):
> 
> > SmallVector has grown a few other minor advantages over std::vector, 
> > causing `SmallVector` to be preferred over `std::vector`."
> > [...]
> > SmallVector understands std::is_trivially_copyable and uses realloc 
> > aggressively
> 
> This talks about `SmallVector`, but this is just because for this 
> general statement they're thinking about the size of the object. In our case, 
> that isn't a concern, and we want to take advantage of the "small number of 
> elements" optimization, so `SmallVector` seems like the right choice.

So bottom line, I don't expect anyone to ever want to use `std::vector` here.

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][Sema] Fix a bug when instantiating a lambda with requires clause (PR #65193)

[via cfe-commits]

0x59616e wrote:

> There is also the question of what happen in the deeply nested case
> 
> ```c++
> int foo(auto...);
> auto f(auto... a) {
>return [] {
>return [] () requires requires { foo(a...) ;} {};
>}();
> }
> 
> auto g = f()();
> ```
> 
> we may have to visit all functions recursively from the bottom up to add 
> their locals / parameters / captures

How deep the nested level should we support ? Support for two levels is easy, 
but three (or more) levels is complicated. I wonder whether the three (or more) 
nested levels is common enough that deserves the support. Any thought ?

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

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

[via cfe-commits]

https://github.com/martinboehme deleted 
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] [analyzer] Fix StdLibraryFunctionsChecker crash on surprising sink node (PR #66109)

[Balázs Kéri via cfe-commits]

@@ -1427,8 +1427,13 @@ void StdLibraryFunctionsChecker::checkPostCall(const 
CallEvent &Call,
 });
 Pred = C.addTransition(NewState, Pred, Tag);
   }
-  if (!Pred)
+  if (!Pred || Pred->isSink()) {
+// Pred may be:
+//  - a nullpointer, when the generated node is not new;
+//  - a sink, when NewState is posteriorly overconstrained.
+// In these situations we cannot add the errno note tag.

balazske wrote:

I like more if the comment is added before the `if` and the braces are not 
added.

https://github.com/llvm/llvm-project/pull/66109
___
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)

[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)

[via cfe-commits]

martinboehme wrote:

> Updated to enforce llvm::SmallVector, per Martin's recommendation. PTAL.

LGTM, but note that the PR title is now out of date.



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][Sema] Stop format size estimator upon %p to adapt to linux kernel's extension (PR #65969)

[Takuya Shimizu via cfe-commits]

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

[clang] [clang][Sema] Stop format size estimator upon %p to adapt to linux kernel's extension (PR #65969)

[Takuya Shimizu via cfe-commits]

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

[clang] [clang][Sema] Stop format size estimator upon %p to adapt to linux kernel's extension (PR #65969)

[Takuya Shimizu via cfe-commits]

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

[clang] [clang][Sema] Stop format size estimator upon %p to adapt to linux kernel's extension (PR #65969)

[Takuya Shimizu via cfe-commits]

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

[clang] [analyzer] Fix StdLibraryFunctionsChecker crash on surprising sink node (PR #66109)

[via cfe-commits]

https://github.com/DonatNagyE updated 
https://github.com/llvm/llvm-project/pull/66109:

>From b5c45907b0a5c075dfdbd7f6b3727634d976787b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?= 
Date: Tue, 12 Sep 2023 18:07:34 +0200
Subject: [PATCH] [analyzer] Fix StdLibraryFunctionsChecker crash on surprising
 sink node

Recent changes in StdLibraryFunctionsChecker introduced a situation
where the checker sequentially performed two state transitions to add
two separate note tags.

In the unlikely case when the updated state (the variable `NewState`)
was posteriorly overconstrained, the engine marked the node after the
first state transition as a sink to stop the "natural" graph exploration
after that point.

However, in this particular case the checker tried to directly add a
second node, and this triggered an assertion in the `addPredecessor()`
method of `ExplodedNode`.

This commit introduces an explicit `isSink()` check to avoid this crash.
To avoid similar bugs in the future, perhaps it would be possible to
tweak `addTransition()` and ensure that it returns `nullptr` when it
would return a sink node (to unify the two possible error conditions).

This crash was observed in an analysis of the curl project (in a very
long and complex function), and there I validated that this is the root
cause, but I don't have a self-contained testcase that can trigger the
creation of a PosteriorlyOverconstrained node in this situation.
---
 .../Checkers/StdLibraryFunctionsChecker.cpp   | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
index f5f6e3a91237686..13bb9cef5e490ed 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -1387,8 +1387,8 @@ void StdLibraryFunctionsChecker::checkPostCall(const 
CallEvent &Call,
 if (!NewState)
   continue;
 
-// It is possible that NewState == State is true.
-// It can occur if another checker has applied the state before us.
+// Here it's possible that NewState == State, e.g. when other checkers
+// already applied the same constraints (or stricter ones).
 // Still add these note tags, the other checker should add only its
 // specialized note tags. These general note tags are handled always by
 // StdLibraryFunctionsChecker.
@@ -1427,7 +1427,12 @@ void StdLibraryFunctionsChecker::checkPostCall(const 
CallEvent &Call,
 });
 Pred = C.addTransition(NewState, Pred, Tag);
   }
-  if (!Pred)
+
+  // Pred may be:
+  //  - a nullpointer, if we reach an already existing node 
(theoretically);
+  //  - a sink, when NewState is posteriorly overconstrained.
+  // In these situations we cannot add the errno note tag.
+  if (!Pred || Pred->isSink())
 continue;
 }
 

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

[PATCH] D158169: [X86] Fix i128 argument passing under SysV ABI

[Ralf via Phabricator via cfe-commits]

RalfJung added a comment.

> I think the CCIfSplit means it was larger than i64 to start.

What about the case where R9  would 
take the *second* half of a split i128 (i.e., the value gets split across R8 
 and R9 
)? Does that still work after this 
patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158169

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

[clang] [analyzer] Fix StdLibraryFunctionsChecker crash on surprising sink node (PR #66109)

[via cfe-commits]

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

[clang] [analyzer] Fix StdLibraryFunctionsChecker crash on surprising sink node (PR #66109)

[via cfe-commits]

@@ -1427,8 +1427,13 @@ void StdLibraryFunctionsChecker::checkPostCall(const 
CallEvent &Call,
 });
 Pred = C.addTransition(NewState, Pred, Tag);
   }
-  if (!Pred)
+  if (!Pred || Pred->isSink()) {
+// Pred may be:
+//  - a nullpointer, when the generated node is not new;
+//  - a sink, when NewState is posteriorly overconstrained.
+// In these situations we cannot add the errno note tag.

DonatNagyE wrote:

I updated the patch.

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

[clang] Implement ACLE rintn and rintnf intrinsics (PR #66112)

[Simon Pilgrim via cfe-commits]

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

[clang] Implement ACLE rintn and rintnf intrinsics (PR #66112)

[Simon Pilgrim via cfe-commits]

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

[clang] [dataflow] Add global condition to DataflowAnalysisContext (PR #65949)

[Sam McCall via cfe-commits]

@@ -108,6 +108,16 @@ class DataflowAnalysisContext {
   /// A null `PointeeType` can be used for the pointee of `std::nullptr_t`.
   PointerValue &getOrCreateNullPointerValue(QualType PointeeType);
 
+  /// Adds `Constraint` to current and future flow conditions in this context.
+  ///
+  /// The global condition must contain only flow-insensitive information, i.e.

sam-mccall wrote:

This is a much more accurate descriptor, but IME "flow insensitive" is not good 
as an actual name. We used "non-flow-sensitive" extensively in nullability and 
gradually phasing it out in favor of the "type" metaphor, as after many months 
reading it still requires "deciphering". Mostly it's too long, it's a negative 
definition, and too technical I think.
The parallel between `addFlowConditionConstraint` and 
`addFlowInsensitiveInvariant` is also IMO not clear enough. (I'd be in favor of 
dropping "Constraint" from both, but that's a different change)

I've tried `Common` instead of `Global` which might more clearly emphasize the 
sharing that happens here - WDYT?
If you feel strongly about `FlowInsensitive` I can use that, it might be more 
consistent with the framework's style.

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

[clang] [dataflow] Add global condition to DataflowAnalysisContext (PR #65949)

[Sam McCall via cfe-commits]

@@ -172,27 +179,33 @@ bool DataflowAnalysisContext::equivalentFormulas(const 
Formula &Val1,
 }
 
 void DataflowAnalysisContext::addTransitiveFlowConditionConstraints(
-Atom Token, llvm::SetVector &Constraints,
-llvm::DenseSet &VisitedTokens) {
-  auto Res = VisitedTokens.insert(Token);
-  if (!Res.second)
-return;
-
-  auto ConstraintsIt = FlowConditionConstraints.find(Token);
-  if (ConstraintsIt == FlowConditionConstraints.end()) {
-Constraints.insert(&arena().makeAtomRef(Token));
-  } else {
-// Bind flow condition token via `iff` to its set of constraints:
-// FC <=> (C1 ^ C2 ^ ...), where Ci are constraints
-Constraints.insert(&arena().makeEquals(arena().makeAtomRef(Token),
-   *ConstraintsIt->second));
-  }
+Atom Token, llvm::SetVector &Constraints) {
+  llvm::DenseSet AddedTokens;
+  std::vector Remaining = {Token};
+
+  if (GlobalConstraints)
+Constraints.insert(GlobalConstraints);
+  // Define all the flow conditions that might be referenced in constraints.
+  while (!Remaining.empty()) {
+auto Token = Remaining.back();
+Remaining.pop_back();
+if (!AddedTokens.insert(Token).second)
+  continue;
+
+auto ConstraintsIt = FlowConditionConstraints.find(Token);
+if (ConstraintsIt == FlowConditionConstraints.end()) {
+  Constraints.insert(&arena().makeAtomRef(Token));
+} else {
+  // Bind flow condition token via `iff` to its set of constraints:
+  // FC <=> (C1 ^ C2 ^ ...), where Ci are constraints
+  Constraints.insert(&arena().makeEquals(arena().makeAtomRef(Token),
+ *ConstraintsIt->second));
+}
 
-  auto DepsIt = FlowConditionDeps.find(Token);
-  if (DepsIt != FlowConditionDeps.end()) {
-for (Atom DepToken : DepsIt->second) {
-  addTransitiveFlowConditionConstraints(DepToken, Constraints,
-VisitedTokens);
+if (auto DepsIt = FlowConditionDeps.find(Token);
+DepsIt != FlowConditionDeps.end()) {
+  for (Atom A : DepsIt->second)
+Remaining.push_back(A);

sam-mccall wrote:

This would also IMO be less readable, due to the line split between init and 
condition in the `if`.
I think this falls under "has complex conditionals" in the style guide

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

[clang] [dataflow] Add global condition to DataflowAnalysisContext (PR #65949)

[Sam McCall via cfe-commits]

@@ -172,27 +179,33 @@ bool DataflowAnalysisContext::equivalentFormulas(const 
Formula &Val1,
 }
 
 void DataflowAnalysisContext::addTransitiveFlowConditionConstraints(
-Atom Token, llvm::SetVector &Constraints,
-llvm::DenseSet &VisitedTokens) {
-  auto Res = VisitedTokens.insert(Token);
-  if (!Res.second)
-return;
-
-  auto ConstraintsIt = FlowConditionConstraints.find(Token);
-  if (ConstraintsIt == FlowConditionConstraints.end()) {
-Constraints.insert(&arena().makeAtomRef(Token));
-  } else {
-// Bind flow condition token via `iff` to its set of constraints:
-// FC <=> (C1 ^ C2 ^ ...), where Ci are constraints
-Constraints.insert(&arena().makeEquals(arena().makeAtomRef(Token),
-   *ConstraintsIt->second));
-  }
+Atom Token, llvm::SetVector &Constraints) {
+  llvm::DenseSet AddedTokens;
+  std::vector Remaining = {Token};
+
+  if (GlobalConstraints)
+Constraints.insert(GlobalConstraints);
+  // Define all the flow conditions that might be referenced in constraints.
+  while (!Remaining.empty()) {
+auto Token = Remaining.back();
+Remaining.pop_back();
+if (!AddedTokens.insert(Token).second)
+  continue;
+
+auto ConstraintsIt = FlowConditionConstraints.find(Token);
+if (ConstraintsIt == FlowConditionConstraints.end()) {
+  Constraints.insert(&arena().makeAtomRef(Token));
+} else {
+  // Bind flow condition token via `iff` to its set of constraints:
+  // FC <=> (C1 ^ C2 ^ ...), where Ci are constraints
+  Constraints.insert(&arena().makeEquals(arena().makeAtomRef(Token),
+ *ConstraintsIt->second));
+}

sam-mccall wrote:

braces are required here because the `else` has a comment and the `then` should 
be consistent with it

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

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

[clang] [dataflow] Add global condition to DataflowAnalysisContext (PR #65949)

[Sam McCall via cfe-commits]

@@ -150,7 +157,7 @@ bool DataflowAnalysisContext::flowConditionImplies(Atom 
Token,
   Constraints.insert(&arena().makeAtomRef(Token));
   Constraints.insert(&arena().makeNot(Val));
   llvm::DenseSet VisitedTokens;

sam-mccall wrote:

Indeed, oops!

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

[clang] [dataflow] Add global condition to DataflowAnalysisContext (PR #65949)

[Sam McCall via cfe-commits]

https://github.com/sam-mccall updated 
https://github.com/llvm/llvm-project/pull/65949:

>From 1d765a3b22cd81d6739a20f2b2f7b68935773f2a Mon Sep 17 00:00:00 2001
From: Sam McCall 
Date: Mon, 11 Sep 2023 13:21:11 +0200
Subject: [PATCH 1/3] [dataflow] Add global condition to
 DataflowAnalysisContext

This records facts that are not sensitive to the current flow condition,
and should apply to all environments.

The motivating case is recording information about where a Value
originated, such as nullability:
 - we may see the same Value for multiple expressions (e.g. reads of the
   same field) in multiple environments (multiple blocks or iterations)
 - we want to record information only when we first see the Value
   (e.g. Nullability annotations on fields only add information if we
   don't know where the value came from)
 - this information should be expressible as a SAT condition
 - we must add this SAT condition to every environment where the
   Value may appear

We solve this by recording the information in the global condition.
This doesn't seem particularly elegant, but solves the problem and is
a fairly small and natural extension of the Environment.

Alternatives considered:
 - store the constraint directly as a property on the Value.
   But it's more composable for such properties to always be variables
   (AtomicBoolValue), and constrain them with SAT conditions.
 - add a hook whenever values are created, giving the analysis the
   chance to populate them.
   However the framework relies on/provides the ability to construct
   values in arbitrary places without providing the context such a hook
   would need, this would be a very invasive change.
---
 .../FlowSensitive/DataflowAnalysisContext.h   | 20 +--
 .../FlowSensitive/DataflowAnalysisContext.cpp | 60 +++
 .../DataflowAnalysisContextTest.cpp   | 16 +
 3 files changed, 66 insertions(+), 30 deletions(-)

diff --git 
a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
index 685bbe486b54e1f..8ff7e584887241a 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
@@ -108,6 +108,14 @@ class DataflowAnalysisContext {
   /// A null `PointeeType` can be used for the pointee of `std::nullptr_t`.
   PointerValue &getOrCreateNullPointerValue(QualType PointeeType);
 
+  /// Adds `Constraint` to current and future flow conditions in this context.
+  ///
+  /// This must be used with care: the constraint must be truly global across
+  /// the analysis, and should not invalidate the result of past logic.
+  ///
+  /// Adding constraints on freshly created boolean variables is generally 
safe.
+  void addGlobalConstraint(const Formula &Constraint);
+
   /// Adds `Constraint` to the flow condition identified by `Token`.
   void addFlowConditionConstraint(Atom Token, const Formula &Constraint);
 
@@ -174,12 +182,11 @@ class DataflowAnalysisContext {
   void addModeledFields(const FieldSet &Fields);
 
   /// Adds all constraints of the flow condition identified by `Token` and all
-  /// of its transitive dependencies to `Constraints`. `VisitedTokens` is used
-  /// to track tokens of flow conditions that were already visited by recursive
-  /// calls.
-  void addTransitiveFlowConditionConstraints(
-  Atom Token, llvm::SetVector &Constraints,
-  llvm::DenseSet &VisitedTokens);
+  /// of its transitive dependencies to `Constraints`.
+  void
+  addTransitiveFlowConditionConstraints(Atom Token,
+llvm::SetVector &Out);
+
 
   /// Returns true if the solver is able to prove that there is no satisfying
   /// assignment for `Constraints`
@@ -224,6 +231,7 @@ class DataflowAnalysisContext {
   // dependencies is stored in the `FlowConditionDeps` map.
   llvm::DenseMap> FlowConditionDeps;
   llvm::DenseMap FlowConditionConstraints;
+  const Formula *GlobalConstraints = nullptr;
 
   llvm::DenseMap FunctionContexts;
 
diff --git a/clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
index 47a994f4bbdb6a1..f2b3207609801e4 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
@@ -104,6 +104,13 @@ 
DataflowAnalysisContext::getOrCreateNullPointerValue(QualType PointeeType) {
   return *Res.first->second;
 }
 
+void DataflowAnalysisContext::addGlobalConstraint(const Formula &Constraint) {
+  if (GlobalConstraints == nullptr)
+GlobalConstraints = &Constraint;
+  else
+GlobalConstraints = &arena().makeAnd(*GlobalConstraints, Constraint);
+}
+
 void DataflowAnalysisContext::addFlowConditionConstraint(
 Atom Token, const Formula &Constraint) {
   auto Res = FlowConditionConstraints.try_emplace(Token, &Constraint);
@@ -150,7 +157,7 @@ bool DataflowA

[clang] [dataflow] Add global condition to DataflowAnalysisContext (PR #65949)

[Sam McCall via cfe-commits]

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

[clang] [dataflow] Add global condition to DataflowAnalysisContext (PR #65949)

[Sam McCall via cfe-commits]

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

[PATCH] D159103: [Driver][HLSL] Improve diagnostics for invalid shader model and stage

[Nathan Gauër via Phabricator via cfe-commits]

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

LGTM from the SPIR-V side. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159103

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

[clang-tools-extra] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[via cfe-commits]

https://github.com/CarolineConcatto updated 
https://github.com/llvm/llvm-project/pull/65582:

>From ae2f1bee2d912895cecb002c2434ef11da7ba3a7 Mon Sep 17 00:00:00 2001
From: Caroline Concatto 
Date: Wed, 6 Sep 2023 14:16:17 +
Subject: [PATCH 1/2] [AArch64][SME]Update intrinsic interface for ld1/st1

The new ACLE PR#225[1] now combines the slice parameters for some builtins.
This patch is the #1 of 3 patches to update the interface.

Slice specifies the ZA slice number directly and needs to be
explicity implemented by the "user" with the base register plus the
immediate offset

[1]https://github.com/ARM-software/acle/pull/225/files
---
 clang/include/clang/Basic/arm_sme.td  |  36 +++
 clang/lib/CodeGen/CGBuiltin.cpp   |  16 +--
 .../aarch64-sme-intrinsics/acle_sme_ld1.c |  58 ++
 .../acle_sme_ld1_vnum.c   |  58 ++
 .../aarch64-sme-intrinsics/acle_sme_st1.c |  58 ++
 .../acle_sme_st1_vnum.c   |  58 ++
 .../aarch64-sme-intrinsics/acle_sme_imm.cpp   | 102 +-
 .../aarch64-sme-intrinsics/acle_sme_target.c  |   8 +-
 8 files changed, 211 insertions(+), 183 deletions(-)

diff --git a/clang/include/clang/Basic/arm_sme.td 
b/clang/include/clang/Basic/arm_sme.td
index f747ccde38a3a15..58471c3dc8dd0d5 100644
--- a/clang/include/clang/Basic/arm_sme.td
+++ b/clang/include/clang/Basic/arm_sme.td
@@ -20,29 +20,29 @@ include "arm_sve_sme_incl.td"
 
 multiclass ZALoad 
ch> {
   let TargetGuard = "sme" in {
-def NAME # _H : MInst<"svld1_hor_" # n_suffix, "vimiPQ", t,
+def NAME # _H : MInst<"svld1_hor_" # n_suffix, "vimPQ", t,
   [IsLoad, IsOverloadNone, IsStreaming, IsSharedZA],
   MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _H_VNUM : MInst<"svld1_hor_vnum_" # n_suffix, "vimiPQl", t,
+def NAME # _H_VNUM : MInst<"svld1_hor_vnum_" # n_suffix, "vimPQl", t,
[IsLoad, IsOverloadNone, IsStreaming, 
IsSharedZA],
MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _V : MInst<"svld1_ver_" # n_suffix, "vimiPQ", t,
+def NAME # _V : MInst<"svld1_ver_" # n_suffix, "vimPQ", t,
   [IsLoad, IsOverloadNone, IsStreaming, IsSharedZA],
   MemEltTyDefault, i_prefix # "_vert", ch>;
 
-def NAME # _V_VNUM : MInst<"svld1_ver_vnum_" # n_suffix, "vimiPQl", t,
+def NAME # _V_VNUM : MInst<"svld1_ver_vnum_" # n_suffix, "vimPQl", t,
[IsLoad, IsOverloadNone, IsStreaming, 
IsSharedZA],
MemEltTyDefault, i_prefix # "_vert", ch>;
   }
 }
 
-defm SVLD1_ZA8 : ZALoad<"za8", "c", "aarch64_sme_ld1b", [ImmCheck<0, 
ImmCheck0_0>, ImmCheck<2, ImmCheck0_15>]>;
-defm SVLD1_ZA16 : ZALoad<"za16", "s", "aarch64_sme_ld1h", [ImmCheck<0, 
ImmCheck0_1>, ImmCheck<2, ImmCheck0_7>]>;
-defm SVLD1_ZA32 : ZALoad<"za32", "i", "aarch64_sme_ld1w", [ImmCheck<0, 
ImmCheck0_3>, ImmCheck<2, ImmCheck0_3>]>;
-defm SVLD1_ZA64 : ZALoad<"za64", "l", "aarch64_sme_ld1d", [ImmCheck<0, 
ImmCheck0_7>, ImmCheck<2, ImmCheck0_1>]>;
-defm SVLD1_ZA128 : ZALoad<"za128", "q", "aarch64_sme_ld1q", [ImmCheck<0, 
ImmCheck0_15>, ImmCheck<2, ImmCheck0_0>]>;
+defm SVLD1_ZA8 : ZALoad<"za8", "c", "aarch64_sme_ld1b", [ImmCheck<0, 
ImmCheck0_0>]>;
+defm SVLD1_ZA16 : ZALoad<"za16", "s", "aarch64_sme_ld1h", [ImmCheck<0, 
ImmCheck0_1>]>;
+defm SVLD1_ZA32 : ZALoad<"za32", "i", "aarch64_sme_ld1w", [ImmCheck<0, 
ImmCheck0_3>]>;
+defm SVLD1_ZA64 : ZALoad<"za64", "l", "aarch64_sme_ld1d", [ImmCheck<0, 
ImmCheck0_7>]>;
+defm SVLD1_ZA128 : ZALoad<"za128", "q", "aarch64_sme_ld1q", [ImmCheck<0, 
ImmCheck0_15>]>;
 
 def SVLDR_VNUM_ZA : MInst<"svldr_vnum_za", "vmiQ", "",
   [IsOverloadNone, IsStreamingCompatible, IsSharedZA],
@@ -54,29 +54,29 @@ def SVLDR_VNUM_ZA : MInst<"svldr_vnum_za", "vmiQ", "",
 
 multiclass ZAStore 
ch> {
   let TargetGuard = "sme" in {
-def NAME # _H : MInst<"svst1_hor_" # n_suffix, "vimiP%", t,
+def NAME # _H : MInst<"svst1_hor_" # n_suffix, "vimP%", t,
   [IsStore, IsOverloadNone, IsStreaming, IsSharedZA, 
IsPreservesZA],
   MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _H_VNUM : MInst<"svst1_hor_vnum_" # n_suffix, "vimiP%l", t,
+def NAME # _H_VNUM : MInst<"svst1_hor_vnum_" # n_suffix, "vimP%l", t,
[IsStore, IsOverloadNone, IsStreaming, 
IsSharedZA, IsPreservesZA],
MemEltTyDefault, i_prefix # "_horiz", ch>;
 
-def NAME # _V : MInst<"svst1_ver_" # n_suffix, "vimiP%", t,
+def NAME # _V : MInst<"svst1_ver_" # n_suffix, "vimP%", t,
   [IsStore, IsOverloadNone, IsStreaming, IsSharedZA, 
IsPreservesZA],
   MemEltTyDefault, i_prefix # "_vert", ch>;
 
-def NAME # _V_VNUM : MInst<"svst1_ver_vnum_" # n_suffi

[clang-tools-extra] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[via cfe-commits]

@@ -20,8 +20,10 @@
 // CHECK-NEXT:ret void
 //
 ARM_STREAMING_ATTR void test_svld1_hor_za8(uint32_t slice_base, svbool_t pg, 
const void *ptr) {
-  svld1_hor_za8(0, slice_base, 0, pg, ptr);
-  svld1_hor_za8(0, slice_base, 15, pg, ptr);
+  uint32_t slice = slice_base;

CarolineConcatto wrote:

I removed from all the codegen tests the variable. 

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

[libunwind] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[via cfe-commits]

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

[clang-tools-extra] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[via cfe-commits]

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

[clang-tools-extra] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[via cfe-commits]

https://github.com/CarolineConcatto resolved 
https://github.com/llvm/llvm-project/pull/65582
___
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 ld1/st1 (PR #65582)

[Sander de Smalen via cfe-commits]

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

LGTM with nit addressed!

https://github.com/llvm/llvm-project/pull/65582
___
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 ld1/st1 (PR #65582)

[Sander de Smalen via cfe-commits]

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

[clang-tools-extra] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[Sander de Smalen via cfe-commits]

@@ -84,8 +76,8 @@ ARM_STREAMING_ATTR void test_svld1_hor_za64(uint32_t 
slice_base, svbool_t pg, co
 //
 ARM_STREAMING_ATTR void test_svld1_hor_za128(uint32_t slice_base, svbool_t pg, 
const void *ptr) {
   uint32_t slice = slice_base;
-  svld1_hor_za128(0, slice, pg, ptr);
-  svld1_hor_za128(15, slice, pg, ptr);
+  svld1_hor_za128(0, slice_base, pg, ptr);

sdesmalen-arm wrote:

```uint32_t slice = slice_base;```
nit: unused variable

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

[libunwind] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[Sander de Smalen via cfe-commits]

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

LGTM with nit addressed!

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

[clang-tools-extra] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[Sander de Smalen via cfe-commits]

https://github.com/sdesmalen-arm edited 
https://github.com/llvm/llvm-project/pull/65582
___
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 ld1/st1 (PR #65582)

[Sander de Smalen via cfe-commits]

@@ -84,8 +76,8 @@ ARM_STREAMING_ATTR void test_svld1_hor_za64(uint32_t 
slice_base, svbool_t pg, co
 //
 ARM_STREAMING_ATTR void test_svld1_hor_za128(uint32_t slice_base, svbool_t pg, 
const void *ptr) {
   uint32_t slice = slice_base;
-  svld1_hor_za128(0, slice, pg, ptr);
-  svld1_hor_za128(15, slice, pg, ptr);
+  svld1_hor_za128(0, slice_base, pg, ptr);

sdesmalen-arm wrote:

```uint32_t slice = slice_base;```
nit: unused variable

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

[clang-tools-extra] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[Sander de Smalen via cfe-commits]

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

LGTM with nit addressed!

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

[libunwind] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[Sander de Smalen via cfe-commits]

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

[libunwind] [AArch64][SME]Update intrinsic interface for ld1/st1 (PR #65582)

[Sander de Smalen via cfe-commits]

@@ -84,8 +76,8 @@ ARM_STREAMING_ATTR void test_svld1_hor_za64(uint32_t 
slice_base, svbool_t pg, co
 //
 ARM_STREAMING_ATTR void test_svld1_hor_za128(uint32_t slice_base, svbool_t pg, 
const void *ptr) {
   uint32_t slice = slice_base;
-  svld1_hor_za128(0, slice, pg, ptr);
-  svld1_hor_za128(15, slice, pg, ptr);
+  svld1_hor_za128(0, slice_base, pg, ptr);

sdesmalen-arm wrote:

```uint32_t slice = slice_base;```
nit: unused variable

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

[clang] [clang-tidy] Add performance-move-smart-pointer-contents check. (PR #66139)

[via cfe-commits]

martinboehme wrote:

> > I don't see problem described by this check as an performance issue. For 
> > example:
> > ```
> > std::unique_ptr> ptr;
> > std::vector local = std::move(*ptr);
> > ```
> > 
> > 
> > 
> >   
> > 
> > 
> >   
> > 
> > 
> > 
> >   
> > No performance issue here, simply value may need to be moved, do not expect 
> > that someone have to always keep object in unique_ptr, at some point it may 
> > need to be moved/copied. And some types may be cheap to move.
> > As for std::shared_ptr, yes this could be a problem.
> > My suggestion is:
> > 
> > * Part related to moving object from a std::shared_ptr should be a 
> > bugprone-moved-from-shared check (or some other name).
> > * As for current check, I fear that it may cause lot of false-positives, 
> > and basicly it should work only on "heavy" types,  but it could be hard to 
> > detect such heavy types. But still I don't think why that part should be 
> > reduced to just shared ptr, check that would detect std::move calls that 
> > are still heavy, simply because moved class is above XYZ bytes in size.
> 
> @martinboehme internally suggested putting this in the performance category; 
> perhaps he has a more detailed rationale or some relevant thoughts?

While it's true, as @PiotrZSL points out here and in another comment, that a 
class being "heavyweight" (i.e. expensive to move) is not the only reason to 
put it behind a `unique_ptr`, I would argue that it's the overwhelmingly common 
reason.

Quoting a counterexample from a different comment:

```cxx
std::unique_ptr> ptr;
std::vector local = std::move(*ptr);
```

Why would someone ever put a `std::vector` behind a `std::unique_ptr` to begin 
with?[^1] It costs an extra allocation and every access incurs an extra 
indirection. Granted, moving a `std::unique_ptr` requires copying only a single 
machine word as opposed to three for a `std::vector`, but surely the cases 
where this makes `std::unique_ptr` the right tradeoff are the 
exception?

So I think that if we want to recommend to the user to do `std::move(p)` 
instead of `std::move(*p)`, it's because we assume that it's cheaper to move 
the `unique_ptr` rather than the contents. There's a question of how often this 
recommendation will be right (I think it will very rarely be wrong), but in any 
case, the reason we're making the recommendation is performance, so this seems 
the right category for the check.

`shared_ptr`, on the other hand, is definitely a different case, and I agree 
that "bugprone" seems like a better category.

[^1]: Let's disregard custom deleters. These show up as a template argument, so 
if we're concerned about them, we should simply check that there is no custom 
deleter.

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

[clang] [Sema] add cast from IncompleteArrayType to ConstantArrayType in TryReferenceListInitialization (PR #65918)

[Mariya Podchishchaeva via cfe-commits]

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

[clang] [Sema] add cast from IncompleteArrayType to ConstantArrayType in TryReferenceListInitialization (PR #65918)

[Mariya Podchishchaeva via cfe-commits]

@@ -4532,6 +4532,15 @@ static void TryReferenceListInitialization(Sema &S,
   if (T1Quals.hasAddressSpace())
 Sequence.AddQualificationConversionStep(
 cv1T1, DestType->isRValueReferenceType() ? VK_XValue : VK_LValue);
+  else if (S.getLangOpts().CPlusPlus20 &&
+   isa(T1->getUnqualifiedDesugaredType()) &&
+   DestType->isRValueReferenceType()) {
+// [dcl.init.list] p3.10

Fznamznon wrote:

NIT
```suggestion
// C++20 [dcl.init.list]p3.10:
```

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

[clang] [Sema] add cast from IncompleteArrayType to ConstantArrayType in TryReferenceListInitialization (PR #65918)

[Mariya Podchishchaeva via cfe-commits]

@@ -4532,6 +4532,15 @@ static void TryReferenceListInitialization(Sema &S,
   if (T1Quals.hasAddressSpace())
 Sequence.AddQualificationConversionStep(
 cv1T1, DestType->isRValueReferenceType() ? VK_XValue : VK_LValue);
+  else if (S.getLangOpts().CPlusPlus20 &&
+   isa(T1->getUnqualifiedDesugaredType()) &&
+   DestType->isRValueReferenceType()) {
+// [dcl.init.list] p3.10
+// unless T is “reference to array of unknown bound of U”, in which 
case
+// the type of the prvalue is the type of x in the declaration U x[] H,
+// where H is the initializer list.
+Sequence.AddQualificationConversionStep(cv1T1, VK_XValue);

Fznamznon wrote:

Is qualification conversion right here? I'm not sure we convert qualifiers here.


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

[clang] [Sema] add cast from IncompleteArrayType to ConstantArrayType in TryReferenceListInitialization (PR #65918)

[Mariya Podchishchaeva via cfe-commits]

https://github.com/Fznamznon commented:

This needs a release note.

cc @erichkeane 

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

[clang] [clang-tidy] Add performance-move-smart-pointer-contents check. (PR #66139)

[via cfe-commits]

martinboehme wrote:

> This check has issue in my opinion, the semantic of `std::move(*p)` is not 
> same as `*std::move(p)`

Agree that the suggested fix may not always be correct.

I would suggest simply not emitting a suggested fix (i.e. only emitting a 
warning).

https://github.com/llvm/llvm-project/pull/66139
___
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 performance-move-smart-pointer-contents check. (PR #66139)

[via cfe-commits]

martinboehme wrote:

> This check has issue in my opinion, the semantic of `std::move(*p)` is not 
> same as `*std::move(p)`

Agree that the suggested fix may not always be correct.

I would suggest simply not emitting a suggested fix (i.e. only emitting a 
warning).

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

[clang] [clang-tidy] Add performance-move-smart-pointer-contents check. (PR #66139)

[via cfe-commits]

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

[clang] [clang-tidy] Add performance-move-smart-pointer-contents check. (PR #66139)

[via cfe-commits]

@@ -0,0 +1,95 @@
+//===--- MoveSmartPointerContentsCheck.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 
+
+<<< HEAD
+#include "MoveSmartPointerContentsCheck.h"
+#include "../utils/Matchers.h"
+#include "../utils/OptionsUtils.h"
+===
+#include "../utils/Matchers.h"
+#include "../utils/OptionsUtils.h"
+#include "MoveSmartPointerContentsCheck.h"
+>>> b0179a7f3cac ([clang-tidy] Add performance-move-smart-pointer-contents 
check.)
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Lex/Lexer.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::performance {
+
+bool MoveSmartPointerContentsCheck::isLanguageVersionSupported(
+const LangOptions &LangOptions) const {
+  if (!LangOptions.CPlusPlus) {
+return false;
+  }

martinboehme wrote:

If you're checking for `CPlusPlus11` anyway, I believe this is redundant.

https://github.com/llvm/llvm-project/pull/66139
___
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 performance-move-smart-pointer-contents check. (PR #66139)

[via cfe-commits]

@@ -0,0 +1,95 @@
+//===--- MoveSmartPointerContentsCheck.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 
+
+<<< HEAD
+#include "MoveSmartPointerContentsCheck.h"
+#include "../utils/Matchers.h"
+#include "../utils/OptionsUtils.h"
+===
+#include "../utils/Matchers.h"
+#include "../utils/OptionsUtils.h"
+#include "MoveSmartPointerContentsCheck.h"
+>>> b0179a7f3cac ([clang-tidy] Add performance-move-smart-pointer-contents 
check.)

martinboehme wrote:

It looks as if you've got remnants of a merge conflict here?

https://github.com/llvm/llvm-project/pull/66139
___
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 performance-move-smart-pointer-contents check. (PR #66139)

[via cfe-commits]

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


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

[clang] [clang-tidy] Add performance-move-smart-pointer-contents check. (PR #66139)

[via cfe-commits]

@@ -0,0 +1,95 @@
+//===--- MoveSmartPointerContentsCheck.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 
+
+<<< HEAD
+#include "MoveSmartPointerContentsCheck.h"
+#include "../utils/Matchers.h"
+#include "../utils/OptionsUtils.h"
+===
+#include "../utils/Matchers.h"
+#include "../utils/OptionsUtils.h"
+#include "MoveSmartPointerContentsCheck.h"
+>>> b0179a7f3cac ([clang-tidy] Add performance-move-smart-pointer-contents 
check.)
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Lex/Lexer.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::performance {
+
+bool MoveSmartPointerContentsCheck::isLanguageVersionSupported(
+const LangOptions &LangOptions) const {
+  if (!LangOptions.CPlusPlus) {
+return false;
+  }
+
+  // Anything after C++11 is fine.
+  return LangOptions.CPlusPlus11;
+}
+
+MoveSmartPointerContentsCheck::MoveSmartPointerContentsCheck(
+StringRef Name, ClangTidyContext *Context)
+: ClangTidyCheck(Name, Context),
+  UniquePointerClasses(utils::options::parseStringList(
+  Options.get("UniquePointerClasses", "std::unique_ptr"))),
+  SharedPointerClasses(utils::options::parseStringList(
+  Options.get("SharedPointerClasses", "std::shared_ptr"))) {}
+
+void MoveSmartPointerContentsCheck::storeOptions(
+ClangTidyOptions::OptionMap &Opts) {
+  Options.store(Opts, "UniquePtrClasses",
+utils::options::serializeStringList(UniquePointerClasses));
+  Options.store(Opts, "SharedPtrClasses",
+utils::options::serializeStringList(SharedPointerClasses));
+}
+
+void MoveSmartPointerContentsCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(
+  callExpr(
+  callee(functionDecl(hasName("std::move"))),
+  hasArgument(
+  0,
+  anyOf(cxxOperatorCallExpr(hasOperatorName("*"),
+hasDeclaration(cxxMethodDecl(namedDecl(
+matchers::matchesAnyListedName(
+UniquePointerClasses)

martinboehme wrote:

I believe the canonical way of doing this is:

```
cxxOperatorCallExpr(hasOverloadedOperatorName("*"),
  
callee(cxxMethodDecl(ofClass(matchers::matchesAnyListedName(
UniquePointerClasses);
```

https://github.com/llvm/llvm-project/pull/66139
___
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 performance-move-smart-pointer-contents check. (PR #66139)

[via cfe-commits]

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

[clang] [clang-tidy] Add performance-move-smart-pointer-contents check. (PR #66139)

[via cfe-commits]

@@ -0,0 +1,95 @@
+//===--- MoveSmartPointerContentsCheck.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 
+
+<<< HEAD
+#include "MoveSmartPointerContentsCheck.h"
+#include "../utils/Matchers.h"
+#include "../utils/OptionsUtils.h"
+===
+#include "../utils/Matchers.h"
+#include "../utils/OptionsUtils.h"
+#include "MoveSmartPointerContentsCheck.h"
+>>> b0179a7f3cac ([clang-tidy] Add performance-move-smart-pointer-contents 
check.)

martinboehme wrote:

It looks as if you've got remnants of a merge conflict here?

https://github.com/llvm/llvm-project/pull/66139
___
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 performance-move-smart-pointer-contents check. (PR #66139)

[Piotr Zegar via cfe-commits]

PiotrZSL wrote:

Other common example from me:
```
struct SomeHeavyClass {};

std::unique_ptr build();

void sendMsg()
{
auto msgContent = build();
Message msg;
msg.content = std::move(*msgContent);
send(msg);
}
```

And next one:
```
struct Info {
   virtual const std::string& getInfo();
};

struct
```

Simply moving a content of unique ptr is not an issue for me, coping big 
structure is.
User may want to move part of object from unique_ptr

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

[PATCH] D157205: [clangd] Add hexadecimal member offsets and sizes to hover popup

[tetra via Phabricator via cfe-commits]

tetraxile added a comment.

Just bumping this patch, I'd like if it could get reviewed before Phabricator 
becomes read-only.


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

https://reviews.llvm.org/D157205

___
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

[Sergio Afonso via Phabricator via cfe-commits]

skatrak added a comment.

Thank you for the review. After I address your last comment my plan is to land 
this and the other two accepted REQUIRES patches that depended on it.

Is there a preferred approach as to how to go about it? I could rebase them all 
and wait until the pre-merge builds finish without errors and then land them in 
quick succession or I could go one by one to make sure post-merge builds don't 
find any issues before landing the next, which will be over a couple of days 
most likely.




Comment at: flang/lib/Lower/Bridge.cpp:2366-2367
 mlir::OpBuilder::InsertPoint insertPt = builder->saveInsertionPoint();
+analyzeOpenMPDeclarativeConstruct(*this, getEval(), ompDecl,
+  ompDeviceCodeFound);
 genOpenMPDeclarativeConstruct(*this, getEval(), ompDecl);

kiranchandramohan wrote:
> Can this be rewritten this way.
> 
> And rename `analyzeOpenMPDeclarativeConstruct` to `isTargetDeclare` or 
> something like that?
My idea was to make it generic to allow the analysis of other declarative 
constructs in the future there as well, that's the reason for the function name 
and returning through an output argument. But I'll follow your suggestion, 
since we don't know for sure that we'll need this later on.


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

[clang] 88b7e06 - Revert "[clang][CodeGen] Emit annotations for function declarations."

[Benjamin Kramer via cfe-commits]

Author: Benjamin Kramer
Date: 2023-09-13T13:22:57+02:00
New Revision: 88b7e06dcf9723d0869b0c6bee030b4140e4366d

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

LOG: Revert "[clang][CodeGen] Emit annotations for function declarations."

This reverts commit c6a33ff49dfb3498dae15c718820ea3d9c19f3cb. Makes
clang segfault.

// clang t.cc
class a;
class c {
 public:
  [[clang::annotate("")]] c(const c *) {}
};
class d {
  d(const c *, a *, a *);
  c e;
};
d::d(const c *f, a *, a *) : e(f) {}

Added: 


Modified: 
clang/lib/CodeGen/CodeGenModule.cpp
clang/lib/CodeGen/CodeGenModule.h
clang/test/CodeGen/annotations-global.c
clang/test/CodeGenCXX/attr-annotate.cpp

Removed: 
clang/test/CodeGen/annotations-decl-use-decl.c
clang/test/CodeGen/annotations-decl-use-define.c
clang/test/CodeGen/annotations-declaration.c
clang/test/CodeGenCXX/attr-annotate-destructor.cpp



diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 0ee9c4a9e0be4c9..8b0c9340775cbe9 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -697,7 +697,6 @@ void CodeGenModule::checkAliases() {
 void CodeGenModule::clear() {
   DeferredDeclsToEmit.clear();
   EmittedDeferredDecls.clear();
-  DeferredAnnotations.clear();
   if (OpenMPRuntime)
 OpenMPRuntime->clear();
 }
@@ -3094,10 +3093,6 @@ void CodeGenModule::EmitVTablesOpportunistically() {
 }
 
 void CodeGenModule::EmitGlobalAnnotations() {
-  for (const auto& [MangledName, VD] : DeferredAnnotations)
-AddGlobalAnnotations(VD, GetGlobalValue(MangledName));
-  DeferredAnnotations.clear();
-
   if (Annotations.empty())
 return;
 
@@ -3602,14 +3597,6 @@ void CodeGenModule::EmitGlobal(GlobalDecl GD) {
 
   // Ignore declarations, they will be emitted on their first use.
   if (const auto *FD = dyn_cast(Global)) {
-// Update deferred annotations with the latest declaration if the function
-// function was already used or defined.
-if (FD->hasAttr()) {
-  StringRef MangledName = getMangledName(GD);
-  if (GetGlobalValue(MangledName))
-DeferredAnnotations[MangledName] = FD;
-}
-
 // Forward declarations are emitted lazily on first use.
 if (!FD->doesThisDeclarationHaveABody()) {
   if (!FD->doesDeclarationForceExternallyVisibleDefinition())
@@ -4383,11 +4370,6 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
   llvm::Function::Create(FTy, llvm::Function::ExternalLinkage,
  Entry ? StringRef() : MangledName, &getModule());
 
-  // Store the declaration associated with this function so it is potentially
-  // updated by further declarations or definitions and emitted at the end.
-  if (D && D->hasAttr())
-DeferredAnnotations[MangledName] = cast(D);
-
   // If we already created a function with the same mangled name (but 
diff erent
   // type) before, take its name and add it to the list of functions to be
   // replaced with F at the end of CodeGen.
@@ -5682,6 +5664,8 @@ void 
CodeGenModule::EmitGlobalFunctionDefinition(GlobalDecl GD,
 AddGlobalCtor(Fn, CA->getPriority());
   if (const DestructorAttr *DA = D->getAttr())
 AddGlobalDtor(Fn, DA->getPriority(), true);
+  if (D->hasAttr())
+AddGlobalAnnotations(D, Fn);
   if (getLangOpts().OpenMP && D->hasAttr())
 getOpenMPRuntime().emitDeclareTargetFunction(D, GV);
 }

diff  --git a/clang/lib/CodeGen/CodeGenModule.h 
b/clang/lib/CodeGen/CodeGenModule.h
index 8b0d68afbd0ecd2..073b471c6e3cc11 100644
--- a/clang/lib/CodeGen/CodeGenModule.h
+++ b/clang/lib/CodeGen/CodeGenModule.h
@@ -431,10 +431,6 @@ class CodeGenModule : public CodeGenTypeCache {
   /// Global annotations.
   std::vector Annotations;
 
-  // Store deferred function annotations so they can be emitted at the end with
-  // most up to date ValueDecl that will have all the inherited annotations.
-  llvm::DenseMap DeferredAnnotations;
-
   /// Map used to get unique annotation strings.
   llvm::StringMap AnnotationStrings;
 

diff  --git a/clang/test/CodeGen/annotations-decl-use-decl.c 
b/clang/test/CodeGen/annotations-decl-use-decl.c
deleted file mode 100644
index f43ba91a34d876f..000
--- a/clang/test/CodeGen/annotations-decl-use-decl.c
+++ /dev/null
@@ -1,16 +0,0 @@
-// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s
-
-// Test annotation attributes are still emitted when the function is used 
before
-// it is defined with annotations.
-
-void foo(void);
-void *xxx = (void*)foo;
-void __attribute__((annotate("bar"))) foo();
-
-// CHECK: target triple
-// CHECK-DAG: private unnamed_addr constant [4 x i8] c"bar\00", section 
"llvm.metadata"
-
-// CHECK: @llvm.global.annotations = appending global [1 x { ptr, ptr, ptr, 
i32, ptr }] [{
-// CHE

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

[Kiran Chandramohan via Phabricator via cfe-commits]

kiranchandramohan added a comment.

In D147218#4645055 , @skatrak wrote:

> Thank you for the review. After I address your last comment my plan is to 
> land this and the other two accepted REQUIRES patches that depended on it.
>
> Is there a preferred approach as to how to go about it? I could rebase them 
> all and wait until the pre-merge builds finish without errors and then land 
> them in quick succession or I could go one by one to make sure post-merge 
> builds don't find any issues before landing the next, which will be over a 
> couple of days most likely.

Both are fine. I would recommend the former.


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] D156172: [clang][CodeGen] Emit annotations for function declarations.

[Benjamin Kramer via Phabricator via cfe-commits]

bkramer added a comment.

Reverted this in 88b7e06dcf9723d0869b0c6bee030b4140e4366d 
 as it 
makes clang crash. Reduced test case in the commit description.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156172

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