[clang] [clang] NFCI: remove obsolete workaround for template default arguments (PR #94311)

2024-06-04 Thread Haojian Wu via cfe-commits

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

Thanks for the cleanup, this looks good to me.

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


[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)

2024-06-04 Thread Michael Kruse via cfe-commits

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


[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)

2024-06-04 Thread Michael Kruse via cfe-commits

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


[clang] [clang-format] Add SpacesInParensOption for filtering repeated parens (PR #77522)

2024-06-04 Thread Alibek Omarov via cfe-commits

a1batross wrote:

> I saw some comments on this. Looks like some were deleted maybe. This is 
> still in my queue, but unclear when I'll get back to it.

Yeah, sorry, I posted a comment here but decided it was a bit irrelevant. :)

But going to ask anyway then. Can this setting remove the space from repeated 
parentheses pattern like this?

```c
foo( (void *)buf, size );
```

to:

```c
foo((void *)buf, size );
```

So it does remove it on one side where the C-style cast parentheses, but 
doesn't on the other side?

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


[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

2024-06-04 Thread James Henderson via cfe-commits

jh7370 wrote:

> (Friendly Ping:)

Sorry, a combination of PTO and other factors have delayed me in getting to 
this. It's on my radar, but will likely be a few more days before I can sink my 
teeth into more complex reviews like this.

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


[clang] 799ae77 - [NFC] [Serialization] Avoid unnecessary check for if Identifier from AST

2024-06-04 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-06-04T15:28:24+08:00
New Revision: 799ae77993fa5d7b0638f10b3895090f8748de92

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

LOG: [NFC] [Serialization] Avoid unnecessary check for if Identifier from AST

Inspired by the review process in
https://github.com/llvm/llvm-project/pull/92085.

The check `ID >= FirstIdentID` can cover the following check
`!II->isFromAST()`.

Added: 


Modified: 
clang/lib/Serialization/ASTWriter.cpp

Removed: 




diff  --git a/clang/lib/Serialization/ASTWriter.cpp 
b/clang/lib/Serialization/ASTWriter.cpp
index 4f1d2c532bc91..b8b613db712f4 100644
--- a/clang/lib/Serialization/ASTWriter.cpp
+++ b/clang/lib/Serialization/ASTWriter.cpp
@@ -3895,8 +3895,7 @@ void ASTWriter::WriteIdentifierTable(Preprocessor &PP,
 
   // Write out identifiers if either the ID is local or the identifier has
   // changed since it was loaded.
-  if (ID >= FirstIdentID || !Chain || !II->isFromAST() ||
-  II->hasChangedSinceDeserialization() ||
+  if (ID >= FirstIdentID || II->hasChangedSinceDeserialization() ||
   (Trait.needDecls() &&
II->hasFETokenInfoChangedSinceDeserialization()))
 Generator.insert(II, ID, Trait);



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


[clang] [Serialization] No transitive identifier change (PR #92085)

2024-06-04 Thread Chuanqi Xu via cfe-commits


@@ -3896,7 +3903,7 @@ void ASTWriter::WriteIdentifierTable(Preprocessor &PP,
 
   // Write out identifiers if either the ID is local or the identifier has
   // changed since it was loaded.
-  if (ID >= FirstIdentID || !Chain || !II->isFromAST() ||
+  if (isLocalIdentifierID(ID) || !Chain || !II->isFromAST() ||

ChuanqiXu9 wrote:

Nice catch! The  `!II->isFromAST()` check looks redundant indeed. I've made a 
NFC patch to address this:  
https://github.com/llvm/llvm-project/commit/799ae77993fa5d7b0638f10b3895090f8748de92

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


[clang] [clang] fix parsing typeid with pack index (PR #94299)

2024-06-04 Thread via cfe-commits

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


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


[clang] ade4259 - [clang] Fix parsing a typeid containing a pack indexing expression (#94299)

2024-06-04 Thread via cfe-commits

Author: c8ef
Date: 2024-06-04T09:34:21+02:00
New Revision: ade4259d75d61d4366538b5ee975cac606d43d3c

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

LOG: [clang] Fix parsing a typeid containing a pack indexing expression (#94299)

Fixes #93650

Added: 


Modified: 
clang/lib/AST/Expr.cpp
clang/test/SemaCXX/cxx2c-pack-indexing.cpp

Removed: 




diff  --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index ac0b1b38f0162..f9d634550dc06 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -3618,12 +3618,10 @@ bool Expr::HasSideEffects(const ASTContext &Ctx,
   case ConceptSpecializationExprClass:
   case RequiresExprClass:
   case SYCLUniqueStableNameExprClass:
+  case PackIndexingExprClass:
 // These never have a side-effect.
 return false;
 
-  case PackIndexingExprClass:
-return cast(this)->getSelectedExpr()->HasSideEffects(
-Ctx, IncludePossibleEffects);
   case ConstantExprClass:
 // FIXME: Move this into the "return false;" block above.
 return cast(this)->getSubExpr()->HasSideEffects(

diff  --git a/clang/test/SemaCXX/cxx2c-pack-indexing.cpp 
b/clang/test/SemaCXX/cxx2c-pack-indexing.cpp
index 28b9765127f4e..9ea90a4c3e30f 100644
--- a/clang/test/SemaCXX/cxx2c-pack-indexing.cpp
+++ b/clang/test/SemaCXX/cxx2c-pack-indexing.cpp
@@ -221,3 +221,13 @@ void f( ) {
 
 
 }
+
+namespace std {
+struct type_info {
+  const char *name;
+};
+} // namespace std
+
+namespace GH93650 {
+auto func(auto... inputArgs) { return typeid(inputArgs...[0]); }
+} // namespace GH93650



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


[clang] [clang] fix parsing typeid with pack index (PR #94299)

2024-06-04 Thread via cfe-commits

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


[clang] [clang] fix parsing typeid with pack index (PR #94299)

2024-06-04 Thread via cfe-commits

github-actions[bot] wrote:



@c8ef Congratulations on having your first Pull Request (PR) merged into the 
LLVM Project!

Your changes will be combined with recent changes from other authors, then 
tested
by our [build bots](https://lab.llvm.org/buildbot/). If there is a problem with 
a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as
the builds can include changes from many authors. It is not uncommon for your
change to be included in a build that fails due to someone else's changes, or
infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail 
[here](https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr).

If your change does cause a problem, it may be reverted, or you can revert it 
yourself.
This is a normal part of [LLVM 
development](https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy).
 You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are 
working as expected, well done!


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


[clang] [clang] NFCI: remove obsolete workaround for template default arguments (PR #94311)

2024-06-04 Thread via cfe-commits

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


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


[clang] 6bc71ba - [Clang] \ is not valid in a raw string literal (#93867)

2024-06-04 Thread via cfe-commits

Author: cor3ntin
Date: 2024-06-04T09:35:35+02:00
New Revision: 6bc71bac8728b30b560f7ae210917072b01b8046

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

LOG: [Clang] \ is not valid in a raw string literal (#93867)

Fix regression introduced by #93216

Added: 


Modified: 
clang/include/clang/Basic/CharInfo.h
clang/test/Lexer/cxx2c-raw-strings.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/CharInfo.h 
b/clang/include/clang/Basic/CharInfo.h
index d71857e8e5dcc..87626eeb8a700 100644
--- a/clang/include/clang/Basic/CharInfo.h
+++ b/clang/include/clang/Basic/CharInfo.h
@@ -176,7 +176,7 @@ LLVM_READONLY inline bool isRawStringDelimBody(unsigned 
char c) {
   using namespace charinfo;
   return (InfoTable[c] & (CHAR_UPPER | CHAR_LOWER | CHAR_PERIOD | CHAR_DIGIT |
   CHAR_UNDER | CHAR_PUNCT)) != 0 &&
- c != '(' && c != ')';
+ c != '(' && c != ')' && c != '\\';
 }
 
 enum class EscapeChar {

diff  --git a/clang/test/Lexer/cxx2c-raw-strings.cpp 
b/clang/test/Lexer/cxx2c-raw-strings.cpp
index 569a4b8447e57..a1e971434e244 100644
--- a/clang/test/Lexer/cxx2c-raw-strings.cpp
+++ b/clang/test/Lexer/cxx2c-raw-strings.cpp
@@ -1,12 +1,24 @@
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify -Wc++26-extensions %s
-// RUN: %clang_cc1 -std=c++2c -fsyntax-only -verify=cxx26 -Wpre-c++26-compat %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=precxx26,expected 
-Wc++26-extensions %s
+// RUN: %clang_cc1 -std=c++2c -fsyntax-only -verify=cxx26,expected 
-Wpre-c++26-compat %s
 
 int main() {
   (void) R"abc`@$(foobar)abc`@$";
-  //expected-warning@-1 {{'`' in a raw string literal delimiter is a C++2c 
extension}}
-  //expected-warning@-2 {{'@' in a raw string literal delimiter is a C++2c 
extension}}
-  //expected-warning@-3 {{'$' in a raw string literal delimiter is a C++2c 
extension}}
+  //precxx26-warning@-1 {{'`' in a raw string literal delimiter is a C++2c 
extension}}
+  //precxx26-warning@-2 {{'@' in a raw string literal delimiter is a C++2c 
extension}}
+  //precxx26-warning@-3 {{'$' in a raw string literal delimiter is a C++2c 
extension}}
   //cxx26-warning@-4 {{'`' in a raw string literal delimiter is incompatible 
with standards before C++2c}}
   //cxx26-warning@-5 {{'@' in a raw string literal delimiter is incompatible 
with standards before C++2c}}
   //cxx26-warning@-6 {{'$' in a raw string literal delimiter is incompatible 
with standards before C++2c}}
+
+  (void) R"\t()\t";
+  // expected-error@-1 {{invalid character '\' in raw string delimiter}}
+  // expected-error@-2 {{expected expression}}
+
+  (void) R" () ";
+  // expected-error@-1 {{invalid character ' ' in raw string delimiter}}
+  // expected-error@-2 {{expected expression}}
+
+  (void) R"\()\";
+  // expected-error@-1 {{invalid character '\' in raw string delimiter}}
+  // expected-error@-2 {{expected expression}}
 }



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


[clang] [Clang] \ is not valid in a raw string literal (PR #93867)

2024-06-04 Thread via cfe-commits

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


[clang] [Serialization] No transitive identifier change (PR #92085)

2024-06-04 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/92085

>From e8f756ec7f8ea7e5bf18cc122a965fb2f258fd15 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Tue, 14 May 2024 15:33:12 +0800
Subject: [PATCH] [Serialization] No transitive identifier change

---
 .../clang/Lex/ExternalPreprocessorSource.h|  54 -
 clang/include/clang/Lex/HeaderSearch.h|  12 +-
 .../include/clang/Serialization/ASTBitCodes.h |   2 +-
 clang/include/clang/Serialization/ASTReader.h |  19 ++-
 .../include/clang/Serialization/ModuleFile.h  |   3 -
 clang/lib/Lex/HeaderSearch.cpp|  33 +++---
 clang/lib/Serialization/ASTReader.cpp |  98 
 clang/lib/Serialization/ASTWriter.cpp |  63 ++
 clang/lib/Serialization/GlobalModuleIndex.cpp |   3 +-
 clang/lib/Serialization/ModuleFile.cpp|   1 -
 .../no-transitive-identifier-change.cppm  | 110 ++
 11 files changed, 286 insertions(+), 112 deletions(-)
 create mode 100644 clang/test/Modules/no-transitive-identifier-change.cppm

diff --git a/clang/include/clang/Lex/ExternalPreprocessorSource.h 
b/clang/include/clang/Lex/ExternalPreprocessorSource.h
index 6775841860373..48429948dbffe 100644
--- a/clang/include/clang/Lex/ExternalPreprocessorSource.h
+++ b/clang/include/clang/Lex/ExternalPreprocessorSource.h
@@ -36,12 +36,64 @@ class ExternalPreprocessorSource {
   /// Return the identifier associated with the given ID number.
   ///
   /// The ID 0 is associated with the NULL identifier.
-  virtual IdentifierInfo *GetIdentifier(unsigned ID) = 0;
+  virtual IdentifierInfo *GetIdentifier(uint64_t ID) = 0;
 
   /// Map a module ID to a module.
   virtual Module *getModule(unsigned ModuleID) = 0;
 };
 
+// Either a pointer to an IdentifierInfo of the controlling macro or the ID
+// number of the controlling macro.
+class LazyIdentifierInfoPtr {
+  // If the low bit is clear, a pointer to the IdentifierInfo. If the low
+  // bit is set, the upper 63 bits are the ID number.
+  mutable uint64_t Ptr = 0;
+
+public:
+  LazyIdentifierInfoPtr() = default;
+
+  explicit LazyIdentifierInfoPtr(const IdentifierInfo *Ptr)
+  : Ptr(reinterpret_cast(Ptr)) {}
+
+  explicit LazyIdentifierInfoPtr(uint64_t ID) : Ptr((ID << 1) | 0x01) {
+assert((ID << 1 >> 1) == ID && "ID must require < 63 bits");
+if (ID == 0)
+  Ptr = 0;
+  }
+
+  LazyIdentifierInfoPtr &operator=(const IdentifierInfo *Ptr) {
+this->Ptr = reinterpret_cast(Ptr);
+return *this;
+  }
+
+  LazyIdentifierInfoPtr &operator=(uint64_t ID) {
+assert((ID << 1 >> 1) == ID && "IDs must require < 63 bits");
+if (ID == 0)
+  Ptr = 0;
+else
+  Ptr = (ID << 1) | 0x01;
+
+return *this;
+  }
+
+  /// Whether this pointer is non-NULL.
+  ///
+  /// This operation does not require the AST node to be deserialized.
+  bool isValid() const { return Ptr != 0; }
+
+  /// Whether this pointer is currently stored as ID.
+  bool isID() const { return Ptr & 0x01; }
+
+  IdentifierInfo *getPtr() const {
+assert(!isID());
+return reinterpret_cast(Ptr);
+  }
+
+  uint64_t getID() const {
+assert(isID());
+return Ptr >> 1;
+  }
+};
 }
 
 #endif
diff --git a/clang/include/clang/Lex/HeaderSearch.h 
b/clang/include/clang/Lex/HeaderSearch.h
index 5ac634d4e..65700b8f9dc11 100644
--- a/clang/include/clang/Lex/HeaderSearch.h
+++ b/clang/include/clang/Lex/HeaderSearch.h
@@ -16,6 +16,7 @@
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Lex/DirectoryLookup.h"
+#include "clang/Lex/ExternalPreprocessorSource.h"
 #include "clang/Lex/HeaderMap.h"
 #include "clang/Lex/ModuleMap.h"
 #include "llvm/ADT/ArrayRef.h"
@@ -119,13 +120,6 @@ struct HeaderFileInfo {
   LLVM_PREFERRED_TYPE(bool)
   unsigned IsValid : 1;
 
-  /// The ID number of the controlling macro.
-  ///
-  /// This ID number will be non-zero when there is a controlling
-  /// macro whose IdentifierInfo may not yet have been loaded from
-  /// external storage.
-  unsigned ControllingMacroID = 0;
-
   /// If this file has a \#ifndef XXX (or equivalent) guard that
   /// protects the entire contents of the file, this is the identifier
   /// for the macro that controls whether or not it has any effect.
@@ -134,7 +128,7 @@ struct HeaderFileInfo {
   /// the controlling macro of this header, since
   /// getControllingMacro() is able to load a controlling macro from
   /// external storage.
-  const IdentifierInfo *ControllingMacro = nullptr;
+  LazyIdentifierInfoPtr LazyControllingMacro;
 
   /// If this header came from a framework include, this is the name
   /// of the framework.
@@ -580,7 +574,7 @@ class HeaderSearch {
   /// no-op \#includes.
   void SetFileControllingMacro(FileEntryRef File,
const IdentifierInfo *ControllingMacro) {
-getFileInfo(File).ControllingMacro = ControllingMacro;
+getFileInfo(File).LazyControllingMacro = ControllingMacro;
   }
 

[clang] [clang][RISCV] Update vcpop.v C interface to follow the nameing convention (PR #94318)

2024-06-04 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Brandon Wu (4vtomat)


Changes



---

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


5 Files Affected:

- (modified) clang/include/clang/Basic/riscv_vector.td (+2-1) 
- (modified) 
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vcpopv.c
 (+132-132) 
- (modified) 
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vcpopv.c
 (+132-132) 
- (modified) 
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/policy/non-overloaded/vcpopv.c
 (+264-264) 
- (modified) 
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/policy/overloaded/vcpopv.c
 (+264-264) 


``diff
diff --git a/clang/include/clang/Basic/riscv_vector.td 
b/clang/include/clang/Basic/riscv_vector.td
index cca4367751b92..a0820e2093bc2 100644
--- a/clang/include/clang/Basic/riscv_vector.td
+++ b/clang/include/clang/Basic/riscv_vector.td
@@ -2637,7 +2637,8 @@ let UnMaskedPolicyScheme = HasPassthruOperand in {
 defm vbrev   : RVVOutBuiltinSetZvbb;
 defm vclz: RVVOutBuiltinSetZvbb;
 defm vctz: RVVOutBuiltinSetZvbb;
-defm vcpopv  : RVVOutBuiltinSetZvbb;
+let IRName = "vcpopv", MaskedIRName = "vcpopv_mask" in
+defm vcpop   : RVVOutBuiltinSetZvbb;
 let OverloadedName = "vwsll" in
 defm vwsll   : RVVSignedWidenBinBuiltinSetVwsll;
   }
diff --git 
a/clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vcpopv.c
 
b/clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vcpopv.c
index 13748be1acc1a..b87b225b632a5 100644
--- 
a/clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vcpopv.c
+++ 
b/clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vcpopv.c
@@ -16,399 +16,399 @@
 
 #include 
 
-// CHECK-LABEL: @test_vcpopv_v_u8mf8(
+// CHECK-LABEL: @test_vcpop_v_u8mf8(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[TMP0:%.*]] = call  
@llvm.riscv.vcpopv.nxv1i8.i64( poison,  
[[VS2:%.*]], i64 [[VL:%.*]])
 // CHECK-NEXT:ret  [[TMP0]]
 //
-vuint8mf8_t test_vcpopv_v_u8mf8(vuint8mf8_t vs2, size_t vl) {
-  return __riscv_vcpopv_v_u8mf8(vs2, vl);
+vuint8mf8_t test_vcpop_v_u8mf8(vuint8mf8_t vs2, size_t vl) {
+  return __riscv_vcpop_v_u8mf8(vs2, vl);
 }
 
-// CHECK-LABEL: @test_vcpopv_v_u8mf4(
+// CHECK-LABEL: @test_vcpop_v_u8mf4(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[TMP0:%.*]] = call  
@llvm.riscv.vcpopv.nxv2i8.i64( poison,  
[[VS2:%.*]], i64 [[VL:%.*]])
 // CHECK-NEXT:ret  [[TMP0]]
 //
-vuint8mf4_t test_vcpopv_v_u8mf4(vuint8mf4_t vs2, size_t vl) {
-  return __riscv_vcpopv_v_u8mf4(vs2, vl);
+vuint8mf4_t test_vcpop_v_u8mf4(vuint8mf4_t vs2, size_t vl) {
+  return __riscv_vcpop_v_u8mf4(vs2, vl);
 }
 
-// CHECK-LABEL: @test_vcpopv_v_u8mf2(
+// CHECK-LABEL: @test_vcpop_v_u8mf2(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[TMP0:%.*]] = call  
@llvm.riscv.vcpopv.nxv4i8.i64( poison,  
[[VS2:%.*]], i64 [[VL:%.*]])
 // CHECK-NEXT:ret  [[TMP0]]
 //
-vuint8mf2_t test_vcpopv_v_u8mf2(vuint8mf2_t vs2, size_t vl) {
-  return __riscv_vcpopv_v_u8mf2(vs2, vl);
+vuint8mf2_t test_vcpop_v_u8mf2(vuint8mf2_t vs2, size_t vl) {
+  return __riscv_vcpop_v_u8mf2(vs2, vl);
 }
 
-// CHECK-LABEL: @test_vcpopv_v_u8m1(
+// CHECK-LABEL: @test_vcpop_v_u8m1(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[TMP0:%.*]] = call  
@llvm.riscv.vcpopv.nxv8i8.i64( poison,  
[[VS2:%.*]], i64 [[VL:%.*]])
 // CHECK-NEXT:ret  [[TMP0]]
 //
-vuint8m1_t test_vcpopv_v_u8m1(vuint8m1_t vs2, size_t vl) {
-  return __riscv_vcpopv_v_u8m1(vs2, vl);
+vuint8m1_t test_vcpop_v_u8m1(vuint8m1_t vs2, size_t vl) {
+  return __riscv_vcpop_v_u8m1(vs2, vl);
 }
 
-// CHECK-LABEL: @test_vcpopv_v_u8m2(
+// CHECK-LABEL: @test_vcpop_v_u8m2(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[TMP0:%.*]] = call  
@llvm.riscv.vcpopv.nxv16i8.i64( poison,  
[[VS2:%.*]], i64 [[VL:%.*]])
 // CHECK-NEXT:ret  [[TMP0]]
 //
-vuint8m2_t test_vcpopv_v_u8m2(vuint8m2_t vs2, size_t vl) {
-  return __riscv_vcpopv_v_u8m2(vs2, vl);
+vuint8m2_t test_vcpop_v_u8m2(vuint8m2_t vs2, size_t vl) {
+  return __riscv_vcpop_v_u8m2(vs2, vl);
 }
 
-// CHECK-LABEL: @test_vcpopv_v_u8m4(
+// CHECK-LABEL: @test_vcpop_v_u8m4(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[TMP0:%.*]] = call  
@llvm.riscv.vcpopv.nxv32i8.i64( poison,  
[[VS2:%.*]], i64 [[VL:%.*]])
 // CHECK-NEXT:ret  [[TMP0]]
 //
-vuint8m4_t test_vcpopv_v_u8m4(vuint8m4_t vs2, size_t vl) {
-  return __riscv_vcpopv_v_u8m4(vs2, vl);
+vuint8m4_t test_vcpop_v_u8m4(vuint8m4_t vs2, size_t vl) {
+  return __riscv_vcpop_v_u8m4(vs2, vl);
 }
 
-// CHECK-LABEL: @test_vcpopv_v_u8m8(
+// CHECK-LABEL: @test_vcpop_v_u8m8(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[TMP0:%.*]] = call  
@llvm.riscv.vcpopv.nxv64i8.i64( poison,  
[[VS2:%.*]], i64 [[VL:%.*]])
 // CHECK-NEXT:ret  [[TMP0]]
 //
-vuint8m8_t test_vcpopv_v_u8m8(vuint8m8_t vs2, size_t vl) {
-  return __riscv_vcpopv_v_u

[clang] [Serialization] No transitive identifier change (PR #92085)

2024-06-04 Thread via cfe-commits

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff 799ae77993fa5d7b0638f10b3895090f8748de92 
e8f756ec7f8ea7e5bf18cc122a965fb2f258fd15 -- 
clang/test/Modules/no-transitive-identifier-change.cppm 
clang/include/clang/Lex/ExternalPreprocessorSource.h 
clang/include/clang/Lex/HeaderSearch.h 
clang/include/clang/Serialization/ASTBitCodes.h 
clang/include/clang/Serialization/ASTReader.h 
clang/include/clang/Serialization/ModuleFile.h clang/lib/Lex/HeaderSearch.cpp 
clang/lib/Serialization/ASTReader.cpp clang/lib/Serialization/ASTWriter.cpp 
clang/lib/Serialization/GlobalModuleIndex.cpp 
clang/lib/Serialization/ModuleFile.cpp
``





View the diff from clang-format here.


``diff
diff --git a/clang/lib/Serialization/ASTReader.cpp 
b/clang/lib/Serialization/ASTReader.cpp
index 29a7fcb2cb..fb41a65608 100644
--- a/clang/lib/Serialization/ASTReader.cpp
+++ b/clang/lib/Serialization/ASTReader.cpp
@@ -3436,8 +3436,8 @@ llvm::Error ASTReader::ReadASTBlock(ModuleFile &F,
   F.BaseIdentifierID = getTotalNumIdentifiers();
 
   if (F.LocalNumIdentifiers > 0)
-IdentifiersLoaded.resize(IdentifiersLoaded.size()
- + F.LocalNumIdentifiers);
+IdentifiersLoaded.resize(IdentifiersLoaded.size() +
+ F.LocalNumIdentifiers);
   break;
 }
 

``




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


[clang] [Clang] Static and explicit object member functions with the same parameter-type-lists (PR #93430)

2024-06-04 Thread via cfe-commits

cor3ntin wrote:

@AaronBallman @erichkeane ping!

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


[clang] [llvm] [openmp] [Clang][OpenMP] Add reverse directive (PR #92916)

2024-06-04 Thread Michael Kruse via cfe-commits

Meinersbur wrote:

@alexey-bataev ping

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


[clang] [HLSL] add loop unroll (PR #93879)

2024-06-04 Thread Farzon Lotfi via cfe-commits

https://github.com/farzonl updated 
https://github.com/llvm/llvm-project/pull/93879

>From 87fe5df0bb46a6bea9b33f30bcb5588f04bef080 Mon Sep 17 00:00:00 2001
From: Farzon Lotfi 
Date: Thu, 30 May 2024 13:51:35 -0400
Subject: [PATCH 1/5] [HLSL] add loop unroll - `Attr.td` - Define the HLSL loop
 attribute hints (unroll and loop) - `AttrDocs.td` - Add documentation for
 unroll and loop - `CGLoopInfo.cpp` - Add codegen for HLSL unroll that maps to
 clang   unroll expectations - `ParseStmt.cpp` - For statements if HLSL define
 DeclSpecAttrs via MaybeParseMicrosoftAttributes - `SemaStmtAttr.cpp` - Add
 the HLSL loop unroll handeling

---
 clang/include/clang/Basic/Attr.td| 13 
 clang/include/clang/Basic/AttrDocs.td| 47 +++
 clang/lib/CodeGen/CGLoopInfo.cpp | 15 +++-
 clang/lib/Parse/ParseStmt.cpp| 11 ++-
 clang/lib/Sema/SemaStmtAttr.cpp  | 29 +++
 clang/test/CodeGenHLSL/loops/unroll.hlsl | 99 
 6 files changed, 208 insertions(+), 6 deletions(-)
 create mode 100644 clang/test/CodeGenHLSL/loops/unroll.hlsl

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index c6f08860f203a..15013b42561e4 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -4115,6 +4115,19 @@ def LoopHint : Attr {
   let HasCustomParsing = 1;
 }
 
+/// The HLSL loop attributes
+def HLSLLoopHint: StmtAttr {
+  /// [unroll(directive)]
+  /// [loop]
+  let Spellings = [Microsoft<"unroll">, Microsoft<"loop">];
+  let Args = [UnsignedArgument<"directive">];
+  let Subjects = SubjectList<[ForStmt, WhileStmt, DoStmt],
+  ErrorDiag, "'for', 'while', and 'do' 
statements">;
+  let LangOpts = [HLSL];
+  let Documentation = [HLSLLoopHintDocs, HLSLUnrollHintDocs];
+  let HasCustomParsing = 1;
+}
+
 def CapturedRecord : InheritableAttr {
   // This attribute has no spellings as it is only ever created implicitly.
   let Spellings = [];
diff --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 70d5dfa8aaf86..7c48c4dbcef3d 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -7345,6 +7345,53 @@ where shaders must be compiled into a library and linked 
at runtime.
   }];
 }
 
+def HLSLLoopHintDocs : Documentation {
+  let Category = DocCatStmt;
+  let Heading = "#[loop]";
+  let Content = [{
+The ``[loop]`` directive allows loop optimization hints to be
+specified for the subsequent loop. The directive allows unrolling to
+be disabled and is not compatible with [unroll(x)]. 
+
+Specifying the parameter, ``[loop]``, directs the
+unroller to not unroll the loop. 
+
+.. code-block:: hlsl
+
+  [loop]
+  for (...) {
+...
+  }
+
+See `hlsl loop extensions
+`_
+for details.
+  }];
+}
+
+def HLSLUnrollHintDocs : Documentation {
+  let Category = DocCatStmt;
+  let Heading = "[unroll(x)]";
+  let Content = [{
+Loop unrolling optimization hints can be specified with ``[unroll(x)]``
+. The attribute is placed immediately before a for, while,
+or do-while.
+Specifying the parameter, ``[unroll(_value_)]``, directs the
+unroller to unroll the loop ``_value_`` times. Note: [unroll(x)] is not 
compatible with [loop].
+
+.. code-block:: hlsl
+
+  [unroll(4)]
+  for (...) {
+...
+  }
+See
+`hlsl loop extensions
+`_
+for details.
+  }];
+}
+
 def ClangRandomizeLayoutDocs : Documentation {
   let Category = DocCatDecl;
   let Heading = "randomize_layout, no_randomize_layout";
diff --git a/clang/lib/CodeGen/CGLoopInfo.cpp b/clang/lib/CodeGen/CGLoopInfo.cpp
index 0d4800b90a2f2..6b886bd6b6d2c 100644
--- a/clang/lib/CodeGen/CGLoopInfo.cpp
+++ b/clang/lib/CodeGen/CGLoopInfo.cpp
@@ -612,9 +612,9 @@ void LoopInfoStack::push(BasicBlock *Header, 
clang::ASTContext &Ctx,
 const LoopHintAttr *LH = dyn_cast(Attr);
 const OpenCLUnrollHintAttr *OpenCLHint =
 dyn_cast(Attr);
-
+const HLSLLoopHintAttr *HLSLLoopHint = dyn_cast(Attr);
 // Skip non loop hint attributes
-if (!LH && !OpenCLHint) {
+if (!LH && !OpenCLHint && !HLSLLoopHint) {
   continue;
 }
 
@@ -635,6 +635,17 @@ void LoopInfoStack::push(BasicBlock *Header, 
clang::ASTContext &Ctx,
 Option = LoopHintAttr::UnrollCount;
 State = LoopHintAttr::Numeric;
   }
+} else if (HLSLLoopHint) {
+  ValueInt = HLSLLoopHint->getDirective();
+  if (HLSLLoopHint->getSemanticSpelling() ==
+  HLSLLoopHintAttr::Spelling::Microsoft_unroll) {
+if (ValueInt == 0)
+  State = LoopHintAttr::Enable;
+if (ValueInt > 0) {
+  Option = LoopHintAttr::UnrollCount;
+  State = LoopHintAttr::Numeric;
+}
+  }
 } else if (LH) {
   auto *ValueExpr = LH->getValue();
   if (ValueExpr) {
diff --git a/clan

[clang] [serialization] no transitive decl change (PR #92083)

2024-06-04 Thread Michael Buch via cfe-commits

Michael137 wrote:

Unfortunately this is still failing one test on the macOS CI: 
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/5083/execution/node/97/log

```
==
FAIL: test_duplicate_decls_gmodules 
(TestTemplateWithSameArg.TestTemplateWithSameArg)
--
Traceback (most recent call last):
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 1756, in test_method
return attrvalue(self)
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/lang/cpp/gmodules/template-with-same-arg/TestTemplateWithSameArg.py",
 line 66, in test_duplicate_decls
self.filecheck("target module dump ast", __file__)
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2293, in filecheck
self.assertTrue(cmd_status == 0)
AssertionError: False is not true
Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
--
Ran 2 tests in 1.682s

FAILED (failures=1)
```

Let me know if you need help reproducing this.

Looks like we're doing a FileCheck on the imported LLDB AST:
```
FileCheck output:

/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/lang/cpp/gmodules/template-with-same-arg/TestTemplateWithSameArg.py:69:10:
 error: CHECK: expected string not found in input
# CHECK: ClassTemplateSpecializationDecl {{.*}} imported in Module2 struct 
ClassInMod3 definition
```

But instead of `imported in Module2 struct ClassInMod3 definition` it's now 
just `imported struct ClassInMod3 definition`

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


[clang] bc3baa9 - [clang][analyzer] Move PutenvStackArrayChecker out of alpha package (#93980)

2024-06-04 Thread via cfe-commits

Author: Balázs Kéri
Date: 2024-06-04T10:02:38+02:00
New Revision: bc3baa93ce5142fcdc2dc5a7d27e26a32999116d

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

LOG: [clang][analyzer] Move PutenvStackArrayChecker out of alpha package 
(#93980)

Checker alpha.security.PutenvStackArray is moved to
security.PutenvStackArray.

Added: 


Modified: 
clang/docs/analyzer/checkers.rst
clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
clang/test/Analysis/putenv-stack-array.c

Removed: 




diff  --git a/clang/docs/analyzer/checkers.rst 
b/clang/docs/analyzer/checkers.rst
index 1e75c3997a475..1ae6e9c000420 100644
--- a/clang/docs/analyzer/checkers.rst
+++ b/clang/docs/analyzer/checkers.rst
@@ -1179,6 +1179,41 @@ security.insecureAPI.DeprecatedOrUnsafeBufferHandling (C)
strncpy(buf, "a", 1); // warn
  }
 
+.. _security-putenv-stack-array:
+
+security.PutenvStackArray (C)
+"
+Finds calls to the ``putenv`` function which pass a pointer to a 
stack-allocated
+(automatic) array as the argument. Function ``putenv`` does not copy the passed
+string, only a pointer to the data is stored and this data can be read even by
+other threads. Content of a stack-allocated array is likely to be overwritten
+after exiting from the function.
+
+The problem can be solved by using a static array variable or dynamically
+allocated memory. Even better is to avoid using ``putenv`` (it has other
+problems related to memory leaks) and use ``setenv`` instead.
+
+The check corresponds to CERT rule
+`POS34-C. Do not call putenv() with a pointer to an automatic variable as the 
argument
+`_.
+
+.. code-block:: c
+
+  int f() {
+char env[] = "NAME=value";
+return putenv(env); // putenv function should not be called with 
stack-allocated string
+  }
+
+There is one case where the checker can report a false positive. This is when
+the stack-allocated array is used at `putenv` in a function or code branch that
+does not return (process is terminated on all execution paths).
+
+Another special case is if the `putenv` is called from function `main`. Here
+the stack is deallocated at the end of the program and it should be no problem
+to use the stack-allocated string (a multi-threaded program may require more
+attention). The checker does not warn for cases when stack space of `main` is
+used at the `putenv` call.
+
 security.SetgidSetuidOrder (C)
 ""
 When dropping user-level and group-level privileges in a program by using
@@ -2877,41 +2912,6 @@ Warn on mmap() calls that are both writable and 
executable.
//   code
  }
 
-.. _alpha-security-putenv-stack-array:
-
-alpha.security.PutenvStackArray (C)
-"""
-Finds calls to the ``putenv`` function which pass a pointer to a 
stack-allocated
-(automatic) array as the argument. Function ``putenv`` does not copy the passed
-string, only a pointer to the data is stored and this data can be read even by
-other threads. Content of a stack-allocated array is likely to be overwritten
-after returning from the parent function.
-
-The problem can be solved by using a static array variable or dynamically
-allocated memory. Even better is to avoid using ``putenv`` (it has other
-problems related to memory leaks) and use ``setenv`` instead.
-
-The check corresponds to CERT rule
-`POS34-C. Do not call putenv() with a pointer to an automatic variable as the 
argument
-`_.
-
-.. code-block:: c
-
-  int f() {
-char env[] = "NAME=value";
-return putenv(env); // putenv function should not be called with 
stack-allocated string
-  }
-
-There is one case where the checker can report a false positive. This is when
-the stack-allocated array is used at `putenv` in a function or code branch that
-does not return (calls `fork` or `exec` like function).
-
-Another special case is if the `putenv` is called from function `main`. Here
-the stack is deallocated at the end of the program and it should be no problem
-to use the stack-allocated string (a multi-threaded program may require more
-attention). The checker does not warn for cases when stack space of `main` is
-used at the `putenv` call.
-
 .. _alpha-security-ReturnPtrRange:
 
 alpha.security.ReturnPtrRange (C)

diff  --git a/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td 
b/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
index 668e9f6cf0716..636eeb45f9980 100644
--- a/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
+++ b/clang/incl

[clang] [clang][analyzer] Move PutenvStackArrayChecker out of alpha package (PR #93980)

2024-06-04 Thread Balázs Kéri via cfe-commits

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


[clang] [clang][ASTImport] fix issue on anonymous enum import (PR #93923)

2024-06-04 Thread Balázs Kéri via cfe-commits

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


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


[clang] [serialization] no transitive decl change (PR #92083)

2024-06-04 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

Oh, this is not wanted. It should be almost a NFC patch for users. I'll revert 
it. 

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


[clang] cb60667 - Revert "[serialization] no transitive decl change (#92083)"

2024-06-04 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-06-04T16:10:38+08:00
New Revision: cb60667b6e762aa172b6ad06332465d69f0fd803

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

LOG: Revert "[serialization] no transitive decl change (#92083)"

This reverts commit d8ec452db016f359feeec28994f6560b30b49824.

This fails on LLDB macOS CI. See
https://github.com/llvm/llvm-project/pull/92083 for details.

Added: 


Modified: 
clang/include/clang/AST/DeclBase.h
clang/include/clang/AST/DeclID.h
clang/include/clang/Serialization/ASTBitCodes.h
clang/include/clang/Serialization/ASTReader.h
clang/include/clang/Serialization/ModuleFile.h
clang/include/clang/Serialization/ModuleManager.h
clang/lib/AST/DeclBase.cpp
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/lib/Serialization/ModuleFile.cpp

Removed: 
clang/test/Modules/no-transitive-decls-change.cppm



diff  --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index c4eb053146d32..3a311d4c55916 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -701,7 +701,10 @@ class alignas(8) Decl {
 
   /// Set the owning module ID.  This may only be called for
   /// deserialized Decls.
-  void setOwningModuleID(unsigned ID);
+  void setOwningModuleID(unsigned ID) {
+assert(isFromASTFile() && "Only works on a deserialized declaration");
+*((unsigned*)this - 2) = ID;
+  }
 
 public:
   /// Determine the availability of the given declaration.
@@ -774,11 +777,19 @@ class alignas(8) Decl {
 
   /// Retrieve the global declaration ID associated with this
   /// declaration, which specifies where this Decl was loaded from.
-  GlobalDeclID getGlobalID() const;
+  GlobalDeclID getGlobalID() const {
+if (isFromASTFile())
+  return (*((const GlobalDeclID *)this - 1));
+return GlobalDeclID();
+  }
 
   /// Retrieve the global ID of the module that owns this particular
   /// declaration.
-  unsigned getOwningModuleID() const;
+  unsigned getOwningModuleID() const {
+if (isFromASTFile())
+  return *((const unsigned*)this - 2);
+return 0;
+  }
 
 private:
   Module *getOwningModuleSlow() const;

diff  --git a/clang/include/clang/AST/DeclID.h 
b/clang/include/clang/AST/DeclID.h
index 32d2ed41a374a..614ba06b63860 100644
--- a/clang/include/clang/AST/DeclID.h
+++ b/clang/include/clang/AST/DeclID.h
@@ -19,8 +19,6 @@
 #include "llvm/ADT/DenseMapInfo.h"
 #include "llvm/ADT/iterator.h"
 
-#include 
-
 namespace clang {
 
 /// Predefined declaration IDs.
@@ -109,16 +107,12 @@ class DeclIDBase {
   ///
   /// DeclID should only be used directly in serialization. All other users
   /// should use LocalDeclID or GlobalDeclID.
-  using DeclID = uint64_t;
+  using DeclID = uint32_t;
 
 protected:
   DeclIDBase() : ID(PREDEF_DECL_NULL_ID) {}
   explicit DeclIDBase(DeclID ID) : ID(ID) {}
 
-  explicit DeclIDBase(unsigned LocalID, unsigned ModuleFileIndex) {
-ID = (DeclID)LocalID | ((DeclID)ModuleFileIndex << 32);
-  }
-
 public:
   DeclID get() const { return ID; }
 
@@ -130,10 +124,6 @@ class DeclIDBase {
 
   bool isInvalid() const { return ID == PREDEF_DECL_NULL_ID; }
 
-  unsigned getModuleFileIndex() const { return ID >> 32; }
-
-  unsigned getLocalDeclIndex() const;
-
   friend bool operator==(const DeclIDBase &LHS, const DeclIDBase &RHS) {
 return LHS.ID == RHS.ID;
   }
@@ -166,9 +156,6 @@ class LocalDeclID : public DeclIDBase {
   LocalDeclID(PredefinedDeclIDs ID) : Base(ID) {}
   explicit LocalDeclID(DeclID ID) : Base(ID) {}
 
-  explicit LocalDeclID(unsigned LocalID, unsigned ModuleFileIndex)
-  : Base(LocalID, ModuleFileIndex) {}
-
   LocalDeclID &operator++() {
 ++ID;
 return *this;
@@ -188,9 +175,6 @@ class GlobalDeclID : public DeclIDBase {
   GlobalDeclID() : Base() {}
   explicit GlobalDeclID(DeclID ID) : Base(ID) {}
 
-  explicit GlobalDeclID(unsigned LocalID, unsigned ModuleFileIndex)
-  : Base(LocalID, ModuleFileIndex) {}
-
   // For DeclIDIterator to be able to convert a GlobalDeclID
   // to a LocalDeclID.
   explicit operator LocalDeclID() const { return LocalDeclID(this->ID); }

diff  --git a/clang/include/clang/Serialization/ASTBitCodes.h 
b/clang/include/clang/Serialization/ASTBitCodes.h
index 902c4470650c5..fe1bd47348be1 100644
--- a/clang/include/clang/Serialization/ASTBitCodes.h
+++ b/clang/include/clang/Serialization/ASTBitCodes.h
@@ -255,12 +255,6 @@ class DeclOffset {
   }
 };
 
-// The unaligned decl ID used in the Blobs of bistreams.
-using unaligned_decl_id_t =
-llvm::support::detail::packed_endian_specific_integral<
-serialization::DeclID, llvm::endianness::native,
-llvm::support::unaligned>;
-
 /// The numb

[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)

2024-06-04 Thread Mike Hommey via cfe-commits

glandium wrote:

This broke building clang on Windows with PGO:
```
FAILED: bin/clang-repl.exe lib/clang-repl.lib 
cmd.exe /C "cmd.exe /C "D:\task_171745452431588\fetches\cmake\bin\cmake.exe -E 
__create_def 
D:\task_171745452431588\fetches\llvm-project\build\stage2\build\tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir\.\exports.def
 
D:\task_171745452431588\fetches\llvm-project\build\stage2\build\tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir\.\exports.def.objs
 --nm=D:\task_171745452431588\fetches\clang\bin\llvm-nm.exe && cd 
D:\task_171745452431588\fetches\llvm-project\build\stage2\build" && 
D:\task_171745452431588\fetches\cmake\bin\cmake.exe -E vs_link_exe 
--intdir=tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir 
--rc="D:\task_171745452431588\fetches\vs\Windows 
Kits\10\bin\10.0.22621.0\x64\rc.exe" 
--mt="D:\task_171745452431588\fetches\vs\Windows 
Kits\10\bin\10.0.22621.0\x64\mt.exe" --manifests  -- 
D:\task_171745452431588\fetches\clang\bin\lld-link.exe /nologo 
@CMakeFiles\clang-repl.rsp  /out:bin\clang-repl.exe /implib:lib\clang-repl.lib 
/pdb:bin\clang-repl.pdb /version:0.0 /machine:x64 /STACK:1000 
/libpath:"D:/task_171745452431588/fetches/clang/lib/clang/19/lib/windows" 
/INCREMENTAL:NO /subsystem:console   /EXPORT:??_7type_info@@6B@ 
/EXPORT:?__type_info_root_node@@3U__type_info_node@@A 
/EXPORT:?nothrow@std@@3Unothrow_t@1@B /EXPORT:_Init_thread_abort 
/EXPORT:_Init_thread_epoch /EXPORT:_Init_thread_footer 
/EXPORT:_Init_thread_header /EXPORT:_tls_index /EXPORT:??2@YAPEAX_K@Z 
/EXPORT:??3@YAXPEAX@Z /EXPORT:??_U@YAPEAX_K@Z /EXPORT:??_V@YAXPEAX@Z 
/EXPORT:??3@YAXPEAX_K@Z 
/DEF:"D:/task_171745452431588/fetches/llvm-project/build/stage2/build/tools/clang/tools/clang-repl/clang-repl.def"
  -Wl,--long-plt 
/DEF:tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir\.\exports.def  && 
cd ."
LINK: command "D:\task_171745452431588\fetches\clang\bin\lld-link.exe /nologo 
@CMakeFiles\clang-repl.rsp /out:bin\clang-repl.exe /implib:lib\clang-repl.lib 
/pdb:bin\clang-repl.pdb /version:0.0 /machine:x64 /STACK:1000 
/libpath:D:/task_171745452431588/fetches/clang/lib/clang/19/lib/windows 
/INCREMENTAL:NO /subsystem:console /EXPORT:??_7type_info@@6B@ 
/EXPORT:?__type_info_root_node@@3U__type_info_node@@A 
/EXPORT:?nothrow@std@@3Unothrow_t@1@B /EXPORT:_Init_thread_abort 
/EXPORT:_Init_thread_epoch /EXPORT:_Init_thread_footer 
/EXPORT:_Init_thread_header /EXPORT:_tls_index /EXPORT:??2@YAPEAX_K@Z 
/EXPORT:??3@YAXPEAX@Z /EXPORT:??_U@YAPEAX_K@Z /EXPORT:??_V@YAXPEAX@Z 
/EXPORT:??3@YAXPEAX_K@Z 
/DEF:D:/task_171745452431588/fetches/llvm-project/build/stage2/build/tools/clang/tools/clang-repl/clang-repl.def
 -Wl,--long-plt 
/DEF:tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir\.\exports.def 
/MANIFEST /MANIFESTFILE:bin\clang-repl.exe.manifest" failed (exit code 1) with 
the following output:
lld-link: error: : undefined symbol: __profc_??$?0$$BY03DUdesc
lld-link: error: : undefined symbol: __profc_??$?0$$BY04DW4OptionHidden
lld-link: error: : undefined symbol: __profc_??$?0$$BY09DW4OptionHidden
lld-link: error: : undefined symbol: __profc_??$?0$$BY0BC
lld-link: error: : undefined symbol: __profc_??$?0$$BY0N
lld-link: error: : undefined symbol: __profc_??$?0W4FormattingFlags
lld-link: error: : undefined symbol: __profc_??$?4$$BY05D
lld-link: error: : undefined symbol: __profc_??$?6PEBD
lld-link: error: : undefined symbol: __profc_??$_Emplace_reallocate
lld-link: error: : undefined symbol: __profc_??$_Reallocate_for
lld-link: error: : undefined symbol: __profc_??$_Reallocate_grow_by
lld-link: error: : undefined symbol: __profc_??$_Traits_find 
lld-link: error: : undefined symbol: __profc_??$_Traits_rfind
lld-link: error: : undefined symbol: __profc_??$_Uninitialized_move
lld-link: error: : undefined symbol: __profc_??$addValue
lld-link: error: : undefined symbol: __profc_??$handleErrors 
lld-link: error: : undefined symbol: __profc_??$setValue
lld-link: error: : undefined symbol: __profc_??0?$OptionValueCopy
lld-link: error: : undefined symbol: __profc_??0Completion
lld-link: error: : undefined symbol: __profc_??0ErrorList
lld-link: error: too many errors emitted, stopping now (use /errorlimit:0 to 
see all errors)
```

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


[clang] [clang-format] Add DiagHandler for getStyle function (PR #91317)

2024-06-04 Thread via cfe-commits

pointhex wrote:

> Can you call `parseConfiguration()` instead of `getStyle()` in QtCreator 
> while the user is entering code? It seems inefficient to call `getStyle()` 
> all the time.

I do it in the places where I can use parseConfiguration instead. But in some 
cases I need getStyle and it's also called quite often. I have one optimisation 
in my mind, but I would like to have that patch as well anyway.

Am I right that no one has a major issue with the patch? So fixing the "const" 
issue and adding a unit test will let that in? 

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


[clang] [serialization] no transitive decl change (PR #92083)

2024-06-04 Thread Michael Buch via cfe-commits

Michael137 wrote:

> Oh, this is not wanted. It should be almost a NFC patch for users. I'll 
> revert it.

Thanks!

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


[clang] [Clang][C++23] update constexpr diagnostics for missing return statements per P2448 (PR #94123)

2024-06-04 Thread Mariya Podchishchaeva via cfe-commits

https://github.com/Fznamznon commented:

I wonder if we should always emit an error when a function with non-void return 
type doesn't have a return statement? In any case it is a serious yet dumb bug 
that will lead to problems and perhaps some time spent debugging it.
gcc rejects the case for C++23 as well https://godbolt.org/z/8xq8TdEGE . 
cc @AaronBallman 

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


[clang] [Clang][C++23] update constexpr diagnostics for missing return statements per P2448 (PR #94123)

2024-06-04 Thread Mariya Podchishchaeva via cfe-commits


@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -Wno-return-type -std=c++23 -fsyntax-only -verify %s
+// expected-no-diagnostics
+constexpr int f() { }
+static_assert(__is_same(decltype([] constexpr -> int { }( )), int));

Fznamznon wrote:

Should we emit at least a warning in case of missing return statement and 
non-void function and check it?

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


[clang] [Clang][C++23] update constexpr diagnostics for missing return statements per P2448 (PR #94123)

2024-06-04 Thread Mariya Podchishchaeva via cfe-commits

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


[clang] [Clang][C++23] update constexpr diagnostics for missing return statements per P2448 (PR #94123)

2024-06-04 Thread Mariya Podchishchaeva via cfe-commits


@@ -2487,6 +2477,26 @@ static bool CheckConstexprFunctionBody(Sema &SemaRef, 
const FunctionDecl *Dcl,
   return true;
 }
 
+static bool CheckConstexprMissingReturn(Sema &SemaRef,
+const FunctionDecl *Dcl) {
+  bool IsVoidOrDependentType = Dcl->getReturnType()->isVoidType() ||
+   Dcl->getReturnType()->isDependentType();
+
+  if (SemaRef.getLangOpts().CPlusPlus23 && !IsVoidOrDependentType)
+return true;
+
+  // C++1y doesn't require constexpr functions to contain a 'return'
+  // statement. We still do, unless the return type might be void, because
+  // otherwise if there's no return statement, the function cannot
+  // be used in a core constant expression.

Fznamznon wrote:

Could you please also mention that we early-exit and don't emit error 
diagnostic in C++23 because it doesn't require `constexpr` function to produce 
a constant expression?

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


[clang] [libcxx] [Clang] Implement resolution for CWG1835 (PR #92957)

2024-06-04 Thread Qizhi Hu via cfe-commits


@@ -1442,19 +1442,27 @@ SourceLocation 
CXXUnresolvedConstructExpr::getBeginLoc() const {
 CXXDependentScopeMemberExpr::CXXDependentScopeMemberExpr(
 const ASTContext &Ctx, Expr *Base, QualType BaseType, bool IsArrow,
 SourceLocation OperatorLoc, NestedNameSpecifierLoc QualifierLoc,
-SourceLocation TemplateKWLoc, NamedDecl *FirstQualifierFoundInScope,
+SourceLocation TemplateKWLoc, ArrayRef UnqualifiedLookups,
 DeclarationNameInfo MemberNameInfo,
 const TemplateArgumentListInfo *TemplateArgs)
 : Expr(CXXDependentScopeMemberExprClass, Ctx.DependentTy, VK_LValue,
OK_Ordinary),
-  Base(Base), BaseType(BaseType), QualifierLoc(QualifierLoc),
+  Base(Base), BaseType(BaseType), OperatorLoc(OperatorLoc),

jcsxky wrote:

There is a warning here. `field 'OperatorLoc' will be initialized after field 
'MemberNameInfo'`

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


[clang] [llvm] Enable LLDB tests in pre-merge CI (PR #94208)

2024-06-04 Thread David Spickett via cfe-commits

DavidSpickett wrote:

> MSVC 14.29.30133 is VS 2019. We are using VS 2022 with the latest Windows SDK 
> to build lldb w/o problems.

I also couldn't reproduce it locally with `19.34.31937`, but I may still be 
able to reproduce by making my own version of this PR so I can use the CI's 
version.

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


[clang] [llvm] [AArch64] Support preserve_none calling convention (PR #91046)

2024-06-04 Thread Diego Russo via cfe-commits

diegorusso wrote:

We (CPython project) will use it for the new JIT. I'll be testing the current 
implementation and report back any issue. I don't think you need to revert the 
PR but please let me know when you create the new one to address the post-merge 
comments so I can test it again.

Thanks

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


[clang] 99873b3 - [NFC] [AST] Introduce Decl::isInAnotherModuleUnit and Decl::shouldEmitInExternalSource

2024-06-04 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-06-04T17:08:21+08:00
New Revision: 99873b35da7ecb905143c8a6b8deca4d4416f1a9

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

LOG: [NFC] [AST] Introduce Decl::isInAnotherModuleUnit and 
Decl::shouldEmitInExternalSource

Motivated by the review process in
https://github.com/llvm/llvm-project/pull/75912. This can also help to
simplify the code slightly.

Added: 


Modified: 
clang/include/clang/AST/DeclBase.h
clang/lib/AST/ASTContext.cpp
clang/lib/AST/Decl.cpp
clang/lib/AST/DeclBase.cpp
clang/lib/CodeGen/CGVTables.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Serialization/ASTWriter.cpp

Removed: 




diff  --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index 3a311d4c55916..600ce73c7f019 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -670,6 +670,13 @@ class alignas(8) Decl {
   /// Whether this declaration comes from another module unit.
   bool isInAnotherModuleUnit() const;
 
+  /// Whether the definition of the declaration should be emitted in external
+  /// sources.
+  bool shouldEmitInExternalSource() const;
+
+  /// Whether this declaration comes from a named module;
+  bool isInNamedModule() const;
+
   /// Whether this declaration comes from explicit global module.
   bool isFromExplicitGlobalModule() const;
 

diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index 73d3b152c49f1..bf74e56a14799 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -12018,7 +12018,7 @@ bool ASTContext::DeclMustBeEmitted(const Decl *D) {
 return false;
 
   // Variables in other module units shouldn't be forced to be emitted.
-  if (VD->isInAnotherModuleUnit())
+  if (VD->shouldEmitInExternalSource())
 return false;
 
   // Variables that can be needed in other TUs are required.

diff  --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 0a35ed536a6a7..1f19dadafa44e 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -1174,13 +1174,6 @@ Linkage NamedDecl::getLinkageInternal() const {
   .getLinkage();
 }
 
-/// Determine whether D is attached to a named module.
-static bool isInNamedModule(const NamedDecl *D) {
-  if (auto *M = D->getOwningModule())
-return M->isNamedModule();
-  return false;
-}
-
 static bool isExportedFromModuleInterfaceUnit(const NamedDecl *D) {
   // FIXME: Handle isModulePrivate.
   switch (D->getModuleOwnershipKind()) {
@@ -1190,7 +1183,7 @@ static bool isExportedFromModuleInterfaceUnit(const 
NamedDecl *D) {
 return false;
   case Decl::ModuleOwnershipKind::Visible:
   case Decl::ModuleOwnershipKind::VisibleWhenImported:
-return isInNamedModule(D);
+return D->isInNamedModule();
   }
   llvm_unreachable("unexpected module ownership kind");
 }
@@ -1208,7 +1201,7 @@ Linkage NamedDecl::getFormalLinkage() const {
   // [basic.namespace.general]/p2
   //   A namespace is never attached to a named module and never has a name 
with
   //   module linkage.
-  if (isInNamedModule(this) && InternalLinkage == Linkage::External &&
+  if (isInNamedModule() && InternalLinkage == Linkage::External &&
   !isExportedFromModuleInterfaceUnit(
   cast(this->getCanonicalDecl())) &&
   !isa(this))

diff  --git a/clang/lib/AST/DeclBase.cpp b/clang/lib/AST/DeclBase.cpp
index ffb22194bce52..1e9c879e371bc 100644
--- a/clang/lib/AST/DeclBase.cpp
+++ b/clang/lib/AST/DeclBase.cpp
@@ -1100,23 +1100,22 @@ bool Decl::isInExportDeclContext() const {
 bool Decl::isInAnotherModuleUnit() const {
   auto *M = getOwningModule();
 
-  if (!M)
+  if (!M || !M->isNamedModule())
 return false;
 
-  M = M->getTopLevelModule();
-  // FIXME: It is problematic if the header module lives in another module
-  // unit. Consider to fix this by techniques like
-  // ExternalASTSource::hasExternalDefinitions.
-  if (M->isHeaderLikeModule())
-return false;
+  return M != getASTContext().getCurrentNamedModule();
+}
 
-  // A global module without parent implies that we're parsing the global
-  // module. So it can't be in another module unit.
-  if (M->isGlobalModule())
+bool Decl::shouldEmitInExternalSource() const {
+  ExternalASTSource *Source = getASTContext().getExternalSource();
+  if (!Source)
 return false;
 
-  assert(M->isNamedModule() && "New module kind?");
-  return M != getASTContext().getCurrentNamedModule();
+  return Source->hasExternalDefinitions(this) == ExternalASTSource::EK_Always;
+}
+
+bool Decl::isInNamedModule() const {
+  return getOwningModule() && getOwningModule()->isNamedModule();
 }
 
 bool Decl::isFromExplicitGlobalModule() const {

diff  --git a/clang/lib/CodeGen/CGVTables.cpp b/clang/lib/CodeGen/CGVTables.cpp
index 8d9c22546b420..

[clang-tools-extra] [clang-tidy] new check misc-use-internal-linkage (PR #90830)

2024-06-04 Thread Congcong Cai via cfe-commits


@@ -0,0 +1,78 @@
+//===--- UseInternalLinkageCheck.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 "UseInternalLinkageCheck.h"
+#include "../utils/FileExtensionsUtils.h"
+#include "clang/AST/Decl.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/Specifiers.h"
+#include "llvm/ADT/STLExtras.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::misc {
+
+namespace {
+
+AST_MATCHER(Decl, isFirstDecl) { return Node.isFirstDecl(); }
+
+AST_MATCHER_P(Decl, isInMainFile, FileExtensionsSet, HeaderFileExtensions) {
+  return llvm::all_of(Node.redecls(), [&](const Decl *D) {
+SourceManager &SM = Finder->getASTContext().getSourceManager();
+const SourceLocation L = D->getLocation();
+return SM.isInMainFile(L) &&
+   !utils::isSpellingLocInHeaderFile(L, SM, HeaderFileExtensions);
+  });

HerrCai0907 wrote:

what is the expected behavior for unity files? use static or not? I am a little 
bit confused.

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


[clang] [clang] Move CWG2390 test into `cwg23xx.cpp` (PR #94206)

2024-06-04 Thread Timm Baeder via cfe-commits

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

Looks good, thanks

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


[clang] c631131 - [clang] Move CWG2390 test into `cwg23xx.cpp` (#94206)

2024-06-04 Thread via cfe-commits

Author: Vlad Serebrennikov
Date: 2024-06-04T13:18:56+04:00
New Revision: c631131a1490af9f908a3a3be9aae5295ecff67d

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

LOG: [clang] Move CWG2390 test into `cwg23xx.cpp` (#94206)

This patch refactors an existing test for
[CWG2390](https://cplusplus.github.io/CWG/issues/2390.html) "Is the
argument of `__has_cpp_attribute` macro-expanded?" to use `#error`
instead of emitting a variable in IRGen and checking it via FileCheck.
As a bonus, this makes it possible to move the test into `cwg23xx.cpp`.

Added: 


Modified: 
clang/test/CXX/drs/cwg23xx.cpp

Removed: 
clang/test/CXX/drs/cwg2390.cpp



diff  --git a/clang/test/CXX/drs/cwg2390.cpp b/clang/test/CXX/drs/cwg2390.cpp
deleted file mode 100644
index 41bbd0d1c5499..0
--- a/clang/test/CXX/drs/cwg2390.cpp
+++ /dev/null
@@ -1,47 +0,0 @@
-// RUN: %clang_cc1 -E -P %s -o - | FileCheck %s
-
-// cwg2390: 14
-
-namespace PR48462 {
-// Test that macro expansion of the builtin argument works.
-#define C clang
-#define F fallthrough
-#define CF clang::fallthrough
-
-#if __has_cpp_attribute(F)
-int has_fallthrough;
-#endif
-// CHECK: int has_fallthrough;
-
-#if __has_cpp_attribute(C::F)
-int has_clang_fallthrough_1;
-#endif
-// CHECK: int has_clang_fallthrough_1;
-
-#if __has_cpp_attribute(clang::F)
-int has_clang_fallthrough_2;
-#endif
-// CHECK: int has_clang_fallthrough_2;
-
-#if __has_cpp_attribute(C::fallthrough)
-int has_clang_fallthrough_3;
-#endif
-// CHECK: int has_clang_fallthrough_3;
-
-#if __has_cpp_attribute(CF)
-int has_clang_fallthrough_4;
-#endif
-// CHECK: int has_clang_fallthrough_4;
-
-#define FUNCLIKE1(x) clang::x
-#if __has_cpp_attribute(FUNCLIKE1(fallthrough))
-int funclike_1;
-#endif
-// CHECK: int funclike_1;
-
-#define FUNCLIKE2(x) _Clang::x
-#if __has_cpp_attribute(FUNCLIKE2(fallthrough))
-int funclike_2;
-#endif
-// CHECK: int funclike_2;
-} // namespace PR48462

diff  --git a/clang/test/CXX/drs/cwg23xx.cpp b/clang/test/CXX/drs/cwg23xx.cpp
index ae5ec3b878f59..e4a1e90941dbf 100644
--- a/clang/test/CXX/drs/cwg23xx.cpp
+++ b/clang/test/CXX/drs/cwg23xx.cpp
@@ -317,7 +317,42 @@ namespace cwg2387 { // cwg2387: 9
 #endif
 }
 
-// cwg2390 is in cwg2390.cpp
+namespace cwg2390 { // cwg2390: 14
+// Test that macro expansion of the builtin argument works.
+#define C clang
+#define F fallthrough
+#define CF clang::fallthrough
+
+#if !__has_cpp_attribute(F)
+#error "doesn't have fallthrough"
+#endif
+
+#if !__has_cpp_attribute(C::F)
+#error "doesn't have clang::fallthrough 1"
+#endif
+
+#if !__has_cpp_attribute(clang::F)
+#error "doesn't have clang::fallthrough 2"
+#endif
+
+#if !__has_cpp_attribute(C::fallthrough)
+#error "doesn't have clang::fallthrough 3"
+#endif
+
+#if !__has_cpp_attribute(CF)
+#error "doesn't have clang::fallthrough 4"
+#endif
+
+#define FUNCLIKE1(x) clang::x
+#if !__has_cpp_attribute(FUNCLIKE1(fallthrough))
+#error "doesn't have clang::fallthrough through func-like macro 1"
+#endif
+
+#define FUNCLIKE2(x) _Clang::x
+#if !__has_cpp_attribute(FUNCLIKE2(fallthrough))
+#error "doesn't have clang::fallthrough through func-like macro 2"
+#endif
+} // namespace cwg2390
 
 namespace cwg2394 { // cwg2394: 15
 



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


[clang] [clang] Move CWG2390 test into `cwg23xx.cpp` (PR #94206)

2024-06-04 Thread Vlad Serebrennikov via cfe-commits

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


[clang] [Clang] `constexpr` builtin floating point classification / comparison functions (PR #94118)

2024-06-04 Thread Timm Baeder via cfe-commits

https://github.com/tbaederr commented:

`Interp/` changes LGTM.

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


[clang] [llvm] Enable LLDB tests in pre-merge CI (PR #94208)

2024-06-04 Thread David Spickett via cfe-commits

DavidSpickett wrote:

I think the issue is 
https://developercommunity.visualstudio.com/t/c-shared-state-futuresstate-default-constructs-the/60897
 which appears to have been fixed in 19.32 (https://godbolt.org/z/P594qGrc9).

But @slydiman reports 14.29.30133 which is earlier than that. Perhaps the 
versions in Compiler Explorer don't couple the compiler and standard library.

The CI job reports to be:
```
-- The C compiler identification is MSVC 19.29.30154.0
-- The CXX compiler identification is MSVC 19.29.30154.0
-- The ASM compiler identification is MSVC
-- Found assembler: 
C:/BuildTools/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe
```

Which is even more confusing.

But the point is, we could `#if` it out for a given msvc version, if I can 
figure out which one.


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


[clang-tools-extra] [clang-tidy] new check misc-use-internal-linkage (PR #90830)

2024-06-04 Thread Piotr Zegar via cfe-commits


@@ -0,0 +1,78 @@
+//===--- UseInternalLinkageCheck.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 "UseInternalLinkageCheck.h"
+#include "../utils/FileExtensionsUtils.h"
+#include "clang/AST/Decl.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/Specifiers.h"
+#include "llvm/ADT/STLExtras.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::misc {
+
+namespace {
+
+AST_MATCHER(Decl, isFirstDecl) { return Node.isFirstDecl(); }
+
+AST_MATCHER_P(Decl, isInMainFile, FileExtensionsSet, HeaderFileExtensions) {
+  return llvm::all_of(Node.redecls(), [&](const Decl *D) {
+SourceManager &SM = Finder->getASTContext().getSourceManager();
+const SourceLocation L = D->getLocation();
+return SM.isInMainFile(L) &&
+   !utils::isSpellingLocInHeaderFile(L, SM, HeaderFileExtensions);
+  });

PiotrZSL wrote:

simply .cpp (source files) files included from main file should be treated like 
main file.

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


[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-06-04 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/75912

>From cf8be3c418dde67b74d4a5a4ea98a33f0e2fbd72 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Tue, 19 Dec 2023 17:00:59 +0800
Subject: [PATCH] [C++20] [Modules] [Itanium ABI] Generate the vtable in the
 module unit of dynamic classes

Close https://github.com/llvm/llvm-project/issues/70585 and reflect
https://github.com/itanium-cxx-abi/cxx-abi/issues/170.

The significant change of the patch is: for dynamic classes attached to
module units, we generate the vtable to the attached module units
directly and the key functions for such classes is meaningless.
---
 clang/include/clang/AST/DeclBase.h|  3 ++
 clang/lib/AST/DeclBase.cpp|  9 +
 clang/lib/CodeGen/CGVTables.cpp   | 28 ++
 clang/lib/CodeGen/CodeGenModule.cpp   |  7 
 clang/lib/CodeGen/ItaniumCXXABI.cpp   |  3 ++
 clang/lib/Sema/SemaDecl.cpp   |  9 +
 clang/lib/Sema/SemaDeclCXX.cpp| 12 --
 clang/lib/Serialization/ASTReaderDecl.cpp |  6 +++
 clang/lib/Serialization/ASTWriterDecl.cpp |  6 +++
 clang/test/CodeGenCXX/modules-vtable.cppm | 31 +--
 clang/test/CodeGenCXX/pr70585.cppm| 47 +++
 11 files changed, 138 insertions(+), 23 deletions(-)
 create mode 100644 clang/test/CodeGenCXX/pr70585.cppm

diff --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index 600ce73c7f019..f38386381853b 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -670,6 +670,9 @@ class alignas(8) Decl {
   /// Whether this declaration comes from another module unit.
   bool isInAnotherModuleUnit() const;
 
+  /// Whether this declaration comes from the same module unit being compiled.
+  bool isInCurrentModuleUnit() const;
+
   /// Whether the definition of the declaration should be emitted in external
   /// sources.
   bool shouldEmitInExternalSource() const;
diff --git a/clang/lib/AST/DeclBase.cpp b/clang/lib/AST/DeclBase.cpp
index 1e9c879e371bc..153dc3351dae5 100644
--- a/clang/lib/AST/DeclBase.cpp
+++ b/clang/lib/AST/DeclBase.cpp
@@ -1106,6 +1106,15 @@ bool Decl::isInAnotherModuleUnit() const {
   return M != getASTContext().getCurrentNamedModule();
 }
 
+bool Decl::isInCurrentModuleUnit() const {
+  auto *M = getOwningModule();
+
+  if (!M || !M->isNamedModule())
+return false;
+
+  return M == getASTContext().getCurrentNamedModule();
+}
+
 bool Decl::shouldEmitInExternalSource() const {
   ExternalASTSource *Source = getASTContext().getExternalSource();
   if (!Source)
diff --git a/clang/lib/CodeGen/CGVTables.cpp b/clang/lib/CodeGen/CGVTables.cpp
index 001633453f242..55c3032dc9332 100644
--- a/clang/lib/CodeGen/CGVTables.cpp
+++ b/clang/lib/CodeGen/CGVTables.cpp
@@ -1051,6 +1051,11 @@ CodeGenModule::getVTableLinkage(const CXXRecordDecl *RD) 
{
   if (!RD->isExternallyVisible())
 return llvm::GlobalVariable::InternalLinkage;
 
+  // V-tables for non-template classes with an owning module are always
+  // uniquely emitted in that module.
+  if (RD->isInNamedModule())
+return llvm::GlobalVariable::ExternalLinkage;
+
   // We're at the end of the translation unit, so the current key
   // function is fully correct.
   const CXXMethodDecl *keyFunction = Context.getCurrentKeyFunction(RD);
@@ -1185,6 +1190,21 @@ bool CodeGenVTables::isVTableExternal(const 
CXXRecordDecl *RD) {
   TSK == TSK_ExplicitInstantiationDefinition)
 return false;
 
+  // Itanium C++ ABI [5.2.3]:
+  // Virtual tables for dynamic classes are emitted as follows:
+  //
+  // - If the class is templated, the tables are emitted in every object that
+  // references any of them.
+  // - Otherwise, if the class is attached to a module, the tables are uniquely
+  // emitted in the object for the module unit in which it is defined.
+  // - Otherwise, if the class has a key function (see below), the tables are
+  // emitted in the object for the translation unit containing the definition 
of
+  // the key function. This is unique if the key function is not inline.
+  // - Otherwise, the tables are emitted in every object that references any of
+  // them.
+  if (RD->isInNamedModule())
+return RD->shouldEmitInExternalSource();
+
   // Otherwise, if the class doesn't have a key function (possibly
   // anymore), the vtable must be defined here.
   const CXXMethodDecl *keyFunction = 
CGM.getContext().getCurrentKeyFunction(RD);
@@ -1194,13 +1214,7 @@ bool CodeGenVTables::isVTableExternal(const 
CXXRecordDecl *RD) {
   const FunctionDecl *Def;
   // Otherwise, if we don't have a definition of the key function, the
   // vtable must be defined somewhere else.
-  if (!keyFunction->hasBody(Def))
-return true;
-
-  assert(Def && "The body of the key function is not assigned to Def?");
-  // If the non-inline key function comes from another module unit, the vtable
-  // must be defined there.
-  return Def->shouldE

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-06-04 Thread Chuanqi Xu via cfe-commits


@@ -1180,6 +1185,21 @@ bool CodeGenVTables::isVTableExternal(const 
CXXRecordDecl *RD) {
   TSK == TSK_ExplicitInstantiationDefinition)
 return false;
 
+  // Itanium C++ ABI [5.2.3]:
+  // Virtual tables for dynamic classes are emitted as follows:
+  //
+  // - If the class is templated, the tables are emitted in every object that
+  // references any of them.
+  // - Otherwise, if the class is attached to a module, the tables are uniquely
+  // emitted in the object for the module unit in which it is defined.
+  // - Otherwise, if the class has a key function (see below), the tables are
+  // emitted in the object for the translation unit containing the definition 
of
+  // the key function. This is unique if the key function is not inline.
+  // - Otherwise, the tables are emitted in every object that references any of
+  // them.
+  if (Module *M = RD->getOwningModule(); M && M->isNamedModule())

ChuanqiXu9 wrote:

Done. I add the interfaces in precommit: 
https://github.com/llvm/llvm-project/commit/99873b35da7ecb905143c8a6b8deca4d4416f1a9

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


[clang] [llvm] [AArch64] Decouple feature dependency expansion. (PR #94279)

2024-06-04 Thread Alexandros Lamprineas via cfe-commits

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


[clang] Support [[guarded_by(mutex)]] attribute inside C struct (PR #94216)

2024-06-04 Thread Pierre d'Herbemont via cfe-commits

https://github.com/pdherbemont updated 
https://github.com/llvm/llvm-project/pull/94216

>From ccf6699197b608f95deea2b03b1ee87e29fbc8e1 Mon Sep 17 00:00:00 2001
From: Pierre d'Herbemont 
Date: Wed, 29 May 2024 11:11:03 +0200
Subject: [PATCH] Support [[guarded_by(mutex)]] attribute inside C struct

Today, it's only supported inside C++ classes or top level C/C++
declaration.

I mostly copied and adapted over the code from the
[[counted_by(value)]] lookup.
---
 clang/include/clang/Parse/Parser.h|  6 ++
 clang/lib/Parse/ParseDecl.cpp | 59 +++
 clang/test/Sema/warn-thread-safety-analysis.c | 10 +++-
 .../SemaCXX/warn-thread-safety-parsing.cpp|  6 +-
 4 files changed, 75 insertions(+), 6 deletions(-)

diff --git a/clang/include/clang/Parse/Parser.h 
b/clang/include/clang/Parse/Parser.h
index d054b8cf0d240..308f6ea121eab 100644
--- a/clang/include/clang/Parse/Parser.h
+++ b/clang/include/clang/Parse/Parser.h
@@ -3128,6 +3128,12 @@ class Parser : public CodeCompletionHandler {
 IdentifierInfo *ScopeName, SourceLocation ScopeLoc,
 ParsedAttr::Form Form);
 
+  void ParseGuardedByAttribute(IdentifierInfo &AttrName,
+   SourceLocation AttrNameLoc,
+   ParsedAttributes &Attrs,
+   IdentifierInfo *ScopeName,
+   SourceLocation ScopeLoc, ParsedAttr::Form Form);
+
   void ParseTypeofSpecifier(DeclSpec &DS);
   SourceLocation ParseDecltypeSpecifier(DeclSpec &DS);
   void AnnotateExistingDecltypeSpecifier(const DeclSpec &DS,
diff --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index c528917437332..58a3de7210455 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -671,6 +671,14 @@ void Parser::ParseGNUAttributeArgs(
 ParseBoundsAttribute(*AttrName, AttrNameLoc, Attrs, ScopeName, ScopeLoc,
  Form);
 return;
+  } else if (AttrKind == ParsedAttr::AT_GuardedBy) {
+ParseGuardedByAttribute(*AttrName, AttrNameLoc, Attrs, ScopeName, ScopeLoc,
+Form);
+return;
+  } else if (AttrKind == ParsedAttr::AT_PtGuardedBy) {
+ParseGuardedByAttribute(*AttrName, AttrNameLoc, Attrs, ScopeName, ScopeLoc,
+Form);
+return;
   } else if (AttrKind == ParsedAttr::AT_CXXAssume) {
 ParseCXXAssumeAttributeArg(Attrs, AttrName, AttrNameLoc, EndLoc, Form);
 return;
@@ -3330,6 +3338,57 @@ void Parser::DistributeCLateParsedAttrs(Decl *Dcl,
   }
 }
 
+/// GuardedBy attributes (e.g., guarded_by):
+///   AttrName '(' expression ')'
+void Parser::ParseGuardedByAttribute(IdentifierInfo &AttrName,
+ SourceLocation AttrNameLoc,
+ ParsedAttributes &Attrs,
+ IdentifierInfo *ScopeName,
+ SourceLocation ScopeLoc,
+ ParsedAttr::Form Form) {
+  assert(Tok.is(tok::l_paren) && "Attribute arg list not starting with '('");
+
+  BalancedDelimiterTracker Parens(*this, tok::l_paren);
+  Parens.consumeOpen();
+
+  if (Tok.is(tok::r_paren)) {
+Diag(Tok.getLocation(), diag::err_argument_required_after_attribute);
+Parens.consumeClose();
+return;
+  }
+
+  ArgsVector ArgExprs;
+  // Don't evaluate argument when the attribute is ignored.
+  using ExpressionKind =
+  Sema::ExpressionEvaluationContextRecord::ExpressionKind;
+  EnterExpressionEvaluationContext EC(
+  Actions, Sema::ExpressionEvaluationContext::PotentiallyEvaluated, 
nullptr,
+  ExpressionKind::EK_BoundsAttrArgument);
+
+  ExprResult ArgExpr(
+  Actions.CorrectDelayedTyposInExpr(ParseAssignmentExpression()));
+
+  if (ArgExpr.isInvalid()) {
+Parens.skipToEnd();
+return;
+  }
+
+  ArgExprs.push_back(ArgExpr.get());
+
+  auto &AL = *Attrs.addNew(
+  &AttrName, SourceRange(AttrNameLoc, Parens.getCloseLocation()), 
ScopeName,
+  ScopeLoc, ArgExprs.data(), ArgExprs.size(), Form);
+
+  if (!Tok.is(tok::r_paren)) {
+Diag(Tok.getLocation(), diag::err_attribute_wrong_number_arguments)
+<< AL << 1;
+Parens.skipToEnd();
+return;
+  }
+
+  Parens.consumeClose();
+}
+
 /// Bounds attributes (e.g., counted_by):
 ///   AttrName '(' expression ')'
 void Parser::ParseBoundsAttribute(IdentifierInfo &AttrName,
diff --git a/clang/test/Sema/warn-thread-safety-analysis.c 
b/clang/test/Sema/warn-thread-safety-analysis.c
index 642ea88ec3c96..abad65b0b9154 100644
--- a/clang/test/Sema/warn-thread-safety-analysis.c
+++ b/clang/test/Sema/warn-thread-safety-analysis.c
@@ -28,7 +28,12 @@
 struct LOCKABLE Mutex {};
 
 struct Foo {
-  struct Mutex *mu_;
+struct Mutex *mu_;
+struct Bar {
+struct Mutex *other_mu;
+} bar;
+  int  a_value GUARDED_BY(mu_);
+  int* a_ptr PT_GUARDED_BY(bar.other_mu);
 };
 
 // Declare mutex l

[clang] [llvm] [AArch64] Decouple feature dependency expansion. (PR #94279)

2024-06-04 Thread Alexandros Lamprineas via cfe-commits


@@ -58,58 +58,57 @@ void v1msve() {}
 // CHECK-LABEL: @plussve() #12
 __attribute__((target("+sve")))
 void plussve() {}
-// CHECK-LABEL: @plussveplussve2() #13
+// CHECK-LABEL: @plussveplussve2() #12
 __attribute__((target("+sve+nosve2")))
 void plussveplussve2() {}
-// CHECK-LABEL: @plussveminusnosve2() #13
+// CHECK-LABEL: @plussveminusnosve2() #12
 __attribute__((target("sve,no-sve2")))
 void plussveminusnosve2() {}
-// CHECK-LABEL: @plusfp16() #14
+// CHECK-LABEL: @plusfp16() #13
 __attribute__((target("+fp16")))
 void plusfp16() {}
 
-// CHECK-LABEL: @all() #15
+// CHECK-LABEL: @all() #14
 __attribute__((target("cpu=neoverse-n1,tune=cortex-a710,arch=armv8.6-a+sve2")))
 void all() {}
-// CHECK-LABEL: @allplusbranchprotection() #16
+// CHECK-LABEL: @allplusbranchprotection() #15
 
__attribute__((target("cpu=neoverse-n1,tune=cortex-a710,arch=armv8.6-a+sve2,branch-protection=standard")))
 void allplusbranchprotection() {}
 
 // These tests check that the user facing and internal llvm name are both 
accepted.
-// CHECK-LABEL: @plusnoneon() #17
+// CHECK-LABEL: @plusnoneon() #16
 __attribute__((target("+noneon")))
 void plusnoneon() {}
-// CHECK-LABEL: @plusnosimd() #17
+// CHECK-LABEL: @plusnosimd() #16
 __attribute__((target("+nosimd")))
 void plusnosimd() {}
-// CHECK-LABEL: @noneon() #17
+// CHECK-LABEL: @noneon() #16
 __attribute__((target("no-neon")))
 void noneon() {}
-// CHECK-LABEL: @nosimd() #17
+// CHECK-LABEL: @nosimd() #16
 __attribute__((target("no-simd")))
 void nosimd() {}
 
 // This isn't part of the standard interface, but test that -arch features 
should not apply anything else.
-// CHECK-LABEL: @minusarch() #18
+// CHECK-LABEL: @minusarch() #17
 __attribute__((target("no-v9.3a")))
 void minusarch() {}
 
 // CHECK: attributes #0 = { {{.*}} 
"target-features"="+crc,+fp-armv8,+lse,+neon,+ras,+rdm,+v8.1a,+v8.2a,+v8a" }
 // CHECK: attributes #1 = { {{.*}} 
"target-features"="+crc,+fp-armv8,+fullfp16,+lse,+neon,+ras,+rdm,+sve,+v8.1a,+v8.2a,+v8a"
 }
 // CHECK: attributes #2 = { {{.*}} 
"target-features"="+crc,+fp-armv8,+fullfp16,+lse,+neon,+ras,+rdm,+sve,+sve2,+v8.1a,+v8.2a,+v8a"
 }
-// CHECK: attributes #3 = { {{.*}} 
"target-features"="+bf16,+complxnum,+crc,+dotprod,+fp-armv8,+fullfp16,+i8mm,+jsconv,+lse,+neon,+pauth,+ras,+rcpc,+rdm,+sve,+sve2,+v8.1a,+v8.2a,+v8.3a,+v8.4a,+v8.5a,+v8.6a,+v8a"
 }
-// CHECK: attributes #4 = { {{.*}} "target-cpu"="cortex-a710" 
"target-features"="+bf16,+complxnum,+crc,+dotprod,+flagm,+fp-armv8,+fp16fml,+fullfp16,+i8mm,+jsconv,+lse,+mte,+neon,+pauth,+ras,+rcpc,+rdm,+sb,+sve,+sve2,+sve2-bitperm"
 }
+// CHECK: attributes #3 = { {{.*}} 
"target-features"="+bf16,+complxnum,+crc,+dotprod,+fp-armv8,+fp16fml,+fullfp16,+i8mm,+jsconv,+lse,+neon,+pauth,+ras,+rcpc,+rdm,+sve,+sve2,+v8.1a,+v8.2a,+v8.3a,+v8.4a,+v8.5a,+v8.6a,+v8a"
 }
+// CHECK: attributes #4 = { {{.*}} "target-cpu"="cortex-a710" 
"target-features"="+bf16,+complxnum,+crc,+dotprod,+flagm,+fp-armv8,+fp16fml,+fullfp16,+i8mm,+jsconv,+lse,+mte,+neon,+pauth,+ras,+rcpc,+rdm,+sb,+sve,+sve2,+sve2-bitperm,+v8.1a,+v8.2a,+v8.3a,+v8.4a,+v8.5a,+v8a,+v9a"
 }
 // CHECK: attributes #5 = { {{.*}} "tune-cpu"="cortex-a710" }
 // CHECK: attributes #6 = { {{.*}} "target-cpu"="generic" }
 // CHECK: attributes #7 = { {{.*}} "tune-cpu"="generic" }
-// CHECK: attributes #8 = { {{.*}} "target-cpu"="neoverse-n1" 
"target-features"="+aes,+crc,+dotprod,+fp-armv8,+fullfp16,+lse,+neon,+ras,+rcpc,+rdm,+sha2,+spe,+ssbs"
 "tune-cpu"="cortex-a710" }
+// CHECK: attributes #8 = { {{.*}} "target-cpu"="neoverse-n1" 
"target-features"="+aes,+crc,+dotprod,+fp-armv8,+fullfp16,+lse,+neon,+ras,+rcpc,+rdm,+sha2,+spe,+ssbs,+v8.1a,+v8.2a,+v8a"
 "tune-cpu"="cortex-a710" }
 // CHECK: attributes #9 = { {{.*}} 
"target-features"="+fp-armv8,+fullfp16,+neon,+sve" "tune-cpu"="cortex-a710" }
-// CHECK: attributes #10 = { {{.*}} "target-cpu"="neoverse-v1" 
"target-features"="+aes,+bf16,+complxnum,+crc,+dotprod,+fp-armv8,+fp16fml,+fullfp16,+i8mm,+jsconv,+lse,+neon,+pauth,+rand,+ras,+rcpc,+rdm,+sha2,+sha3,+sm4,+spe,+ssbs,+sve,+sve2"
 }
-// CHECK: attributes #11 = { {{.*}} "target-cpu"="neoverse-v1" 
"target-features"="+aes,+bf16,+complxnum,+crc,+dotprod,+fp-armv8,+fp16fml,+fullfp16,+i8mm,+jsconv,+lse,+neon,+pauth,+rand,+ras,+rcpc,+rdm,+sha2,+sha3,+sm4,+spe,+ssbs,-sve"
 }
+// CHECK: attributes #10 = { {{.*}} "target-cpu"="neoverse-v1" 
"target-features"="+aes,+bf16,+complxnum,+crc,+dotprod,+fp-armv8,+fp16fml,+fullfp16,+i8mm,+jsconv,+lse,+neon,+pauth,+rand,+ras,+rcpc,+rdm,+sha2,+sha3,+sm4,+spe,+ssbs,+sve,+sve2,+v8.1a,+v8.2a,+v8.3a,+v8.4a,+v8a"
 }
+// CHECK: attributes #11 = { {{.*}} "target-cpu"="neoverse-v1" 
"target-features"="+aes,+bf16,+complxnum,+crc,+dotprod,+fp-armv8,+fp16fml,+fullfp16,+i8mm,+jsconv,+lse,+neon,+pauth,+rand,+ras,+rcpc,+rdm,+sha2,+sha3,+sm4,+spe,+ssbs,+v8.1a,+v8.2a,+v8.3a,+v8.4a,+v8a,-sve"
 }
 // CHECK: attributes #12 = { {{.*}} 
"target-features"="+fp-armv8,+fullfp16,+neon,+sve" }
-// CHECK: attributes #13 = { {{.*}} 
"target-featur

[clang] [llvm] [AArch64] Decouple feature dependency expansion. (PR #94279)

2024-06-04 Thread Alexandros Lamprineas via cfe-commits

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


[clang] [llvm] Enable LLDB tests in pre-merge CI (PR #94208)

2024-06-04 Thread Vlad Serebrennikov via cfe-commits

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


[clang] [llvm] [AArch64] set AppleA14 architecture version to v8.4-a (PR #92600)

2024-06-04 Thread Tomas Matheson via cfe-commits


@@ -286,7 +286,6 @@ void AArch64TargetInfo::getTargetDefinesARMV84A(const 
LangOptions &Opts,
 void AArch64TargetInfo::getTargetDefinesARMV85A(const LangOptions &Opts,
 MacroBuilder &Builder) const {
   Builder.defineMacro("__ARM_FEATURE_FRINT", "1");
-  Builder.defineMacro("__ARM_FEATURE_BTI", "1");

tmatheson-arm wrote:

Generally speaking, we should gate things by specific feature rather than 
architecture, so I think this change is correct regardless of what we do with 
these specific chips.

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


[clang] [llvm] [AArch64] set AppleA14 architecture version to v8.4-a (PR #92600)

2024-06-04 Thread Tomas Matheson via cfe-commits

https://github.com/tmatheson-arm updated 
https://github.com/llvm/llvm-project/pull/92600

>From 518b83ab69c4852f7e7ea71c17df3f58e8ff50ef Mon Sep 17 00:00:00 2001
From: Tomas Matheson 
Date: Fri, 17 May 2024 21:39:17 +0100
Subject: [PATCH 1/3] [AArch64] set AppleA14 architecture version to 8.5

---
 llvm/lib/Target/AArch64/AArch64Processors.td | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/llvm/lib/Target/AArch64/AArch64Processors.td 
b/llvm/lib/Target/AArch64/AArch64Processors.td
index f2286ae17dba5..96422758bc618 100644
--- a/llvm/lib/Target/AArch64/AArch64Processors.td
+++ b/llvm/lib/Target/AArch64/AArch64Processors.td
@@ -718,7 +718,7 @@ def ProcessorFeatures {
   list AppleA13 = [HasV8_4aOps, FeatureCrypto, 
FeatureFPARMv8,
  FeatureNEON, FeaturePerfMon, 
FeatureFullFP16,
  FeatureFP16FML, FeatureSHA3];
-  list AppleA14 = [HasV8_4aOps, FeatureCrypto, 
FeatureFPARMv8,
+  list AppleA14 = [HasV8_5aOps, FeatureCrypto, 
FeatureFPARMv8,
  FeatureNEON, FeaturePerfMon, 
FeatureFRInt3264,
  FeatureSpecRestrict, FeatureSSBS, 
FeatureSB,
  FeaturePredRes, FeatureCacheDeepPersist,

>From 74f6d426fa67b1f794a8ba2ac7c864830ee9c2b2 Mon Sep 17 00:00:00 2001
From: Tomas Matheson 
Date: Mon, 20 May 2024 12:38:52 +0100
Subject: [PATCH 2/3] make m1+a14 v8.4 instead

---
 clang/lib/Basic/Targets/AArch64.cpp|  4 +++-
 clang/test/Driver/aarch64-mac-cpus.c   |  2 +-
 clang/test/Preprocessor/aarch64-target-features.c  |  8 +++-
 .../llvm/TargetParser/AArch64TargetParser.h|  4 ++--
 llvm/lib/Target/AArch64/AArch64Processors.td   | 14 +-
 llvm/test/DebugInfo/debug_frame_symbol.ll  |  2 +-
 .../AddressSanitizer/calls-only-smallfn.ll |  2 +-
 .../Instrumentation/AddressSanitizer/calls-only.ll |  2 +-
 llvm/unittests/TargetParser/TargetParserTest.cpp   |  8 
 9 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/clang/lib/Basic/Targets/AArch64.cpp 
b/clang/lib/Basic/Targets/AArch64.cpp
index 5db1ce78c657f..692ec58235efe 100644
--- a/clang/lib/Basic/Targets/AArch64.cpp
+++ b/clang/lib/Basic/Targets/AArch64.cpp
@@ -286,7 +286,6 @@ void AArch64TargetInfo::getTargetDefinesARMV84A(const 
LangOptions &Opts,
 void AArch64TargetInfo::getTargetDefinesARMV85A(const LangOptions &Opts,
 MacroBuilder &Builder) const {
   Builder.defineMacro("__ARM_FEATURE_FRINT", "1");
-  Builder.defineMacro("__ARM_FEATURE_BTI", "1");
   // Also include the Armv8.4 defines
   getTargetDefinesARMV84A(Opts, Builder);
 }
@@ -499,6 +498,9 @@ void AArch64TargetInfo::getTargetDefines(const LangOptions 
&Opts,
   if (HasPAuthLR)
 Builder.defineMacro("__ARM_FEATURE_PAUTH_LR", "1");
 
+  if (HasBTI)
+Builder.defineMacro("__ARM_FEATURE_BTI", "1");
+
   if (HasUnalignedAccess)
 Builder.defineMacro("__ARM_FEATURE_UNALIGNED", "1");
 
diff --git a/clang/test/Driver/aarch64-mac-cpus.c 
b/clang/test/Driver/aarch64-mac-cpus.c
index 5179731268950..488298cfd2d24 100644
--- a/clang/test/Driver/aarch64-mac-cpus.c
+++ b/clang/test/Driver/aarch64-mac-cpus.c
@@ -16,7 +16,7 @@
 // RUN: %clang --target=arm64-apple-macos -mcpu=apple-m1 -### -c %s 2>&1 | 
FileCheck --check-prefix=EXPLICIT-M1 %s
 
 // CHECK: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu" "apple-m1"
-// CHECK-SAME: "-target-feature" "+v8.5a"
+// CHECK-SAME: "-target-feature" "+v8.4a"
 
 // EXPLICIT-A11: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu" "apple-a11"
 // EXPLICIT-A7: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu" "apple-a7"
diff --git a/clang/test/Preprocessor/aarch64-target-features.c 
b/clang/test/Preprocessor/aarch64-target-features.c
index 82304a15a04a3..3f2c2929c7129 100644
--- a/clang/test/Preprocessor/aarch64-target-features.c
+++ b/clang/test/Preprocessor/aarch64-target-features.c
@@ -335,7 +335,7 @@
 // CHECK-MCPU-CARMEL: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+v8.2a" "-target-feature" "+aes" "-target-feature" "+crc" "-target-feature" 
"+fp-armv8" "-target-feature" "+fullfp16" "-target-feature" "+lse" 
"-target-feature" "+ras" "-target-feature" "+rdm" "-target-feature" "+sha2" 
"-target-feature" "+neon"
 
 // RUN: %clang -target x86_64-apple-macosx -arch arm64 -### -c %s 2>&1 | 
FileCheck --check-prefix=CHECK-ARCH-ARM64 %s
-// CHECK-ARCH-ARM64: "-target-cpu" "apple-m1" "-target-feature" "+zcm" 
"-target-feature" "+zcz" "-target-feature" "+v8.5a" "-target-feature" "+aes" 
"-target-feature" "+crc" "-target-feature" "+dotprod" "-target-feature" 
"+complxnum" "-target-feature" "+fp-armv8" "-target-feature" "+fullfp16" 
"-target-feature" "+fp16fml" "-target-feature" "+jsconv" "-target-feature" 
"+lse" "-target-feature" "+pauth" "-target-feature" "+ras" "-target-feature" 
"+rcpc" "-target-feature" "+rdm" "-target-feature" "+sha2" "-

[clang] [llvm] [AArch64] set AppleA14 architecture version to v8.4-a (PR #92600)

2024-06-04 Thread Tomas Matheson via cfe-commits


@@ -718,12 +718,16 @@ def ProcessorFeatures {
   list AppleA13 = [HasV8_4aOps, FeatureCrypto, 
FeatureFPARMv8,
  FeatureNEON, FeaturePerfMon, 
FeatureFullFP16,
  FeatureFP16FML, FeatureSHA3];
+  // Apple A14 and M1 chips are based on Armv8.5-a but without BTI. Since there

tmatheson-arm wrote:

I don't buy the argument that we shouldn't document something because there are 
lots of other things lacking documentation. What other quirks are you aware of? 
Maybe they should be commented too.

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


[clang] [clang][dataflow] Propagate storage location of compound assignment operators. (PR #94332)

2024-06-04 Thread via cfe-commits

https://github.com/martinboehme created 
https://github.com/llvm/llvm-project/pull/94332

To avoid generating unnecessary values, we don't create a new value but instead
leave it to the specific analysis to do this if desired.


>From 6c3273f278cc497992e9a7ed7fc7fbec439d6207 Mon Sep 17 00:00:00 2001
From: Martin Braenne 
Date: Tue, 4 Jun 2024 10:29:13 +
Subject: [PATCH] [clang][dataflow] Propagate storage location of compound
 assignment operators.

To avoid generating unnecessary values, we don't create a new value but instead
leave it to the specific analysis to do this if desired.
---
 clang/lib/Analysis/FlowSensitive/Transfer.cpp |  7 +++
 .../Analysis/FlowSensitive/TransferTest.cpp   | 20 +++
 2 files changed, 27 insertions(+)

diff --git a/clang/lib/Analysis/FlowSensitive/Transfer.cpp 
b/clang/lib/Analysis/FlowSensitive/Transfer.cpp
index d161b231c0b6f..8109ac6a781e7 100644
--- a/clang/lib/Analysis/FlowSensitive/Transfer.cpp
+++ b/clang/lib/Analysis/FlowSensitive/Transfer.cpp
@@ -147,6 +147,13 @@ class TransferVisitor : public 
ConstStmtVisitor {
 const Expr *RHS = S->getRHS();
 assert(RHS != nullptr);
 
+// Do compound assignments up-front, as there are so many of them and we
+// don't want to list all of them in the switch statement below.
+// To avoid generating unnecessary values, we don't create a new value but
+// instead leave it to the specific analysis to do this if desired.
+if (S->isCompoundAssignmentOp())
+  propagateStorageLocation(*S->getLHS(), *S, Env);
+
 switch (S->getOpcode()) {
 case BO_Assign: {
   auto *LHSLoc = Env.getStorageLocation(*LHS);
diff --git a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
index cdaee9b2c9288..f7e6b0c22e8db 100644
--- a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -3796,6 +3796,26 @@ TEST(TransferTest, Postincrement) {
   });
 }
 
+// We test just one of the compound assignment operators because we know the
+// code for propagating the storage location is shared among all of them.
+TEST(TransferTest, AddAssign) {
+  std::string Code = R"(
+void target(int I) {
+  int &IRef = (I += 1);
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {
+const Environment &Env = getEnvironmentAtAnnotation(Results, "p");
+
+EXPECT_EQ(&getLocForDecl(ASTCtx, Env, "IRef"),
+  &getLocForDecl(ASTCtx, Env, "I"));
+  });
+}
+
 TEST(TransferTest, CannotAnalyzeFunctionTemplate) {
   std::string Code = R"(
 template 

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


[clang] [clang][dataflow] Propagate storage location of compound assignment operators. (PR #94332)

2024-06-04 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: None (martinboehme)


Changes

To avoid generating unnecessary values, we don't create a new value but instead
leave it to the specific analysis to do this if desired.


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


2 Files Affected:

- (modified) clang/lib/Analysis/FlowSensitive/Transfer.cpp (+7) 
- (modified) clang/unittests/Analysis/FlowSensitive/TransferTest.cpp (+20) 


``diff
diff --git a/clang/lib/Analysis/FlowSensitive/Transfer.cpp 
b/clang/lib/Analysis/FlowSensitive/Transfer.cpp
index d161b231c0b6f..8109ac6a781e7 100644
--- a/clang/lib/Analysis/FlowSensitive/Transfer.cpp
+++ b/clang/lib/Analysis/FlowSensitive/Transfer.cpp
@@ -147,6 +147,13 @@ class TransferVisitor : public 
ConstStmtVisitor {
 const Expr *RHS = S->getRHS();
 assert(RHS != nullptr);
 
+// Do compound assignments up-front, as there are so many of them and we
+// don't want to list all of them in the switch statement below.
+// To avoid generating unnecessary values, we don't create a new value but
+// instead leave it to the specific analysis to do this if desired.
+if (S->isCompoundAssignmentOp())
+  propagateStorageLocation(*S->getLHS(), *S, Env);
+
 switch (S->getOpcode()) {
 case BO_Assign: {
   auto *LHSLoc = Env.getStorageLocation(*LHS);
diff --git a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
index cdaee9b2c9288..f7e6b0c22e8db 100644
--- a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -3796,6 +3796,26 @@ TEST(TransferTest, Postincrement) {
   });
 }
 
+// We test just one of the compound assignment operators because we know the
+// code for propagating the storage location is shared among all of them.
+TEST(TransferTest, AddAssign) {
+  std::string Code = R"(
+void target(int I) {
+  int &IRef = (I += 1);
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {
+const Environment &Env = getEnvironmentAtAnnotation(Results, "p");
+
+EXPECT_EQ(&getLocForDecl(ASTCtx, Env, "IRef"),
+  &getLocForDecl(ASTCtx, Env, "I"));
+  });
+}
+
 TEST(TransferTest, CannotAnalyzeFunctionTemplate) {
   std::string Code = R"(
 template 

``




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


[clang] [clang][dataflow] Propagate storage location of compound assignment operators. (PR #94332)

2024-06-04 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang-analysis

Author: None (martinboehme)


Changes

To avoid generating unnecessary values, we don't create a new value but instead
leave it to the specific analysis to do this if desired.


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


2 Files Affected:

- (modified) clang/lib/Analysis/FlowSensitive/Transfer.cpp (+7) 
- (modified) clang/unittests/Analysis/FlowSensitive/TransferTest.cpp (+20) 


``diff
diff --git a/clang/lib/Analysis/FlowSensitive/Transfer.cpp 
b/clang/lib/Analysis/FlowSensitive/Transfer.cpp
index d161b231c0b6f..8109ac6a781e7 100644
--- a/clang/lib/Analysis/FlowSensitive/Transfer.cpp
+++ b/clang/lib/Analysis/FlowSensitive/Transfer.cpp
@@ -147,6 +147,13 @@ class TransferVisitor : public 
ConstStmtVisitor {
 const Expr *RHS = S->getRHS();
 assert(RHS != nullptr);
 
+// Do compound assignments up-front, as there are so many of them and we
+// don't want to list all of them in the switch statement below.
+// To avoid generating unnecessary values, we don't create a new value but
+// instead leave it to the specific analysis to do this if desired.
+if (S->isCompoundAssignmentOp())
+  propagateStorageLocation(*S->getLHS(), *S, Env);
+
 switch (S->getOpcode()) {
 case BO_Assign: {
   auto *LHSLoc = Env.getStorageLocation(*LHS);
diff --git a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
index cdaee9b2c9288..f7e6b0c22e8db 100644
--- a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -3796,6 +3796,26 @@ TEST(TransferTest, Postincrement) {
   });
 }
 
+// We test just one of the compound assignment operators because we know the
+// code for propagating the storage location is shared among all of them.
+TEST(TransferTest, AddAssign) {
+  std::string Code = R"(
+void target(int I) {
+  int &IRef = (I += 1);
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {
+const Environment &Env = getEnvironmentAtAnnotation(Results, "p");
+
+EXPECT_EQ(&getLocForDecl(ASTCtx, Env, "IRef"),
+  &getLocForDecl(ASTCtx, Env, "I"));
+  });
+}
+
 TEST(TransferTest, CannotAnalyzeFunctionTemplate) {
   std::string Code = R"(
 template 

``




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


[clang] [serialization] no transitive decl change (PR #92083)

2024-06-04 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> Unfortunately this is still failing one test on the LLDB macOS CI: 
> https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/5083/execution/node/97/log
> 
> ```
> ==
> FAIL: test_duplicate_decls_gmodules 
> (TestTemplateWithSameArg.TestTemplateWithSameArg)
> --
> Traceback (most recent call last):
>   File 
> "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>  line 1756, in test_method
> return attrvalue(self)
>   File 
> "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/lang/cpp/gmodules/template-with-same-arg/TestTemplateWithSameArg.py",
>  line 66, in test_duplicate_decls
> self.filecheck("target module dump ast", __file__)
>   File 
> "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>  line 2293, in filecheck
> self.assertTrue(cmd_status == 0)
> AssertionError: False is not true
> Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
> --
> Ran 2 tests in 1.682s
> 
> FAILED (failures=1)
> ```
> 
> Let me know if you need help reproducing this.
> 
> Looks like we're doing a FileCheck on the imported LLDB AST:
> 
> ```
> FileCheck output:
> 
> /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/lang/cpp/gmodules/template-with-same-arg/TestTemplateWithSameArg.py:69:10:
>  error: CHECK: expected string not found in input
> # CHECK: ClassTemplateSpecializationDecl {{.*}} imported in Module2 struct 
> ClassInMod3 definition
> ```
> 
> But instead of `imported in Module2 struct ClassInMod3 definition` it's now 
> just `imported struct ClassInMod3 definition`. Maybe we're not setting the 
> module ID correctly in LLDB or something? Does that ring any bells?

@Michael137 hi, how can I run test for it? I tried

```
bin/llvm-lit 
../lldb/test/API/lang/cpp/gmodules/template-with-same-arg/TestTemplateWithSameArg.py
```

but it shows it can't work

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


[clang] [serialization] no transitive decl change (PR #92083)

2024-06-04 Thread David Spickett via cfe-commits

DavidSpickett wrote:

Maybe you can run individual tests with lit but generally I use `lldb-dotest` 
instead:
```
./bin/lldb-dotest.py -p TestTemplateWithSameArg.py
```
(you only need the filename)

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


[clang] [clang-format] Allow open brace with trailing comment (no line break) (PR #89956)

2024-06-04 Thread via cfe-commits

GertyP wrote:

@owenca Re. draft status:  I thought a draft would be a better way (less 
presumptuous, more tentative suggestion) to present one particular solution, 
while acknowledging the possibility of alternatives.  If that's not really the 
way a draft is used or if it's more of a problem (e.g. people simply filtering 
out drafts for whatever reason?) then I can remove the draftness; I just didn't 
want to presume this change is the way to go.

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


[clang] [llvm] Enable LLDB tests in pre-merge CI (PR #94208)

2024-06-04 Thread David Spickett via cfe-commits

DavidSpickett wrote:

https://github.com/llvm/llvm-project/pull/94325 will get us past the compiler 
error.

Some things I noticed testing that:
* There is an lld installed on the machine but it's in a path with spaces so 
lit can't run it. Generally we'd build lld along with lldb and use that in the 
test suite, when I did that it worked.
* LLDB is not being built with scripting enabled, so a lot of the API tests 
won't be run.

For a completed run I got these results:
https://buildkite.com/llvm-project/github-pull-requests/builds/69540#018fe2bf-1cf8-49f7-a680-f44bf01dbaec
```
Failed Tests (4):
  lldb-shell :: Process/Windows/process_load.cpp
  lldb-shell :: SymbolFile/DWARF/x86/dwp-separate-debug-file.cpp
  lldb-shell :: Target/dependent-modules-nodupe-windows.test
  lldb-shell :: Unwind/windows-unaligned-x86_64.test

Testing Time: 38.08s
Total Discovered Tests: 2901
  Unsupported  : 1337 (46.09%)
  Passed   : 1543 (53.19%)
  Expectedly Failed:   17 (0.59%)
  Failed   :4 (0.14%)
```

`dwp-separate-debug-file.cpp` I have fixed, it needed to require Python. 
`windows-unaligned-x86_64.test` just fails to breakpoint, I don't know why. The 
rest are something to do with `kernel32.dll` either not being able to load it, 
or it not showing up in the image list for a debugged program.

I have never seen that before but it does sound like something a security 
setting might effect.

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


[clang] [clang] NFCI: remove obsolete workaround for template default arguments (PR #94311)

2024-06-04 Thread Krystian Stasiowski via cfe-commits

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

LGTM

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


[clang] [clang][test] add TestLanguage.def to specify all tested language versions (PR #94243)

2024-06-04 Thread Julian Schmidt via cfe-commits

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


[clang] [clang] Fix loss of `dllexport` for exported template specialization (PR #93302)

2024-06-04 Thread Andrew Ng via cfe-commits

nga888 wrote:

> > shouldn't there be a test case added for the dropping of dllexport?
> 
> I can't think of a test case that would hit it.

Just for clarification, you want to pursue the `getMostRecentDecl()` approach 
but keep the code for the dropping of `dllexport` even though there appears to 
be no test case that would/can exercise this code?


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


[clang] [amdgpu] Pass variadic arguments without splitting (PR #94083)

2024-06-04 Thread Jon Chesterfield via cfe-commits

JonChesterfield wrote:

@arsenm You're right about passing larger things indirectly. I'm intending to 
land this as-is, with the types inlined, as that unblocks #93362. I'm nervous 
that the extra pointer indirection will hit the same memory error that tweaking 
codegen in that patch hits (it's a similar sort of pattern to the top level 
argument passing) and wish to postpone that until there is a working baseline.

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


[clang] [clang-format] Allow open brace with trailing comment (no line break) (PR #89956)

2024-06-04 Thread via cfe-commits

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


[clang] [clang] Fix-it hint for `++this` -> `++*this` when deref is modifiable (PR #94159)

2024-06-04 Thread Rajveer Singh Bharadwaj via cfe-commits


@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -std=c++23 -fsyntax-only -verify %s
+

Rajveer100 wrote:

Sure, I'll add more.

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


[clang] [libc] [llvm] [AMDGPU] Implement variadic functions by IR lowering (PR #93362)

2024-06-04 Thread Jon Chesterfield via cfe-commits


@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This is an optimization pass for variadic functions. If called from codegen,
+// it can serve as the implementation of variadic functions for a given target.
+//
+// The strategy is to turn the ... part of a variadic function into a va_list
+// and fix up the call sites. The majority of the pass is target independent.
+// The exceptions are the va_list type itself and the rules for where to store
+// variables in memory such that va_arg can iterate over them given a va_list.
+//
+// The majority of the plumbing is splitting the variadic function into a
+// single basic block that packs the variadic arguments into a va_list and
+// a second function that does the work of the original. That packing is
+// exactly what is done by va_start. Further, the transform from ... to va_list
+// replaced va_start with an operation to copy a va_list from the new argument,
+// which is exactly a va_copy. This is useful for reducing target-dependence.
+//
+// A va_list instance is a forward iterator, where the primary operation va_arg
+// is dereference-then-increment. This interface forces significant convergent
+// evolution between target specific implementations. The variation in runtime
+// data layout is limited to that representable by the iterator, parameterised
+// by the type passed to the va_arg instruction.
+//
+// Therefore the majority of the target specific subtlety is packing arguments
+// into a stack allocated buffer such that a va_list can be initialised with it
+// and the va_arg expansion for the target will find the arguments at runtime.
+//
+// The aggregate effect is to unblock other transforms, most critically the
+// general purpose inliner. Known calls to variadic functions become zero cost.
+//
+// Consistency with clang is primarily tested by emitting va_arg using clang
+// then expanding the variadic functions using this pass, followed by trying
+// to constant fold the functions to no-ops.
+//
+// Target specific behaviour is tested in IR - mainly checking that values are
+// put into positions in call frames that make sense for that particular 
target.
+//
+// There is one "clever" invariant in use. va_start intrinsics that are not
+// within a varidic functions are an error in the IR verifier. When this
+// transform moves blocks from a variadic function into a fixed arity one, it
+// moves va_start intrinsics along with everything else. That means that the
+// va_start intrinsics that need to be rewritten to use the trailing argument
+// are exactly those that are in non-variadic functions so no further state
+// is needed to distinguish those that need to be rewritten.
+//
+//===--===//
+
+#include "llvm/Transforms/IPO/ExpandVariadics.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/CodeGen/Passes.h"
+#include "llvm/IR/Constants.h"
+#include "llvm/IR/IRBuilder.h"
+#include "llvm/IR/IntrinsicInst.h"
+#include "llvm/IR/Module.h"
+#include "llvm/IR/PassManager.h"
+#include "llvm/InitializePasses.h"
+#include "llvm/Pass.h"
+#include "llvm/Passes/OptimizationLevel.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/TargetParser/Triple.h"
+#include "llvm/Transforms/Utils/ModuleUtils.h"
+
+#define DEBUG_TYPE "expand-variadics"
+
+using namespace llvm;
+
+namespace {
+
+cl::opt ExpandVariadicsModeOption(
+DEBUG_TYPE "-override", cl::desc("Override the behaviour of " DEBUG_TYPE),
+cl::init(ExpandVariadicsMode::Unspecified),
+cl::values(clEnumValN(ExpandVariadicsMode::Unspecified, "unspecified",
+  "Use the implementation defaults"),
+   clEnumValN(ExpandVariadicsMode::Disable, "disable",
+  "Disable the pass entirely"),
+   clEnumValN(ExpandVariadicsMode::Optimize, "optimize",
+  "Optimise without changing ABI"),
+   clEnumValN(ExpandVariadicsMode::Lowering, "lowering",
+  "Change variadic calling convention")));
+
+bool commandLineOverride() {
+  return ExpandVariadicsModeOption != ExpandVariadicsMode::Unspecified;
+}
+
+// Instances of this class encapsulate the target-dependant behaviour as a
+// function of triple. Implementing a new ABI is adding a case to the switch
+// in create(llvm::Triple) at the end of this file.
+class VariadicABIInfo {
+protected:
+  VariadicABIInfo() {}
+
+public:
+  static std::unique_ptr create(llvm::Triple const &Triple);
+
+  // Allow overriding whether the pass runs on a per-target basis
+  virtual bool enableForTarget() = 0;
+
+  

[clang] [libc] [llvm] [AMDGPU] Implement variadic functions by IR lowering (PR #93362)

2024-06-04 Thread Jon Chesterfield via cfe-commits


@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This is an optimization pass for variadic functions. If called from codegen,
+// it can serve as the implementation of variadic functions for a given target.
+//
+// The strategy is to turn the ... part of a variadic function into a va_list
+// and fix up the call sites. The majority of the pass is target independent.
+// The exceptions are the va_list type itself and the rules for where to store
+// variables in memory such that va_arg can iterate over them given a va_list.
+//
+// The majority of the plumbing is splitting the variadic function into a
+// single basic block that packs the variadic arguments into a va_list and
+// a second function that does the work of the original. That packing is
+// exactly what is done by va_start. Further, the transform from ... to va_list
+// replaced va_start with an operation to copy a va_list from the new argument,
+// which is exactly a va_copy. This is useful for reducing target-dependence.
+//
+// A va_list instance is a forward iterator, where the primary operation va_arg
+// is dereference-then-increment. This interface forces significant convergent
+// evolution between target specific implementations. The variation in runtime
+// data layout is limited to that representable by the iterator, parameterised
+// by the type passed to the va_arg instruction.
+//
+// Therefore the majority of the target specific subtlety is packing arguments
+// into a stack allocated buffer such that a va_list can be initialised with it
+// and the va_arg expansion for the target will find the arguments at runtime.
+//
+// The aggregate effect is to unblock other transforms, most critically the
+// general purpose inliner. Known calls to variadic functions become zero cost.
+//
+// Consistency with clang is primarily tested by emitting va_arg using clang
+// then expanding the variadic functions using this pass, followed by trying
+// to constant fold the functions to no-ops.
+//
+// Target specific behaviour is tested in IR - mainly checking that values are
+// put into positions in call frames that make sense for that particular 
target.
+//
+// There is one "clever" invariant in use. va_start intrinsics that are not
+// within a varidic functions are an error in the IR verifier. When this
+// transform moves blocks from a variadic function into a fixed arity one, it
+// moves va_start intrinsics along with everything else. That means that the
+// va_start intrinsics that need to be rewritten to use the trailing argument
+// are exactly those that are in non-variadic functions so no further state
+// is needed to distinguish those that need to be rewritten.
+//
+//===--===//
+
+#include "llvm/Transforms/IPO/ExpandVariadics.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/CodeGen/Passes.h"
+#include "llvm/IR/Constants.h"
+#include "llvm/IR/IRBuilder.h"
+#include "llvm/IR/IntrinsicInst.h"
+#include "llvm/IR/Module.h"
+#include "llvm/IR/PassManager.h"
+#include "llvm/InitializePasses.h"
+#include "llvm/Pass.h"
+#include "llvm/Passes/OptimizationLevel.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/TargetParser/Triple.h"
+#include "llvm/Transforms/Utils/ModuleUtils.h"
+
+#define DEBUG_TYPE "expand-variadics"
+
+using namespace llvm;
+
+namespace {
+
+cl::opt ExpandVariadicsModeOption(
+DEBUG_TYPE "-override", cl::desc("Override the behaviour of " DEBUG_TYPE),
+cl::init(ExpandVariadicsMode::Unspecified),
+cl::values(clEnumValN(ExpandVariadicsMode::Unspecified, "unspecified",
+  "Use the implementation defaults"),
+   clEnumValN(ExpandVariadicsMode::Disable, "disable",
+  "Disable the pass entirely"),
+   clEnumValN(ExpandVariadicsMode::Optimize, "optimize",
+  "Optimise without changing ABI"),
+   clEnumValN(ExpandVariadicsMode::Lowering, "lowering",
+  "Change variadic calling convention")));
+
+bool commandLineOverride() {
+  return ExpandVariadicsModeOption != ExpandVariadicsMode::Unspecified;
+}
+
+// Instances of this class encapsulate the target-dependant behaviour as a
+// function of triple. Implementing a new ABI is adding a case to the switch
+// in create(llvm::Triple) at the end of this file.
+class VariadicABIInfo {
+protected:
+  VariadicABIInfo() {}
+
+public:
+  static std::unique_ptr create(llvm::Triple const &Triple);
+
+  // Allow overriding whether the pass runs on a per-target basis
+  virtual bool enableForTarget() = 0;
+
+  

[clang] [clang] Fix-it hint for `++this` -> `++*this` when deref is modifiable (PR #94159)

2024-06-04 Thread Rajveer Singh Bharadwaj via cfe-commits

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


[clang] 924611b - [clang] NFCI: remove obsolete workaround for template default arguments (#94311)

2024-06-04 Thread via cfe-commits

Author: Matheus Izvekov
Date: 2024-06-04T08:52:17-03:00
New Revision: 924611b0301f751e8c3fef9759b9d2683b0345fc

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

LOG: [clang] NFCI: remove obsolete workaround for template default arguments 
(#94311)

Added: 


Modified: 
clang/include/clang/AST/TemplateName.h
clang/lib/AST/TemplateName.cpp
clang/lib/Sema/SemaTemplateInstantiate.cpp

Removed: 




diff  --git a/clang/include/clang/AST/TemplateName.h 
b/clang/include/clang/AST/TemplateName.h
index 7aedc086ab7d0..489fccb2ef74d 100644
--- a/clang/include/clang/AST/TemplateName.h
+++ b/clang/include/clang/AST/TemplateName.h
@@ -314,11 +314,6 @@ class TemplateName {
 
   TemplateName getUnderlying() const;
 
-  /// Get the template name to substitute when this template name is used as a
-  /// template template argument. This refers to the most recent declaration of
-  /// the template, including any default template arguments.
-  TemplateName getNameToSubstitute() const;
-
   TemplateNameDependence getDependence() const;
 
   /// Determines whether this is a dependent template name.

diff  --git a/clang/lib/AST/TemplateName.cpp b/clang/lib/AST/TemplateName.cpp
index 3dbdad92813f6..4fc25cb34803e 100644
--- a/clang/lib/AST/TemplateName.cpp
+++ b/clang/lib/AST/TemplateName.cpp
@@ -214,23 +214,6 @@ UsingShadowDecl *TemplateName::getAsUsingShadowDecl() 
const {
   return nullptr;
 }
 
-TemplateName TemplateName::getNameToSubstitute() const {
-  TemplateDecl *Decl = getAsTemplateDecl();
-
-  // Substituting a dependent template name: preserve it as written.
-  if (!Decl)
-return *this;
-
-  // If we have a template declaration, use the most recent non-friend
-  // declaration of that template.
-  Decl = cast(Decl->getMostRecentDecl());
-  while (Decl->getFriendObjectKind()) {
-Decl = cast(Decl->getPreviousDecl());
-assert(Decl && "all declarations of template are friends");
-  }
-  return TemplateName(Decl);
-}
-
 TemplateNameDependence TemplateName::getDependence() const {
   auto D = TemplateNameDependence::None;
   switch (getKind()) {

diff  --git a/clang/lib/Sema/SemaTemplateInstantiate.cpp 
b/clang/lib/Sema/SemaTemplateInstantiate.cpp
index abb8a260faab9..863cc53c55afa 100644
--- a/clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -1856,7 +1856,7 @@ Decl *TemplateInstantiator::TransformDecl(SourceLocation 
Loc, Decl *D) {
 Arg = getPackSubstitutedTemplateArgument(getSema(), Arg);
   }
 
-  TemplateName Template = Arg.getAsTemplate().getNameToSubstitute();
+  TemplateName Template = Arg.getAsTemplate();
   assert(!Template.isNull() && Template.getAsTemplateDecl() &&
  "Wrong kind of template template argument");
   return Template.getAsTemplateDecl();
@@ -2029,10 +2029,8 @@ TemplateName TemplateInstantiator::TransformTemplateName(
 Arg = getPackSubstitutedTemplateArgument(getSema(), Arg);
   }
 
-  TemplateName Template = Arg.getAsTemplate().getNameToSubstitute();
+  TemplateName Template = Arg.getAsTemplate();
   assert(!Template.isNull() && "Null template template argument");
-  assert(!Template.getAsQualifiedTemplateName() &&
- "template decl to substitute is qualified?");
 
   if (Final)
 return Template;
@@ -2052,8 +2050,8 @@ TemplateName TemplateInstantiator::TransformTemplateName(
 if (SubstPack->getFinal())
   return Template;
 return getSema().Context.getSubstTemplateTemplateParm(
-Template.getNameToSubstitute(), SubstPack->getAssociatedDecl(),
-SubstPack->getIndex(), getPackIndex(Pack));
+Template, SubstPack->getAssociatedDecl(), SubstPack->getIndex(),
+getPackIndex(Pack));
   }
 
   return inherited::TransformTemplateName(SS, Name, NameLoc, ObjectType,



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


[clang] [clang] NFCI: remove obsolete workaround for template default arguments (PR #94311)

2024-06-04 Thread Matheus Izvekov via cfe-commits

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


[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)

2024-06-04 Thread Pengcheng Wang via cfe-commits

wangpc-pp wrote:

> This broke building clang on Windows with PGO:
> 
> ```
> FAILED: bin/clang-repl.exe lib/clang-repl.lib 
> cmd.exe /C "cmd.exe /C "D:\task_171745452431588\fetches\cmake\bin\cmake.exe 
> -E __create_def 
> D:\task_171745452431588\fetches\llvm-project\build\stage2\build\tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir\.\exports.def
>  
> D:\task_171745452431588\fetches\llvm-project\build\stage2\build\tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir\.\exports.def.objs
>  --nm=D:\task_171745452431588\fetches\clang\bin\llvm-nm.exe && cd 
> D:\task_171745452431588\fetches\llvm-project\build\stage2\build" && 
> D:\task_171745452431588\fetches\cmake\bin\cmake.exe -E vs_link_exe 
> --intdir=tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir 
> --rc="D:\task_171745452431588\fetches\vs\Windows 
> Kits\10\bin\10.0.22621.0\x64\rc.exe" 
> --mt="D:\task_171745452431588\fetches\vs\Windows 
> Kits\10\bin\10.0.22621.0\x64\mt.exe" --manifests  -- 
> D:\task_171745452431588\fetches\clang\bin\lld-link.exe /nologo 
> @CMakeFiles\clang-repl.rsp  /out:bin\clang-repl.exe 
> /implib:lib\clang-repl.lib /pdb:bin\clang-repl.pdb /version:0.0 /machine:x64 
> /STACK:1000 
> /libpath:"D:/task_171745452431588/fetches/clang/lib/clang/19/lib/windows" 
> /INCREMENTAL:NO /subsystem:console   /EXPORT:??_7type_info@@6B@ 
> /EXPORT:?__type_info_root_node@@3U__type_info_node@@A 
> /EXPORT:?nothrow@std@@3Unothrow_t@1@B /EXPORT:_Init_thread_abort 
> /EXPORT:_Init_thread_epoch /EXPORT:_Init_thread_footer 
> /EXPORT:_Init_thread_header /EXPORT:_tls_index /EXPORT:??2@YAPEAX_K@Z 
> /EXPORT:??3@YAXPEAX@Z /EXPORT:??_U@YAPEAX_K@Z /EXPORT:??_V@YAXPEAX@Z 
> /EXPORT:??3@YAXPEAX_K@Z 
> /DEF:"D:/task_171745452431588/fetches/llvm-project/build/stage2/build/tools/clang/tools/clang-repl/clang-repl.def"
>   -Wl,--long-plt 
> /DEF:tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir\.\exports.def  && 
> cd ."
> LINK: command "D:\task_171745452431588\fetches\clang\bin\lld-link.exe /nologo 
> @CMakeFiles\clang-repl.rsp /out:bin\clang-repl.exe /implib:lib\clang-repl.lib 
> /pdb:bin\clang-repl.pdb /version:0.0 /machine:x64 /STACK:1000 
> /libpath:D:/task_171745452431588/fetches/clang/lib/clang/19/lib/windows 
> /INCREMENTAL:NO /subsystem:console /EXPORT:??_7type_info@@6B@ 
> /EXPORT:?__type_info_root_node@@3U__type_info_node@@A 
> /EXPORT:?nothrow@std@@3Unothrow_t@1@B /EXPORT:_Init_thread_abort 
> /EXPORT:_Init_thread_epoch /EXPORT:_Init_thread_footer 
> /EXPORT:_Init_thread_header /EXPORT:_tls_index /EXPORT:??2@YAPEAX_K@Z 
> /EXPORT:??3@YAXPEAX@Z /EXPORT:??_U@YAPEAX_K@Z /EXPORT:??_V@YAXPEAX@Z 
> /EXPORT:??3@YAXPEAX_K@Z 
> /DEF:D:/task_171745452431588/fetches/llvm-project/build/stage2/build/tools/clang/tools/clang-repl/clang-repl.def
>  -Wl,--long-plt 
> /DEF:tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir\.\exports.def 
> /MANIFEST /MANIFESTFILE:bin\clang-repl.exe.manifest" failed (exit code 1) 
> with the following output:
> lld-link: error: : undefined symbol: __profc_??$?0$$BY03DUdesc
> lld-link: error: : undefined symbol: __profc_??$?0$$BY04DW4OptionHidden
> lld-link: error: : undefined symbol: __profc_??$?0$$BY09DW4OptionHidden
> lld-link: error: : undefined symbol: __profc_??$?0$$BY0BC
> lld-link: error: : undefined symbol: __profc_??$?0$$BY0N
> lld-link: error: : undefined symbol: __profc_??$?0W4FormattingFlags
> lld-link: error: : undefined symbol: __profc_??$?4$$BY05D
> lld-link: error: : undefined symbol: __profc_??$?6PEBD
> lld-link: error: : undefined symbol: __profc_??$_Emplace_reallocate
> lld-link: error: : undefined symbol: __profc_??$_Reallocate_for
> lld-link: error: : undefined symbol: __profc_??$_Reallocate_grow_by
> lld-link: error: : undefined symbol: __profc_??$_Traits_find 
> lld-link: error: : undefined symbol: __profc_??$_Traits_rfind
> lld-link: error: : undefined symbol: __profc_??$_Uninitialized_move
> lld-link: error: : undefined symbol: __profc_??$addValue
> lld-link: error: : undefined symbol: __profc_??$handleErrors 
> lld-link: error: : undefined symbol: __profc_??$setValue
> lld-link: error: : undefined symbol: __profc_??0?$OptionValueCopy
> lld-link: error: : undefined symbol: __profc_??0Completion
> lld-link: error: : undefined symbol: __profc_??0ErrorList
> lld-link: error: too many errors emitted, stopping now (use /errorlimit:0 to 
> see all errors)
> ```

I don't have such environment, can you provide more details? And it seems these 
undefined symbols are not symbols for `delete`.

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


[clang] [libc] [llvm] [AMDGPU] Implement variadic functions by IR lowering (PR #93362)

2024-06-04 Thread Jon Chesterfield via cfe-commits


@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This is an optimization pass for variadic functions. If called from codegen,
+// it can serve as the implementation of variadic functions for a given target.
+//
+// The strategy is to turn the ... part of a variadic function into a va_list
+// and fix up the call sites. The majority of the pass is target independent.
+// The exceptions are the va_list type itself and the rules for where to store
+// variables in memory such that va_arg can iterate over them given a va_list.
+//
+// The majority of the plumbing is splitting the variadic function into a
+// single basic block that packs the variadic arguments into a va_list and
+// a second function that does the work of the original. That packing is
+// exactly what is done by va_start. Further, the transform from ... to va_list
+// replaced va_start with an operation to copy a va_list from the new argument,
+// which is exactly a va_copy. This is useful for reducing target-dependence.
+//
+// A va_list instance is a forward iterator, where the primary operation va_arg
+// is dereference-then-increment. This interface forces significant convergent
+// evolution between target specific implementations. The variation in runtime
+// data layout is limited to that representable by the iterator, parameterised
+// by the type passed to the va_arg instruction.
+//
+// Therefore the majority of the target specific subtlety is packing arguments
+// into a stack allocated buffer such that a va_list can be initialised with it
+// and the va_arg expansion for the target will find the arguments at runtime.
+//
+// The aggregate effect is to unblock other transforms, most critically the
+// general purpose inliner. Known calls to variadic functions become zero cost.
+//
+// Consistency with clang is primarily tested by emitting va_arg using clang
+// then expanding the variadic functions using this pass, followed by trying
+// to constant fold the functions to no-ops.
+//
+// Target specific behaviour is tested in IR - mainly checking that values are
+// put into positions in call frames that make sense for that particular 
target.
+//
+// There is one "clever" invariant in use. va_start intrinsics that are not
+// within a varidic functions are an error in the IR verifier. When this
+// transform moves blocks from a variadic function into a fixed arity one, it
+// moves va_start intrinsics along with everything else. That means that the
+// va_start intrinsics that need to be rewritten to use the trailing argument
+// are exactly those that are in non-variadic functions so no further state
+// is needed to distinguish those that need to be rewritten.
+//
+//===--===//
+
+#include "llvm/Transforms/IPO/ExpandVariadics.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/CodeGen/Passes.h"
+#include "llvm/IR/Constants.h"
+#include "llvm/IR/IRBuilder.h"
+#include "llvm/IR/IntrinsicInst.h"
+#include "llvm/IR/Module.h"
+#include "llvm/IR/PassManager.h"
+#include "llvm/InitializePasses.h"
+#include "llvm/Pass.h"
+#include "llvm/Passes/OptimizationLevel.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/TargetParser/Triple.h"
+#include "llvm/Transforms/Utils/ModuleUtils.h"
+
+#define DEBUG_TYPE "expand-variadics"
+
+using namespace llvm;
+
+namespace {
+
+cl::opt ExpandVariadicsModeOption(
+DEBUG_TYPE "-override", cl::desc("Override the behaviour of " DEBUG_TYPE),
+cl::init(ExpandVariadicsMode::Unspecified),
+cl::values(clEnumValN(ExpandVariadicsMode::Unspecified, "unspecified",
+  "Use the implementation defaults"),
+   clEnumValN(ExpandVariadicsMode::Disable, "disable",
+  "Disable the pass entirely"),
+   clEnumValN(ExpandVariadicsMode::Optimize, "optimize",
+  "Optimise without changing ABI"),
+   clEnumValN(ExpandVariadicsMode::Lowering, "lowering",
+  "Change variadic calling convention")));
+
+bool commandLineOverride() {
+  return ExpandVariadicsModeOption != ExpandVariadicsMode::Unspecified;
+}
+
+// Instances of this class encapsulate the target-dependant behaviour as a
+// function of triple. Implementing a new ABI is adding a case to the switch
+// in create(llvm::Triple) at the end of this file.
+class VariadicABIInfo {
+protected:
+  VariadicABIInfo() {}
+
+public:
+  static std::unique_ptr create(llvm::Triple const &Triple);
+
+  // Allow overriding whether the pass runs on a per-target basis
+  virtual bool enableForTarget() = 0;
+
+  

[clang] [clang][RISCV] Update vcpop.v C interface to follow the nameing convention (PR #94318)

2024-06-04 Thread Pengcheng Wang via cfe-commits

wangpc-pp wrote:

This seems to be a breaking change, do we need to create issue in 
https://github.com/riscv-non-isa/rvv-intrinsic-doc?

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


[clang] [clang][RISCV] Update vcpop.v C interface to follow the nameing convention (PR #94318)

2024-06-04 Thread Pengcheng Wang via cfe-commits

https://github.com/wangpc-pp approved this pull request.

LGTM.

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


[clang] [libc] [llvm] [AMDGPU] Implement variadic functions by IR lowering (PR #93362)

2024-06-04 Thread Jon Chesterfield via cfe-commits


@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This is an optimization pass for variadic functions. If called from codegen,
+// it can serve as the implementation of variadic functions for a given target.
+//
+// The strategy is to turn the ... part of a variadic function into a va_list
+// and fix up the call sites. The majority of the pass is target independent.
+// The exceptions are the va_list type itself and the rules for where to store
+// variables in memory such that va_arg can iterate over them given a va_list.
+//
+// The majority of the plumbing is splitting the variadic function into a
+// single basic block that packs the variadic arguments into a va_list and
+// a second function that does the work of the original. That packing is
+// exactly what is done by va_start. Further, the transform from ... to va_list
+// replaced va_start with an operation to copy a va_list from the new argument,
+// which is exactly a va_copy. This is useful for reducing target-dependence.
+//
+// A va_list instance is a forward iterator, where the primary operation va_arg
+// is dereference-then-increment. This interface forces significant convergent
+// evolution between target specific implementations. The variation in runtime
+// data layout is limited to that representable by the iterator, parameterised
+// by the type passed to the va_arg instruction.
+//
+// Therefore the majority of the target specific subtlety is packing arguments
+// into a stack allocated buffer such that a va_list can be initialised with it
+// and the va_arg expansion for the target will find the arguments at runtime.
+//
+// The aggregate effect is to unblock other transforms, most critically the
+// general purpose inliner. Known calls to variadic functions become zero cost.
+//
+// Consistency with clang is primarily tested by emitting va_arg using clang
+// then expanding the variadic functions using this pass, followed by trying
+// to constant fold the functions to no-ops.
+//
+// Target specific behaviour is tested in IR - mainly checking that values are
+// put into positions in call frames that make sense for that particular 
target.
+//
+// There is one "clever" invariant in use. va_start intrinsics that are not
+// within a varidic functions are an error in the IR verifier. When this
+// transform moves blocks from a variadic function into a fixed arity one, it
+// moves va_start intrinsics along with everything else. That means that the
+// va_start intrinsics that need to be rewritten to use the trailing argument
+// are exactly those that are in non-variadic functions so no further state
+// is needed to distinguish those that need to be rewritten.
+//
+//===--===//
+
+#include "llvm/Transforms/IPO/ExpandVariadics.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/CodeGen/Passes.h"
+#include "llvm/IR/Constants.h"
+#include "llvm/IR/IRBuilder.h"
+#include "llvm/IR/IntrinsicInst.h"
+#include "llvm/IR/Module.h"
+#include "llvm/IR/PassManager.h"
+#include "llvm/InitializePasses.h"
+#include "llvm/Pass.h"
+#include "llvm/Passes/OptimizationLevel.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/TargetParser/Triple.h"
+#include "llvm/Transforms/Utils/ModuleUtils.h"
+
+#define DEBUG_TYPE "expand-variadics"
+
+using namespace llvm;
+
+namespace {
+
+cl::opt ExpandVariadicsModeOption(
+DEBUG_TYPE "-override", cl::desc("Override the behaviour of " DEBUG_TYPE),
+cl::init(ExpandVariadicsMode::Unspecified),
+cl::values(clEnumValN(ExpandVariadicsMode::Unspecified, "unspecified",
+  "Use the implementation defaults"),
+   clEnumValN(ExpandVariadicsMode::Disable, "disable",
+  "Disable the pass entirely"),
+   clEnumValN(ExpandVariadicsMode::Optimize, "optimize",
+  "Optimise without changing ABI"),
+   clEnumValN(ExpandVariadicsMode::Lowering, "lowering",
+  "Change variadic calling convention")));
+
+bool commandLineOverride() {
+  return ExpandVariadicsModeOption != ExpandVariadicsMode::Unspecified;
+}
+
+// Instances of this class encapsulate the target-dependant behaviour as a
+// function of triple. Implementing a new ABI is adding a case to the switch
+// in create(llvm::Triple) at the end of this file.
+class VariadicABIInfo {
+protected:
+  VariadicABIInfo() {}
+
+public:
+  static std::unique_ptr create(llvm::Triple const &Triple);
+
+  // Allow overriding whether the pass runs on a per-target basis
+  virtual bool enableForTarget() = 0;
+
+  

[clang] 3b020d5 - [clang][ASTImport] fix issue on anonymous enum import (#93923)

2024-06-04 Thread via cfe-commits

Author: Qizhi Hu
Date: 2024-06-04T20:06:15+08:00
New Revision: 3b020d51f1c96980b1813e5148dbbd6af91669cf

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

LOG: [clang][ASTImport] fix issue on anonymous enum import (#93923)

Don't skip searching in `ToContext` during importing `EnumDecl`. And
`IsStructuralMatch` in `StructralEquivalence` can make sure to determine
whether the found result is match or not.

-

Co-authored-by: huqizhi <836744...@qq.com>

Added: 


Modified: 
clang/lib/AST/ASTImporter.cpp
clang/unittests/AST/ASTImporterTest.cpp

Removed: 




diff  --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index cab5ee6047956..3b9080e09b331 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -2929,7 +2929,7 @@ ExpectedDecl ASTNodeImporter::VisitEnumDecl(EnumDecl *D) {
 
   // We may already have an enum of the same name; try to find and match it.
   EnumDecl *PrevDecl = nullptr;
-  if (!DC->isFunctionOrMethod() && SearchName) {
+  if (!DC->isFunctionOrMethod()) {
 SmallVector ConflictingDecls;
 auto FoundDecls =
 Importer.findDeclsInToCtx(DC, SearchName);

diff  --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index 3dc1c336365d1..92f9bae6cb064 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -9674,6 +9674,46 @@ TEST_P(ASTImporterOptionSpecificTestBase, 
ImportInstantiatedFromMember) {
   EXPECT_TRUE(ImportedPartialSpecialization->getInstantiatedFromMember());
 }
 
+AST_MATCHER_P(EnumDecl, hasEnumConstName, StringRef, ConstName) {
+  for (EnumConstantDecl *D : Node.enumerators())
+if (D->getName() == ConstName)
+  return true;
+  return false;
+}
+
+TEST_P(ASTImporterOptionSpecificTestBase, ImportAnonymousEnum) {
+  const char *ToCode =
+  R"(
+  struct A {
+enum { E1, E2} x;
+enum { E3, E4} y;
+  };
+  )";
+  Decl *ToTU = getToTuDecl(ToCode, Lang_CXX11);
+  auto *ToE1 = FirstDeclMatcher().match(
+  ToTU, enumDecl(hasEnumConstName("E1")));
+  auto *ToE3 = FirstDeclMatcher().match(
+  ToTU, enumDecl(hasEnumConstName("E3")));
+  const char *Code =
+  R"(
+  struct A {
+enum { E1, E2} x;
+enum { E3, E4} y;
+  };
+  )";
+  Decl *FromTU = getTuDecl(Code, Lang_CXX11);
+  auto *FromE1 = FirstDeclMatcher().match(
+  FromTU, enumDecl(hasEnumConstName("E1")));
+  auto *ImportedE1 = Import(FromE1, Lang_CXX11);
+  ASSERT_TRUE(ImportedE1);
+  EXPECT_EQ(ImportedE1, ToE1);
+  auto *FromE3 = FirstDeclMatcher().match(
+  FromTU, enumDecl(hasEnumConstName("E3")));
+  auto *ImportedE3 = Import(FromE3, Lang_CXX11);
+  ASSERT_TRUE(ImportedE3);
+  EXPECT_EQ(ImportedE3, ToE3);
+}
+
 INSTANTIATE_TEST_SUITE_P(ParameterizedTests, ASTImporterLookupTableTest,
  DefaultTestValuesForRunOptions);
 



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


[clang] [clang][ASTImport] fix issue on anonymous enum import (PR #93923)

2024-06-04 Thread Qizhi Hu via cfe-commits

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


[clang] [libc] [llvm] [AMDGPU] Implement variadic functions by IR lowering (PR #93362)

2024-06-04 Thread Jon Chesterfield via cfe-commits


@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This is an optimization pass for variadic functions. If called from codegen,
+// it can serve as the implementation of variadic functions for a given target.
+//
+// The strategy is to turn the ... part of a variadic function into a va_list
+// and fix up the call sites. The majority of the pass is target independent.
+// The exceptions are the va_list type itself and the rules for where to store
+// variables in memory such that va_arg can iterate over them given a va_list.
+//
+// The majority of the plumbing is splitting the variadic function into a
+// single basic block that packs the variadic arguments into a va_list and
+// a second function that does the work of the original. That packing is
+// exactly what is done by va_start. Further, the transform from ... to va_list
+// replaced va_start with an operation to copy a va_list from the new argument,
+// which is exactly a va_copy. This is useful for reducing target-dependence.
+//
+// A va_list instance is a forward iterator, where the primary operation va_arg
+// is dereference-then-increment. This interface forces significant convergent
+// evolution between target specific implementations. The variation in runtime
+// data layout is limited to that representable by the iterator, parameterised
+// by the type passed to the va_arg instruction.
+//
+// Therefore the majority of the target specific subtlety is packing arguments
+// into a stack allocated buffer such that a va_list can be initialised with it
+// and the va_arg expansion for the target will find the arguments at runtime.
+//
+// The aggregate effect is to unblock other transforms, most critically the
+// general purpose inliner. Known calls to variadic functions become zero cost.
+//
+// Consistency with clang is primarily tested by emitting va_arg using clang
+// then expanding the variadic functions using this pass, followed by trying
+// to constant fold the functions to no-ops.
+//
+// Target specific behaviour is tested in IR - mainly checking that values are
+// put into positions in call frames that make sense for that particular 
target.
+//
+// There is one "clever" invariant in use. va_start intrinsics that are not
+// within a varidic functions are an error in the IR verifier. When this
+// transform moves blocks from a variadic function into a fixed arity one, it
+// moves va_start intrinsics along with everything else. That means that the
+// va_start intrinsics that need to be rewritten to use the trailing argument
+// are exactly those that are in non-variadic functions so no further state
+// is needed to distinguish those that need to be rewritten.
+//
+//===--===//
+
+#include "llvm/Transforms/IPO/ExpandVariadics.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/CodeGen/Passes.h"
+#include "llvm/IR/Constants.h"
+#include "llvm/IR/IRBuilder.h"
+#include "llvm/IR/IntrinsicInst.h"
+#include "llvm/IR/Module.h"
+#include "llvm/IR/PassManager.h"
+#include "llvm/InitializePasses.h"
+#include "llvm/Pass.h"
+#include "llvm/Passes/OptimizationLevel.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/TargetParser/Triple.h"
+#include "llvm/Transforms/Utils/ModuleUtils.h"
+
+#define DEBUG_TYPE "expand-variadics"
+
+using namespace llvm;
+
+namespace {
+
+cl::opt ExpandVariadicsModeOption(
+DEBUG_TYPE "-override", cl::desc("Override the behaviour of " DEBUG_TYPE),
+cl::init(ExpandVariadicsMode::Unspecified),
+cl::values(clEnumValN(ExpandVariadicsMode::Unspecified, "unspecified",
+  "Use the implementation defaults"),
+   clEnumValN(ExpandVariadicsMode::Disable, "disable",
+  "Disable the pass entirely"),
+   clEnumValN(ExpandVariadicsMode::Optimize, "optimize",
+  "Optimise without changing ABI"),
+   clEnumValN(ExpandVariadicsMode::Lowering, "lowering",
+  "Change variadic calling convention")));
+
+bool commandLineOverride() {
+  return ExpandVariadicsModeOption != ExpandVariadicsMode::Unspecified;
+}
+
+// Instances of this class encapsulate the target-dependant behaviour as a
+// function of triple. Implementing a new ABI is adding a case to the switch
+// in create(llvm::Triple) at the end of this file.
+class VariadicABIInfo {
+protected:
+  VariadicABIInfo() {}
+
+public:
+  static std::unique_ptr create(llvm::Triple const &Triple);
+
+  // Allow overriding whether the pass runs on a per-target basis
+  virtual bool enableForTarget() = 0;
+
+  

[clang] [amdgpu] Pass variadic arguments without splitting (PR #94083)

2024-06-04 Thread Jon Chesterfield via cfe-commits

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


[clang] [amdgpu] Pass variadic arguments without splitting (PR #94083)

2024-06-04 Thread Jon Chesterfield via cfe-commits

JonChesterfield wrote:

Slightly jumped the gun on this patch because Eli just wrote a bunch of useful 
things on #93362 and there's therefore a credible chance that rebasing on this 
will get the pass in the hands of other people soon, giving libc sprintf and so 
forth.

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


[clang] [libc] [llvm] [AMDGPU] Implement variadic functions by IR lowering (PR #93362)

2024-06-04 Thread Jon Chesterfield via cfe-commits


@@ -33,6 +33,7 @@ static_library("IPO") {
 "DeadArgumentElimination.cpp",
 "ElimAvailExtern.cpp",
 "EmbedBitcodePass.cpp",
+"ExpandVariadics.cpp",

JonChesterfield wrote:

Nice, I did not know what. I am indeed not a BUILD.gn user.

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


[clang] [libc] [llvm] [AMDGPU] Implement variadic functions by IR lowering (PR #93362)

2024-06-04 Thread Jon Chesterfield via cfe-commits

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


[clang] [clang][dataflow] Propagate storage location of compound assignment operators. (PR #94332)

2024-06-04 Thread Yitzhak Mandelbaum via cfe-commits

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


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


[clang] [clang] Fix loss of `dllexport` for exported template specialization (PR #93302)

2024-06-04 Thread via cfe-commits

zmodem wrote:

Yes.

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


[clang] [libc] [llvm] [AMDGPU] Implement variadic functions by IR lowering (PR #93362)

2024-06-04 Thread Jon Chesterfield via cfe-commits

JonChesterfield wrote:

Majority of review comments applied. Merged 94083 (with apologies to Matt) and 
rebased.

I claim the top level strategy of "turn ... into va_list then fix up known call 
sites" is a reasonable strategy for optimising variadic functions. The target 
specific quirks being abstracted over by the existing va_list interface is 
pleasing.

The target abstraction here is not totally what I want it to be and there are 
some simplifying assumptions (e.g. the C calling conv check probably needs to 
be under target-specific, variadic invokes exist in libc++) that won't survive 
for long.

Still, I think this is a worthwhile step forward. It's the machinery needed to 
render variadic functions zero cost at compile time, and gives back ends with 
freedom over their ABI the option to totally ignore variadic functions. 
@bigboze this is the pass I looked for during the IPU bring up - it would have 
been great to say "a void *, four byte alignment seems fine" and cross 
"implement varargs" off the backlog in half an hour, instead of hand 
implementing the thing in sdag. Shipping this would also mean successfully 
avoiding implementing varargs in sdag and globalisel for amdgpu, and whatever 
nvptx codegen uses, so there's a definite code reuse theme from the IR strategy.

My near immediate future involves trying to work out what the 
addrspace/struct/memory-error weirdness on amdgpu is but I'm also looking 
forward to the variadic wrapper functions in my headers on x64 disappearing at 
O1 time.

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


[clang] [clang][CodeGen] Fix EmitInvariantStart for non-zero addrspace (PR #94346)

2024-06-04 Thread Bruno De Fraine via cfe-commits

https://github.com/brunodf-snps created 
https://github.com/llvm/llvm-project/pull/94346

The `llvm.invariant.start` intrinsic is already overloaded to work with memory 
objects in any address space. We simply instantiate the intrinsic with the 
appropriate pointer type.

Fixes #94345.

>From ea1a8a67e840a718324a7256e3917207c5661ab5 Mon Sep 17 00:00:00 2001
From: Bruno De Fraine 
Date: Tue, 4 Jun 2024 14:44:30 +0200
Subject: [PATCH] [clang][CodeGen] Fix EmitInvariantStart for non-zero
 addrspace

The `llvm.invariant.start` intrinsic is already overloaded to work with
memory objects in any address space. We simply instantiate the intrinsic
with the appropriate pointer type.

Fixes #94345.

Co-authored-by: Vito Kortbeek 
---
 clang/lib/CodeGen/CGDeclCXX.cpp  | 3 ++-
 clang/test/CodeGenCXX/init-invariant.cpp | 6 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/clang/lib/CodeGen/CGDeclCXX.cpp b/clang/lib/CodeGen/CGDeclCXX.cpp
index b047279912f6b..a0429435dbe7e 100644
--- a/clang/lib/CodeGen/CGDeclCXX.cpp
+++ b/clang/lib/CodeGen/CGDeclCXX.cpp
@@ -162,7 +162,8 @@ void CodeGenFunction::EmitInvariantStart(llvm::Constant 
*Addr, CharUnits Size) {
   // Grab the llvm.invariant.start intrinsic.
   llvm::Intrinsic::ID InvStartID = llvm::Intrinsic::invariant_start;
   // Overloaded address space type.
-  llvm::Type *ObjectPtr[1] = {Int8PtrTy};
+  assert(Addr->getType()->isPointerTy() && "Address must be a pointer");
+  llvm::Type *ObjectPtr[1] = {Addr->getType()};
   llvm::Function *InvariantStart = CGM.getIntrinsic(InvStartID, ObjectPtr);
 
   // Emit a call with the size in bytes of the object.
diff --git a/clang/test/CodeGenCXX/init-invariant.cpp 
b/clang/test/CodeGenCXX/init-invariant.cpp
index fdd5753402ccb..974064b70a3c0 100644
--- a/clang/test/CodeGenCXX/init-invariant.cpp
+++ b/clang/test/CodeGenCXX/init-invariant.cpp
@@ -46,6 +46,8 @@ extern const C c = C();
 int f();
 // CHECK: @d ={{.*}} global i32 0
 extern const int d = f();
+// CHECK: @d2 ={{.*}} addrspace(10) global i32 0
+extern const int __attribute__((address_space(10))) d2 = f();
 
 void e() {
   static const A a = A();
@@ -67,6 +69,10 @@ void e() {
 // CHECK: store {{.*}}, ptr @d
 // CHECK: call {{.*}}@llvm.invariant.start.p0(i64 4, ptr @d)
 
+// CHECK: call noundef i32 @_Z1fv(
+// CHECK: store {{.*}}, ptr addrspace(10) @d2
+// CHECK: call {{.*}}@llvm.invariant.start.p10(i64 4, ptr addrspace(10) @d2)
+
 // CHECK-LABEL: define{{.*}} void @_Z1ev(
 // CHECK: call void @_ZN1AC1Ev(ptr noundef {{[^,]*}} @_ZZ1evE1a)
 // CHECK: call {{.*}}@llvm.invariant.start.p0(i64 4, ptr {{.*}}@_ZZ1evE1a)

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


[clang] [clang][CodeGen] Fix EmitInvariantStart for non-zero addrspace (PR #94346)

2024-06-04 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Bruno De Fraine (brunodf-snps)


Changes

The `llvm.invariant.start` intrinsic is already overloaded to work with memory 
objects in any address space. We simply instantiate the intrinsic with the 
appropriate pointer type.

Fixes #94345.

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


2 Files Affected:

- (modified) clang/lib/CodeGen/CGDeclCXX.cpp (+2-1) 
- (modified) clang/test/CodeGenCXX/init-invariant.cpp (+6) 


``diff
diff --git a/clang/lib/CodeGen/CGDeclCXX.cpp b/clang/lib/CodeGen/CGDeclCXX.cpp
index b047279912f6b..a0429435dbe7e 100644
--- a/clang/lib/CodeGen/CGDeclCXX.cpp
+++ b/clang/lib/CodeGen/CGDeclCXX.cpp
@@ -162,7 +162,8 @@ void CodeGenFunction::EmitInvariantStart(llvm::Constant 
*Addr, CharUnits Size) {
   // Grab the llvm.invariant.start intrinsic.
   llvm::Intrinsic::ID InvStartID = llvm::Intrinsic::invariant_start;
   // Overloaded address space type.
-  llvm::Type *ObjectPtr[1] = {Int8PtrTy};
+  assert(Addr->getType()->isPointerTy() && "Address must be a pointer");
+  llvm::Type *ObjectPtr[1] = {Addr->getType()};
   llvm::Function *InvariantStart = CGM.getIntrinsic(InvStartID, ObjectPtr);
 
   // Emit a call with the size in bytes of the object.
diff --git a/clang/test/CodeGenCXX/init-invariant.cpp 
b/clang/test/CodeGenCXX/init-invariant.cpp
index fdd5753402ccb..974064b70a3c0 100644
--- a/clang/test/CodeGenCXX/init-invariant.cpp
+++ b/clang/test/CodeGenCXX/init-invariant.cpp
@@ -46,6 +46,8 @@ extern const C c = C();
 int f();
 // CHECK: @d ={{.*}} global i32 0
 extern const int d = f();
+// CHECK: @d2 ={{.*}} addrspace(10) global i32 0
+extern const int __attribute__((address_space(10))) d2 = f();
 
 void e() {
   static const A a = A();
@@ -67,6 +69,10 @@ void e() {
 // CHECK: store {{.*}}, ptr @d
 // CHECK: call {{.*}}@llvm.invariant.start.p0(i64 4, ptr @d)
 
+// CHECK: call noundef i32 @_Z1fv(
+// CHECK: store {{.*}}, ptr addrspace(10) @d2
+// CHECK: call {{.*}}@llvm.invariant.start.p10(i64 4, ptr addrspace(10) @d2)
+
 // CHECK-LABEL: define{{.*}} void @_Z1ev(
 // CHECK: call void @_ZN1AC1Ev(ptr noundef {{[^,]*}} @_ZZ1evE1a)
 // CHECK: call {{.*}}@llvm.invariant.start.p0(i64 4, ptr {{.*}}@_ZZ1evE1a)

``




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


[clang] Disable constexpr function body checking in more situations (PR #94347)

2024-06-04 Thread Aaron Ballman via cfe-commits

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


[clang] Disable constexpr function body checking in more situations (PR #94347)

2024-06-04 Thread Aaron Ballman via cfe-commits

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


[clang] Disable constexpr function body checking in more situations (PR #94347)

2024-06-04 Thread Aaron Ballman via cfe-commits

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


[clang] Disable constexpr function body checking in more situations (PR #94347)

2024-06-04 Thread Aaron Ballman via cfe-commits

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


[clang] Disable constexpr function body checking in more situations (PR #94347)

2024-06-04 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Aaron Ballman (AaronBallman)


Changes

Before C++23, we would check a constexpr function body to diagnose if the 
function can never be evaluated in a constant expression context. This was 
previously required standards behavior, but C++23 relaxed the restrictions with 
P2448R2. While this checking is useful, it is also quite expensive, especially 
in pathological cases (see #92924 for an example), because it means the 
mere presence of a constexpr function definition will require constant 
evaluation even if the function is not used within the TU.

Clang suppresses diagnostics in system headers by default and system headers 
(like STL implementations) can be full of constexpr function bodies. Now we 
suppress the check for a diagnostic if the function definition is in a system 
header or if the `-Winvalid-constexpr` diagnostic is disabled. This should have 
some mild compile time performance improvements.

Also, the previous implementation would disable the diagnostic in C++23 mode 
entirely. Due to the benefit of the check, this patch now makes it possible to 
enable the diagnostic explicitly in C++23 mode.

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


6 Files Affected:

- (modified) clang/docs/ReleaseNotes.rst (+14) 
- (modified) clang/include/clang/Basic/LangOptions.def (+3) 
- (modified) clang/include/clang/Driver/Options.td (+4) 
- (modified) clang/lib/Frontend/CompilerInvocation.cpp (+6) 
- (modified) clang/lib/Sema/SemaDeclCXX.cpp (+13-4) 
- (added) clang/test/SemaCXX/constexpr-never-constant.cpp (+26) 


``diff
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 32515fbac64f6..6f599bbe11a2f 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -207,6 +207,9 @@ C++23 Feature Support
 - Implemented `P1774R8: Portable assumptions `_.
 
 - Implemented `P2448R2: Relaxing some constexpr restrictions 
`_.
+  Note, the ``-Winvalid-constexpr`` diagnostic is now disabled in C++23 mode,
+  but can be explicitly specified to retain the old diagnostic checking
+  behavior.
 
 - Added a ``__reference_converts_from_temporary`` builtin, completing the 
necessary compiler support for
   `P2255R2: Type trait to determine if a reference binds to a temporary 
`_.
@@ -323,6 +326,17 @@ Non-comprehensive list of changes in this release
 - Builtins ``__builtin_shufflevector()`` and ``__builtin_convertvector()`` may
   now be used within constant expressions.
 
+- When compiling a constexpr function, Clang will check to see whether the
+  function can *never* be used in a constant expression context and issues a
+  diagnostic under the ``-Winvalid-constexpr`` diagostic flag (which defaults
+  to an error). This check can be expensive because the mere presence of a
+  function marked ``constexpr`` will cause us to undergo constant expression
+  evaluation, even if the function is not called within the translation unit
+  being compiled. Due to the expense, Clang no longer checks constexpr function
+  bodies when the function is defined in a system header file or when
+  ``-Winvalid-constexpr`` is not enabled for the function definition, which
+  should result in mild compile-time performance improvements.
+
 New Compiler Flags
 --
 - ``-fsanitize=implicit-bitfield-conversion`` checks implicit truncation and
diff --git a/clang/include/clang/Basic/LangOptions.def 
b/clang/include/clang/Basic/LangOptions.def
index 4061451b2150a..cd0c430850159 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -505,6 +505,9 @@ COMPATIBLE_LANGOPT(IncrementalExtensions, 1, 0, " True if 
we want to process sta
 
 BENIGN_LANGOPT(CheckNew, 1, 0, "Do not assume C++ operator new may not return 
NULL")
 
+BENIGN_LANGOPT(CheckConstexprFunctionBodies, 1, 1,
+   "True if we want to emit a diagnostics for a constexpr function 
"
+   "body if it can never be used in a constant expression.")
 #undef LANGOPT
 #undef COMPATIBLE_LANGOPT
 #undef BENIGN_LANGOPT
diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 57f37c5023110..904547a0a13de 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -961,6 +961,10 @@ def Wdeprecated : Flag<["-"], "Wdeprecated">, 
Group,
   HelpText<"Enable warnings for deprecated constructs and define 
__DEPRECATED">;
 def Wno_deprecated : Flag<["-"], "Wno-deprecated">, Group,
   Visibility<[ClangOption, CC1Option]>;
+def Winvalid_constexpr : Flag<["-"], "Winvalid-constexpr">, Group,
+  Visibility<[ClangOption, CC1Option]>;
+def Wno_invalid_constexpr : Flag<["-"], "Wno-invalid-constexpr">,
+  Group, Visibility<[ClangOption, CC1Option]>;
 def Wl_COMMA : CommaJoined<["-"], "Wl,">, Visibility<[ClangOption, 
FlangOption]>,
   Flags<[LinkerIn

[clang] [Driver] Make the FileCheck less strict for some tests. (PR #94349)

2024-06-04 Thread Haojian Wu via cfe-commits

https://github.com/hokein created 
https://github.com/llvm/llvm-project/pull/94349

We see some tests are failing internally after 
12949c952c4fbad776a860c003ccf176973278a0.

In CAS systems, we might not see the exact binary name (clang), this patch 
removes the binary name in the FileCheck content to make these tests work on 
CAS.

>From a5e8cfdc213a889e01080edb1cbdabe279c3449a Mon Sep 17 00:00:00 2001
From: Haojian Wu 
Date: Tue, 4 Jun 2024 14:51:10 +0200
Subject: [PATCH] [Driver] Make the FileCheck less strict for some tests.

We see some tests are failing internally after 
12949c952c4fbad776a860c003ccf176973278a0.

In some CAS systems, we might not see the exact binary name (clang),
this patch removes the binary name in the FileCheck content to make
these tests work on CAS.
---
 clang/test/Driver/mips-mti-linux.c |  4 ++--
 clang/test/Driver/openmp-offload-gpu.c |  6 +++---
 clang/test/Driver/openmp-offload.c | 10 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/clang/test/Driver/mips-mti-linux.c 
b/clang/test/Driver/mips-mti-linux.c
index d10eb837b8a6e..0be25a284b777 100644
--- a/clang/test/Driver/mips-mti-linux.c
+++ b/clang/test/Driver/mips-mti-linux.c
@@ -12,7 +12,7 @@
 // RUN: --sysroot=%S/Inputs/mips_mti_linux/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-BE-HF-32R2 %s
 //
-// CHECK-BE-HF-32R2: "{{[^"]*}}clang{{[^"]*}}" {{.*}} "-triple" 
"mips-mti-linux"
+// CHECK-BE-HF-32R2: "-triple" "mips-mti-linux"
 // CHECK-BE-HF-32R2-SAME: "-target-cpu" "mips32r2"
 // CHECK-BE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
 // CHECK-BE-HF-32R2: "{{[^"]*}}ld.lld{{[^"]*}}"
@@ -31,7 +31,7 @@
 // RUN: --sysroot=%S/Inputs/mips_mti_linux/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-LE-HF-32R2 %s
 //
-// CHECK-LE-HF-32R2: "{{[^"]*}}clang{{[^"]*}}" {{.*}} "-triple" 
"mipsel-mti-linux"
+// CHECK-LE-HF-32R2: "-triple" "mipsel-mti-linux"
 // CHECK-LE-HF-32R2-SAME: "-target-cpu" "mips32r2"
 // CHECK-LE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
 // CHECK-LE-HF-32R2: "{{[^"]*}}ld.lld{{[^"]*}}"
diff --git a/clang/test/Driver/openmp-offload-gpu.c 
b/clang/test/Driver/openmp-offload-gpu.c
index 0b98aaf6ba53c..a9ddf65177ee5 100644
--- a/clang/test/Driver/openmp-offload-gpu.c
+++ b/clang/test/Driver/openmp-offload-gpu.c
@@ -89,9 +89,9 @@
 // RUN:   -fopenmp-relocatable-target -save-temps \
 // RUN:   %s 2>&1 | FileCheck -check-prefix=CHK-ENV-BCLIB %s
 
-// CHK-BCLIB: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-test.bc
-// CHK-BCLIB-DIR: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget{{/|}}libomptarget-nvptx-sm_52.bc
-// CHK-ENV-BCLIB: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}subdir{{/|}}libomptarget-nvptx-sm_52.bc
+// CHK-BCLIB: 
triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-test.bc
+// CHK-BCLIB-DIR: 
triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget{{/|}}libomptarget-nvptx-sm_52.bc
+// CHK-ENV-BCLIB: 
triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}subdir{{/|}}libomptarget-nvptx-sm_52.bc
 // CHK-BCLIB-NOT: {{error:|warning:}}
 
 /// ###
diff --git a/clang/test/Driver/openmp-offload.c 
b/clang/test/Driver/openmp-offload.c
index 38065d9398f45..9e7f523895ba3 100644
--- a/clang/test/Driver/openmp-offload.c
+++ b/clang/test/Driver/openmp-offload.c
@@ -38,7 +38,7 @@
 // RUN:   %clang -### -fopenmp=libomp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu 
-Xopenmp-target=powerpc64le-ibm-linux-gnu -mcpu=pwr7 %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-FOPENMP-EQ-TARGET %s
 
-// CHK-FOPENMP-EQ-TARGET: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
+// CHK-FOPENMP-EQ-TARGET: "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
 
 /// ###
 
@@ -46,7 +46,7 @@
 // RUN:   %clang -### -fopenmp=libomp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target -mcpu=pwr7 %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-FOPENMP-TARGET %s
 
-// CHK-FOPENMP-TARGET: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
+// CHK-FOPENMP-TARGET: "-target-cpu" "pwr7" {{.*}}"-fopenmp-is-target-device"
 
 /// ##
 
@@ -54,7 +54,7 @@
 // RUN:%clang -### -fopenmp=libomp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu --target=powerpc64le-ibm-linux-gnu 
-mcpu=pwr7 %s 2>&1 \
 // RUN:| FileCheck -check-prefix=CHK-FOPENMP-MCPU-TO-SAME-TRIPLE %s
 
-// CHK-FOPENMP-MCPU-TO-SAME-TRIPLE: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
+// CHK-FOPENMP-MCPU-TO-SAME-TRIPLE: "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
 
 /// 

[clang] [Driver] Make the FileCheck less strict for some tests. (PR #94349)

2024-06-04 Thread via cfe-commits

llvmbot wrote:



@llvm/pr-subscribers-clang

@llvm/pr-subscribers-clang-driver

Author: Haojian Wu (hokein)


Changes

We see some tests are failing internally after 
12949c952c4fbad776a860c003ccf176973278a0.

In CAS systems, we might not see the exact binary name (clang), this patch 
removes the binary name in the FileCheck content to make these tests work on 
CAS.

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


3 Files Affected:

- (modified) clang/test/Driver/mips-mti-linux.c (+2-2) 
- (modified) clang/test/Driver/openmp-offload-gpu.c (+3-3) 
- (modified) clang/test/Driver/openmp-offload.c (+5-5) 


``diff
diff --git a/clang/test/Driver/mips-mti-linux.c 
b/clang/test/Driver/mips-mti-linux.c
index d10eb837b8a6e..0be25a284b777 100644
--- a/clang/test/Driver/mips-mti-linux.c
+++ b/clang/test/Driver/mips-mti-linux.c
@@ -12,7 +12,7 @@
 // RUN: --sysroot=%S/Inputs/mips_mti_linux/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-BE-HF-32R2 %s
 //
-// CHECK-BE-HF-32R2: "{{[^"]*}}clang{{[^"]*}}" {{.*}} "-triple" 
"mips-mti-linux"
+// CHECK-BE-HF-32R2: "-triple" "mips-mti-linux"
 // CHECK-BE-HF-32R2-SAME: "-target-cpu" "mips32r2"
 // CHECK-BE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
 // CHECK-BE-HF-32R2: "{{[^"]*}}ld.lld{{[^"]*}}"
@@ -31,7 +31,7 @@
 // RUN: --sysroot=%S/Inputs/mips_mti_linux/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-LE-HF-32R2 %s
 //
-// CHECK-LE-HF-32R2: "{{[^"]*}}clang{{[^"]*}}" {{.*}} "-triple" 
"mipsel-mti-linux"
+// CHECK-LE-HF-32R2: "-triple" "mipsel-mti-linux"
 // CHECK-LE-HF-32R2-SAME: "-target-cpu" "mips32r2"
 // CHECK-LE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
 // CHECK-LE-HF-32R2: "{{[^"]*}}ld.lld{{[^"]*}}"
diff --git a/clang/test/Driver/openmp-offload-gpu.c 
b/clang/test/Driver/openmp-offload-gpu.c
index 0b98aaf6ba53c..a9ddf65177ee5 100644
--- a/clang/test/Driver/openmp-offload-gpu.c
+++ b/clang/test/Driver/openmp-offload-gpu.c
@@ -89,9 +89,9 @@
 // RUN:   -fopenmp-relocatable-target -save-temps \
 // RUN:   %s 2>&1 | FileCheck -check-prefix=CHK-ENV-BCLIB %s
 
-// CHK-BCLIB: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-test.bc
-// CHK-BCLIB-DIR: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget{{/|}}libomptarget-nvptx-sm_52.bc
-// CHK-ENV-BCLIB: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}subdir{{/|}}libomptarget-nvptx-sm_52.bc
+// CHK-BCLIB: 
triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-test.bc
+// CHK-BCLIB-DIR: 
triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget{{/|}}libomptarget-nvptx-sm_52.bc
+// CHK-ENV-BCLIB: 
triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}subdir{{/|}}libomptarget-nvptx-sm_52.bc
 // CHK-BCLIB-NOT: {{error:|warning:}}
 
 /// ###
diff --git a/clang/test/Driver/openmp-offload.c 
b/clang/test/Driver/openmp-offload.c
index 38065d9398f45..9e7f523895ba3 100644
--- a/clang/test/Driver/openmp-offload.c
+++ b/clang/test/Driver/openmp-offload.c
@@ -38,7 +38,7 @@
 // RUN:   %clang -### -fopenmp=libomp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu 
-Xopenmp-target=powerpc64le-ibm-linux-gnu -mcpu=pwr7 %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-FOPENMP-EQ-TARGET %s
 
-// CHK-FOPENMP-EQ-TARGET: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
+// CHK-FOPENMP-EQ-TARGET: "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
 
 /// ###
 
@@ -46,7 +46,7 @@
 // RUN:   %clang -### -fopenmp=libomp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target -mcpu=pwr7 %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-FOPENMP-TARGET %s
 
-// CHK-FOPENMP-TARGET: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
+// CHK-FOPENMP-TARGET: "-target-cpu" "pwr7" {{.*}}"-fopenmp-is-target-device"
 
 /// ##
 
@@ -54,7 +54,7 @@
 // RUN:%clang -### -fopenmp=libomp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu --target=powerpc64le-ibm-linux-gnu 
-mcpu=pwr7 %s 2>&1 \
 // RUN:| FileCheck -check-prefix=CHK-FOPENMP-MCPU-TO-SAME-TRIPLE %s
 
-// CHK-FOPENMP-MCPU-TO-SAME-TRIPLE: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
+// CHK-FOPENMP-MCPU-TO-SAME-TRIPLE: "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
 
 /// ##
 
@@ -62,7 +62,7 @@
 // RUN:not %clang -### -fopenmp=libomp 
-fopenmp-targets=nvptx64-nvidia-cuda --target=powerpc64le-ibm-linux-gnu 
-march=pwr7 %s 2>&1 \
 // RUN:| FileCheck -check-prefix=CHK-FOPENMP-MARCH-TO-GPU %s
 
-// CHK-FOPENMP-MARCH-TO-GPU-NOT: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-targe

[clang] [llvm] [AArch64] Decouple feature dependency expansion. (PR #94279)

2024-06-04 Thread Alexandros Lamprineas via cfe-commits


@@ -69,8 +69,8 @@ void undefined(uint32x2_t v2i32, uint32x4_t v4i32, uint16x8_t 
v8i16, uint8x16_t
   vrnd_f16(v4f16); // expected-error {{always_inline function 'vrnd_f16' 
requires target feature 'fullfp16'}}
   vmaxnm_f16(v4f16, v4f16); // expected-error {{always_inline function 
'vmaxnm_f16' requires target feature 'fullfp16'}}
   vrndi_f16(v4f16); // expected-error {{always_inline function 'vrndi_f16' 
requires target feature 'fullfp16'}}
-  // fp16fml
-  vfmlal_low_f16(v2f32, v4f16, v4f16); // expected-error {{always_inline 
function 'vfmlal_low_f16' requires target feature 'fp16fml'}}
+  // fp16fml depends on fp-armv8
+  vfmlal_low_f16(v2f32, v4f16, v4f16); // expected-error {{always_inline 
function 'vfmlal_low_f16' requires target feature 'fp-armv8'}}

labrinea wrote:

In a future patch it is perhaps worth filtering all these diagnostics with 
targetFeatureToExtension() since I don't see the point in reporting an internal 
feature name to the user. We should be diagnosing the corresponding Extension.

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


[clang] [Driver] Make the FileCheck less strict for some tests. (PR #94349)

2024-06-04 Thread Haojian Wu via cfe-commits

https://github.com/hokein updated 
https://github.com/llvm/llvm-project/pull/94349

>From fa0880d477439e4af3f0b1b057dc1c66a2ccbc1e Mon Sep 17 00:00:00 2001
From: Haojian Wu 
Date: Tue, 4 Jun 2024 14:51:10 +0200
Subject: [PATCH] [Driver] Make the FileCheck less strict for some tests.

We see some tests are failing internally after 
12949c952c4fbad776a860c003ccf176973278a0.

In some CAS systems, we might not see the exact binary name (clang),
this patch removes the binary name in the FileCheck content to make
these tests work on CAS.
---
 clang/test/Driver/mips-mti-linux.c |  4 ++--
 clang/test/Driver/openmp-offload-gpu.c |  6 +++---
 clang/test/Driver/openmp-offload.c | 10 +-
 clang/test/Driver/ve-toolchain.c   |  2 +-
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/clang/test/Driver/mips-mti-linux.c 
b/clang/test/Driver/mips-mti-linux.c
index d10eb837b8a6e..0be25a284b777 100644
--- a/clang/test/Driver/mips-mti-linux.c
+++ b/clang/test/Driver/mips-mti-linux.c
@@ -12,7 +12,7 @@
 // RUN: --sysroot=%S/Inputs/mips_mti_linux/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-BE-HF-32R2 %s
 //
-// CHECK-BE-HF-32R2: "{{[^"]*}}clang{{[^"]*}}" {{.*}} "-triple" 
"mips-mti-linux"
+// CHECK-BE-HF-32R2: "-triple" "mips-mti-linux"
 // CHECK-BE-HF-32R2-SAME: "-target-cpu" "mips32r2"
 // CHECK-BE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
 // CHECK-BE-HF-32R2: "{{[^"]*}}ld.lld{{[^"]*}}"
@@ -31,7 +31,7 @@
 // RUN: --sysroot=%S/Inputs/mips_mti_linux/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-LE-HF-32R2 %s
 //
-// CHECK-LE-HF-32R2: "{{[^"]*}}clang{{[^"]*}}" {{.*}} "-triple" 
"mipsel-mti-linux"
+// CHECK-LE-HF-32R2: "-triple" "mipsel-mti-linux"
 // CHECK-LE-HF-32R2-SAME: "-target-cpu" "mips32r2"
 // CHECK-LE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
 // CHECK-LE-HF-32R2: "{{[^"]*}}ld.lld{{[^"]*}}"
diff --git a/clang/test/Driver/openmp-offload-gpu.c 
b/clang/test/Driver/openmp-offload-gpu.c
index 0b98aaf6ba53c..a9ddf65177ee5 100644
--- a/clang/test/Driver/openmp-offload-gpu.c
+++ b/clang/test/Driver/openmp-offload-gpu.c
@@ -89,9 +89,9 @@
 // RUN:   -fopenmp-relocatable-target -save-temps \
 // RUN:   %s 2>&1 | FileCheck -check-prefix=CHK-ENV-BCLIB %s
 
-// CHK-BCLIB: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-test.bc
-// CHK-BCLIB-DIR: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget{{/|}}libomptarget-nvptx-sm_52.bc
-// CHK-ENV-BCLIB: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}subdir{{/|}}libomptarget-nvptx-sm_52.bc
+// CHK-BCLIB: 
triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-test.bc
+// CHK-BCLIB-DIR: 
triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget{{/|}}libomptarget-nvptx-sm_52.bc
+// CHK-ENV-BCLIB: 
triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}subdir{{/|}}libomptarget-nvptx-sm_52.bc
 // CHK-BCLIB-NOT: {{error:|warning:}}
 
 /// ###
diff --git a/clang/test/Driver/openmp-offload.c 
b/clang/test/Driver/openmp-offload.c
index 38065d9398f45..9e7f523895ba3 100644
--- a/clang/test/Driver/openmp-offload.c
+++ b/clang/test/Driver/openmp-offload.c
@@ -38,7 +38,7 @@
 // RUN:   %clang -### -fopenmp=libomp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu 
-Xopenmp-target=powerpc64le-ibm-linux-gnu -mcpu=pwr7 %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-FOPENMP-EQ-TARGET %s
 
-// CHK-FOPENMP-EQ-TARGET: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
+// CHK-FOPENMP-EQ-TARGET: "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
 
 /// ###
 
@@ -46,7 +46,7 @@
 // RUN:   %clang -### -fopenmp=libomp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target -mcpu=pwr7 %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-FOPENMP-TARGET %s
 
-// CHK-FOPENMP-TARGET: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
+// CHK-FOPENMP-TARGET: "-target-cpu" "pwr7" {{.*}}"-fopenmp-is-target-device"
 
 /// ##
 
@@ -54,7 +54,7 @@
 // RUN:%clang -### -fopenmp=libomp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu --target=powerpc64le-ibm-linux-gnu 
-mcpu=pwr7 %s 2>&1 \
 // RUN:| FileCheck -check-prefix=CHK-FOPENMP-MCPU-TO-SAME-TRIPLE %s
 
-// CHK-FOPENMP-MCPU-TO-SAME-TRIPLE: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
+// CHK-FOPENMP-MCPU-TO-SAME-TRIPLE: "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-target-device"
 
 /// ##
 
@@ -62,7 +62,7 @@
 // RUN:not %clang -### -fopenmp=libomp 
-fopenmp-targets=nvptx64-nvidia-cuda --target=powerpc64le-ibm-linux-gnu 
-march=pwr7 %s 2>&1 \
 // RUN:

[clang] [AArch64] Add validation for Global Register Variable. (PR #94271)

2024-06-04 Thread KAWASHIMA Takahiro via cfe-commits

kawashima-fj wrote:

@DanielKristofKiss Thanks for the fix. At first glance, LGTM. I'll take a 
closer look in a few days.
I'm not so familiar with the code. If someone else can review, I'll leave it to 
them.

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


[clang] [Clang] Static and explicit object member functions with the same parameter-type-lists (PR #93430)

2024-06-04 Thread Erich Keane via cfe-commits

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


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


  1   2   3   4   >