[clang] [clang][Interp] Implement IntegralAP::{div, rem} (PR #72614)

[Timm Baeder via cfe-commits]

@@ -44,6 +44,24 @@ static_assert(MulA * MulB == 50, ""); // ref-error {{not an 
integral constant ex
 static_assert(MulA * 5 == 25, "");
 static_assert(-1 * MulB == -7, "");
 
+
+constexpr _BitInt(4) DivA = 2;
+constexpr _BitInt(2) DivB = 1;
+static_assert(DivA / DivB == 2, "");
+
+constexpr _BitInt(4) DivC = DivA / 0; // ref-error {{must be initialized by a 
constant expression}} \

tbaederr wrote:

Did you really mean `int`? Or `_BitInt`?

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

[clang] [clang] Add per-global code model attribute (PR #72078)

[via cfe-commits]

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

[clang] [clang] Add per-global code model attribute (PR #72078)

[via cfe-commits]

@@ -4841,6 +4841,19 @@ CodeGenModule::GetOrCreateLLVMGlobal(StringRef 
MangledName, llvm::Type *Ty,
 isExternallyVisible(D->getLinkageAndVisibility().getLinkage()))
   GV->setSection(".cp.rodata");
 
+// Handle code model attribute
+if (D->hasAttr()) {
+  if (const CodeModelAttr *CMA = D->getAttr()) {

heiher wrote:

Done

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

[clang] [clang] Add per-global code model attribute (PR #72078)

[via cfe-commits]

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

[clang] [clang] Add per-global code model attribute (PR #72078)

[via cfe-commits]

@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 -emit-llvm -triple loongarch64 %s -o - | FileCheck %s
+
+// CHECK: @_ZL2v1 ={{.*}} global i32 0, code_model "small"
+static int v1 __attribute__((model("normal")));
+
+void use1() {
+  v1 = 1;
+}
+
+// CHECK: @v2 ={{.*}} global i32 0, code_model "medium"
+int v2 __attribute__((model("medium")));
+
+// CHECK: @v3 ={{.*}} global float 0.00e+00, code_model "large"
+float v3 __attribute__((model("extreme")));
+
+// CHECK: @_ZL2v4IiE ={{.*}} global i32 0, code_model "medium"
+template 
+static T v4 __attribute__((model("medium")));
+
+void use2() {
+  v4 = 1;
+}
+
+// CHECK: @v5 ={{.*}} global i32 0, code_model "large"
+thread_local int v5 __attribute__((model("extreme")));

heiher wrote:

Clang's GlobalVar covers TLSVar, but GCC not. This is why GCC reports an error 
for that and Clang not. The code model is not useful for thread-local 
variables, so I added non-TLS global variable to handle it.

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

[clang] [clang] Add per-global code model attribute (PR #72078)

[via cfe-commits]

https://github.com/heiher updated 
https://github.com/llvm/llvm-project/pull/72078

>From e3863873ab817dacf8680763bb42d91f005fe5ea Mon Sep 17 00:00:00 2001
From: WANG Rui 
Date: Fri, 10 Nov 2023 21:07:48 -0600
Subject: [PATCH 1/6] [clang] Add per-global code model attribute

This patch adds a per-global code model attribute, which can override
the target's code model to access global variables.

Currently, the code model attribute is only supported on LoongArch.
This patch also maps GCC's code model names to LLVM's, which allows
for better compatibility between the two compilers.

Suggested-by: Arthur Eubanks 
Signed-off-by: WANG Rui 
Link: 
https://discourse.llvm.org/t/how-to-best-implement-code-model-overriding-for-certain-values/71816
Link: https://discourse.llvm.org/t/rfc-add-per-global-code-model-attribute/74944
---
 clang/include/clang/Basic/Attr.td |  8 +
 clang/include/clang/Basic/AttrDocs.td |  9 ++
 .../clang/Basic/DiagnosticSemaKinds.td|  2 ++
 clang/lib/CodeGen/CodeGenModule.cpp   | 13 
 clang/lib/Sema/SemaDeclAttr.cpp   | 30 +++
 clang/test/CodeGen/LoongArch/attributes.c | 10 +++
 ...a-attribute-supported-attributes-list.test |  1 +
 clang/test/Sema/loongarch-attr-model.c| 13 
 8 files changed, 86 insertions(+)
 create mode 100644 clang/test/CodeGen/LoongArch/attributes.c
 create mode 100644 clang/test/Sema/loongarch-attr-model.c

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 1800f584c7e108..d5b5717f3d77cb 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2718,6 +2718,14 @@ def PragmaClangTextSection : InheritableAttr {
   let Documentation = [InternalOnly];
 }
 
+def CodeModel : InheritableAttr {
+  let Spellings = [GCC<"model">];
+  let Args = [StringArgument<"Model">];
+  let Subjects =
+  SubjectList<[ GlobalVar ], ErrorDiag>;
+  let Documentation = [CodeModelDocs];
+}
+
 def Sentinel : InheritableAttr {
   let Spellings = [GCC<"sentinel">];
   let Args = [DefaultIntArgument<"Sentinel", 0>,
diff --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index b45ec6bbb8d37e..1d37c2da6bec05 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -57,6 +57,15 @@ global variable or function should be in after translation.
   let Heading = "section, __declspec(allocate)";
 }
 
+def CodeModelDocs : Documentation {
+  let Category = DocCatVariable;
+  let Content = [{
+The ``model`` attribute allows you to specify a specific code model a
+global variable should be in after translation.
+  }];
+  let Heading = "model";
+}
+
 def UsedDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 6dfb2d7195203a..d438fdde9ac7eb 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3408,6 +3408,8 @@ def warn_objc_redundant_literal_use : Warning<
 def err_attr_tlsmodel_arg : Error<"tls_model must be \"global-dynamic\", "
   "\"local-dynamic\", \"initial-exec\" or \"local-exec\"">;
 
+def err_attr_codemodel_arg : Error<"code_model '%0' is not yet supported on 
this target">;
+
 def err_aix_attr_unsupported_tls_model : Error<"TLS model '%0' is not yet 
supported on AIX">;
 
 def err_tls_var_aligned_over_maximum : Error<
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index dea58a7ff4146a..1f49721e79ddc4 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -4841,6 +4841,19 @@ CodeGenModule::GetOrCreateLLVMGlobal(StringRef 
MangledName, llvm::Type *Ty,
 isExternallyVisible(D->getLinkageAndVisibility().getLinkage()))
   GV->setSection(".cp.rodata");
 
+// Handle code model attribute
+if (D->hasAttr()) {
+  if (const CodeModelAttr *CMA = D->getAttr()) {
+auto CM = llvm::StringSwitch(CMA->getModel())
+  .Case("tiny", llvm::CodeModel::Tiny)
+  .Case("kernel", llvm::CodeModel::Kernel)
+  .Case("medium", llvm::CodeModel::Medium)
+  .Case("large", llvm::CodeModel::Large)
+  .Default(llvm::CodeModel::Small);
+GV->setCodeModel(CM);
+  }
+}
+
 // Check if we a have a const declaration with an initializer, we may be
 // able to emit it as available_externally to expose it's value to the
 // optimizer.
diff --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index 87c78d742d0ff4..64aa242dbb04f8 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -3369,6 +3369,33 @@ static void handleSectionAttr(Sema , Decl *D, const 
ParsedAttr ) {
   }
 }
 
+static void 

[clang] [clang][Interp] Reject static lambdas with captures (PR #74718)

[Ben Jackson via cfe-commits]

@@ -61,6 +61,11 @@ ByteCodeEmitter::compileFunc(const FunctionDecl *FuncDecl) {
   MD->getParent()->getCaptureFields(LC, LTC);
 
   for (auto Cap : LC) {
+// Static lambdas cannot have any captures. If this one does,
+// it has already been diagnosed and we can only ignore it.
+if (MD->isStatic())

puremourning wrote:

Not sure we need to even enter this loop. 

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

[clang] [clang][Interp] Reject static lambdas with captures (PR #74718)

[Ben Jackson via cfe-commits]

https://github.com/puremourning commented:

Lgtm 

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

[clang] [clang][Interp] Reject static lambdas with captures (PR #74718)

[Ben Jackson via cfe-commits]

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

[clang] [clang][wasm] Resolve assertion errors caused by converting ComplexTy… (PR #70496)

[via cfe-commits]

knightXun wrote:

cc @Endilll @cor3ntin 

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

[clang] [llvm] [Sema] Implement support for -Wformat-signedness (PR #74440)

[Karl-Johan Karlsson via cfe-commits]

https://github.com/karka228 updated 
https://github.com/llvm/llvm-project/pull/74440

>From a80bf9d03f19d48c0aca4af7758dc49516da8825 Mon Sep 17 00:00:00 2001
From: Karl-Johan Karlsson 
Date: Tue, 5 Dec 2023 10:03:00 +0100
Subject: [PATCH 1/6] [Sema] Implement support for -Wformat-signedness

In gcc there exist a modifier option -Wformat-signedness that turns on
additional signedness warnings in the already existing -Wformat warning.

This patch implements that support in clang.
---
 clang/include/clang/AST/FormatString.h|   2 +
 .../include/clang/Basic/DiagnosticOptions.def |   1 +
 clang/include/clang/Driver/Options.td |   3 +
 clang/lib/AST/FormatString.cpp|  29 +++--
 clang/lib/Driver/ToolChains/Clang.cpp |   2 +
 clang/lib/Sema/SemaChecking.cpp   |  26 -
 format-strings-signedness.c   | 107 ++
 7 files changed, 158 insertions(+), 12 deletions(-)
 create mode 100644 format-strings-signedness.c

diff --git a/clang/include/clang/AST/FormatString.h 
b/clang/include/clang/AST/FormatString.h
index 5c4ad9baaef60..c267a32be4d6f 100644
--- a/clang/include/clang/AST/FormatString.h
+++ b/clang/include/clang/AST/FormatString.h
@@ -264,6 +264,8 @@ class ArgType {
 /// The conversion specifier and the argument type are compatible. For
 /// instance, "%d" and int.
 Match = 1,
+/// The conversion specifier and the argument type have different sign
+MatchSignedness,
 /// The conversion specifier and the argument type are compatible because 
of
 /// default argument promotions. For instance, "%hhd" and int.
 MatchPromotion,
diff --git a/clang/include/clang/Basic/DiagnosticOptions.def 
b/clang/include/clang/Basic/DiagnosticOptions.def
index 6d0c1b14acc12..a9562e7d8dcb0 100644
--- a/clang/include/clang/Basic/DiagnosticOptions.def
+++ b/clang/include/clang/Basic/DiagnosticOptions.def
@@ -44,6 +44,7 @@ DIAGOPT(Name, Bits, Default)
 #endif
 
 SEMANTIC_DIAGOPT(IgnoreWarnings, 1, 0)   /// -w
+DIAGOPT(FormatSignedness, 1, 0) /// -Wformat-signedness
 DIAGOPT(NoRewriteMacros, 1, 0)  /// -Wno-rewrite-macros
 DIAGOPT(Pedantic, 1, 0) /// -pedantic
 DIAGOPT(PedanticErrors, 1, 0)   /// -pedantic-errors
diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 1d04e4f6e7e6d..04fdf9a7eb92d 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -918,6 +918,9 @@ 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 Wformat_signedness : Flag<["-"], "Wformat-signedness">,
+  Flags<[HelpHidden]>, Visibility<[ClangOption, CC1Option]>,
+  MarshallingInfoFlag>;
 def Wl_COMMA : CommaJoined<["-"], "Wl,">, Visibility<[ClangOption, 
FlangOption]>,
   Flags<[LinkerInput, RenderAsInput]>,
   HelpText<"Pass the comma separated arguments in  to the linker">,
diff --git a/clang/lib/AST/FormatString.cpp b/clang/lib/AST/FormatString.cpp
index e0c9e18cfe3a2..670cde017d3ac 100644
--- a/clang/lib/AST/FormatString.cpp
+++ b/clang/lib/AST/FormatString.cpp
@@ -409,7 +409,7 @@ ArgType::matchesType(ASTContext , QualType argTy) const {
 return Match;
   if (const auto *BT = argTy->getAs()) {
 // Check if the only difference between them is signed vs unsigned
-// if true, we consider they are compatible.
+// if true, return match signedness.
 switch (BT->getKind()) {
   default:
 break;
@@ -419,44 +419,53 @@ ArgType::matchesType(ASTContext , QualType argTy) const 
{
 [[fallthrough]];
   case BuiltinType::Char_S:
   case BuiltinType::SChar:
+if (T == C.UnsignedShortTy || T == C.ShortTy)
+  return NoMatchTypeConfusion;
+if (T == C.UnsignedCharTy)
+  return MatchSignedness;
+if (T == C.SignedCharTy)
+  return Match;
+break;
   case BuiltinType::Char_U:
   case BuiltinType::UChar:
 if (T == C.UnsignedShortTy || T == C.ShortTy)
   return NoMatchTypeConfusion;
-if (T == C.UnsignedCharTy || T == C.SignedCharTy)
+if (T == C.UnsignedCharTy)
   return Match;
+if (T == C.SignedCharTy)
+  return MatchSignedness;
 break;
   case BuiltinType::Short:
 if (T == C.UnsignedShortTy)
-  return Match;
+  return MatchSignedness;
 break;
   case BuiltinType::UShort:
 if (T == C.ShortTy)
-  return Match;
+  return MatchSignedness;
 break;
   case BuiltinType::Int:
 if (T == C.UnsignedIntTy)
-  return Match;
+  return MatchSignedness;
 break;
  

[libcxx] [clang] [clang-tools-extra] [compiler-rt] [libc] [llvm] [flang] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

[Yeoul Na via cfe-commits]

@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const 
ArraySubscriptExpr *E,
   ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
 else
   ArrayLV = EmitLValue(Array);
+
 auto *Idx = EmitIdxAfterBase(/*Promote*/true);
 
+if (SanOpts.has(SanitizerKind::ArrayBounds)) {

rapidsna wrote:

But it may generate a miscompute if the base has a side effect. Have you 
checked what happens if the base has a side effect, e.g., `foo()->arr[2];`?

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

[clang] [clang][Interp] Diagnose reads from non-const global variables (PR #71919)

[Timm Baeder via cfe-commits]

Timm =?utf-8?q?Bäder?= 
Message-ID:
In-Reply-To: 



@@ -1005,12 +1008,23 @@ bool SetThisField(InterpState , CodePtr OpPC, 
uint32_t I) {
 template ::T>
 bool GetGlobal(InterpState , CodePtr OpPC, uint32_t I) {
   const Block *B = S.P.getGlobal(I);
+
+  if (!CheckConstant(S, OpPC, B->getDescriptor()))
+return false;
   if (B->isExtern())
 return false;
   S.Stk.push(B->deref());
   return true;
 }
 
+/// Same as GetGlobal, but without the checks.
+template ::T>
+bool GetGlobalUnchecked(InterpState , CodePtr OpPC, uint32_t I) {
+  auto *B = S.P.getGlobal(I);
+  S.Stk.push(B->deref());
+  return true;
+}
+

tbaederr wrote:

It's a bit involved because `GetGlobal` can't just call `GetGlobalUnchecked` 
since they would both have to call `S.P.getGlobal(I)`... I mean, that's not a 
problem per se but a little ugly and slower than it needs to be. So we'd have 
to use a third function that just does `S.Stk.push(B->deref()); return 
true;`.

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

[clang] [Preprocessor] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 for AArch64 (PR #74954)

[Fangrui Song via cfe-commits]

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

[clang] 1c830b7 - [Preprocessor] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 for AArch64 (#74954)

[via cfe-commits]

Author: Fangrui Song
Date: 2023-12-11T23:09:14-08:00
New Revision: 1c830b787c0d8ccc863d23fa507182dc7685fcc2

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

LOG: [Preprocessor] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 for AArch64 
(#74954)

GCC sets `#define HAVE_atomic_compare_and_swapti 1` and therefore
defines `__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16`.

Clang compiles the 16-byte legacy `__sync_bool_compare_and_swap` and new
`__atomic_compare_exchange` compile to LDXP/STXP or (with LSE)
CASP{,A,L,AL}.

Link: https://github.com/llvm/llvm-project/issues/71883

Added: 


Modified: 
clang/lib/Basic/Targets/AArch64.cpp
clang/test/Preprocessor/init-aarch64.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/AArch64.cpp 
b/clang/lib/Basic/Targets/AArch64.cpp
index c31f2e0bee5439..e3e08b571667cc 100644
--- a/clang/lib/Basic/Targets/AArch64.cpp
+++ b/clang/lib/Basic/Targets/AArch64.cpp
@@ -574,11 +574,12 @@ void AArch64TargetInfo::getTargetDefines(const 
LangOptions ,
   else if (*ArchInfo == llvm::AArch64::ARMV9_5A)
 getTargetDefinesARMV95A(Opts, Builder);
 
-  // All of the __sync_(bool|val)_compare_and_swap_(1|2|4|8) builtins work.
+  // All of the __sync_(bool|val)_compare_and_swap_(1|2|4|8|16) builtins work.
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2");
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4");
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+  Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16");
 
   // Allow detection of fast FMA support.
   Builder.defineMacro("__FP_FAST_FMA", "1");

diff  --git a/clang/test/Preprocessor/init-aarch64.c 
b/clang/test/Preprocessor/init-aarch64.c
index b0333b3f023890..94c091a69e8444 100644
--- a/clang/test/Preprocessor/init-aarch64.c
+++ b/clang/test/Preprocessor/init-aarch64.c
@@ -118,6 +118,7 @@
 // AARCH64-NEXT: #define __FP_FAST_FMAF 1
 // AARCH64-NEXT: #define __GCC_ASM_FLAG_OUTPUTS__ 1
 // AARCH64-NEXT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+// AARCH64-NEXT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 1
 // AARCH64-NEXT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
 // AARCH64-NEXT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
 // AARCH64-NEXT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1



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

[clang] [clang][Interp] Reject static lambdas with captures (PR #74718)

[Timm Baeder via cfe-commits]

https://github.com/tbaederr updated 
https://github.com/llvm/llvm-project/pull/74718

>From cb0cb30f9caea7d73a2bb09068f7187ac3b94408 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Timm=20B=C3=A4der?= 
Date: Thu, 7 Dec 2023 14:19:52 +0100
Subject: [PATCH] [clang][Interp] Reject static lambdas with captures

A version of #74661 for the new interpreter. It didn't crash before,
but we did emit a few non-sensical diagnostics.
---
 clang/lib/AST/Interp/ByteCodeEmitter.cpp |  5 +
 clang/test/AST/Interp/cxx23.cpp  | 27 +---
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/clang/lib/AST/Interp/ByteCodeEmitter.cpp 
b/clang/lib/AST/Interp/ByteCodeEmitter.cpp
index 89b7708c0c2a1..045263447cbc9 100644
--- a/clang/lib/AST/Interp/ByteCodeEmitter.cpp
+++ b/clang/lib/AST/Interp/ByteCodeEmitter.cpp
@@ -61,6 +61,11 @@ ByteCodeEmitter::compileFunc(const FunctionDecl *FuncDecl) {
   MD->getParent()->getCaptureFields(LC, LTC);
 
   for (auto Cap : LC) {
+// Static lambdas cannot have any captures. If this one does,
+// it has already been diagnosed and we can only ignore it.
+if (MD->isStatic())
+  return nullptr;
+
 unsigned Offset = R->getField(Cap.second)->Offset;
 this->LambdaCaptures[Cap.first] = {
 Offset, Cap.second->getType()->isReferenceType()};
diff --git a/clang/test/AST/Interp/cxx23.cpp b/clang/test/AST/Interp/cxx23.cpp
index e284a66626fb3..bd1cf186d519c 100644
--- a/clang/test/AST/Interp/cxx23.cpp
+++ b/clang/test/AST/Interp/cxx23.cpp
@@ -4,9 +4,6 @@
 // RUN: %clang_cc1 -std=c++23 -fsyntax-only -fcxx-exceptions 
-verify=expected23 %s -fexperimental-new-constant-interpreter
 
 
-// expected23-no-diagnostics
-
-
 /// FIXME: The new interpreter is missing all the 'control flows through...' 
diagnostics.
 
 constexpr int f(int n) {  // ref20-error {{constexpr function never produces a 
constant expression}} \
@@ -82,3 +79,27 @@ constexpr int k(int n) {
   return m;
 }
 constexpr int k0 = k(0);
+
+namespace StaticLambdas {
+  constexpr auto static_capture_constexpr() {
+char n = 'n';
+return [n] static { return n; }(); // expected23-error {{a static lambda 
cannot have any captures}} \
+   // expected20-error {{a static lambda 
cannot have any captures}} \
+   // expected20-warning {{are a C++23 
extension}} \
+   // expected20-warning {{is a C++23 
extension}} \
+   // ref23-error {{a static lambda cannot 
have any captures}} \
+   // ref20-error {{a static lambda cannot 
have any captures}} \
+   // ref20-warning {{are a C++23 
extension}} \
+   // ref20-warning {{is a C++23 
extension}}
+  }
+  static_assert(static_capture_constexpr()); // expected23-error {{static 
assertion expression is not an integral constant expression}} \
+ // expected20-error {{static 
assertion expression is not an integral constant expression}} \
+ // ref23-error {{static assertion 
expression is not an integral constant expression}} \
+ // ref20-error {{static assertion 
expression is not an integral constant expression}}
+
+  constexpr auto capture_constexpr() {
+char n = 'n';
+return [n] { return n; }();
+  }
+  static_assert(capture_constexpr());
+}

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

[clang] [clang][Sema] Resolving Inconsistent Arguments Panic in Variadic Template Variables (PR #70280)

[via cfe-commits]

https://github.com/knightXun updated 
https://github.com/llvm/llvm-project/pull/70280

>From 95180e1765fea3ec6de822d0b9926056d0d12404 Mon Sep 17 00:00:00 2001
From: knightXun 
Date: Thu, 26 Oct 2023 09:25:58 +0800
Subject: [PATCH] [clang][Sema] Resolving Panic Caused by Inconsistent
 Arguments in Variadic Template Variables

When template variables are variadic, sema may panic, potentially leading to a 
situation
 where the number of function variables exceeds the number of template 
variables.
The sema compares the template signature and function signature parameters one 
by one,
 which can trigger an assertion error. This PR, when encountering variadic 
templates,
avoids comparing the template signature and function signature parameters one 
by one.

issue: https://github.com/llvm/llvm-project/issues/70191
---
 clang/docs/ReleaseNotes.rst |  3 +++
 clang/lib/Sema/SemaOverload.cpp | 13 +++--
 clang/test/SemaCXX/GH70280.cpp  |  9 +
 3 files changed, 23 insertions(+), 2 deletions(-)
 create mode 100644 clang/test/SemaCXX/GH70280.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index d6719680d2ac70..456be476a95447 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -1069,6 +1069,9 @@ Static Analyzer
   `#65888 `_, and
   `#65887 `_
 
+- Resolving Inconsistent Arguments Panic in Variadic Template Variables.
+  (`#70280: `_).
+
 .. _release-notes-sanitizers:
 
 Sanitizers
diff --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 5026e1d603e5ee..320f53a7159f3e 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -11092,6 +11092,14 @@ static void DiagnoseBadConversion(Sema , 
OverloadCandidate *Cand,
   I--;
   }
 
+  bool isVariadic = false;
+  for (unsigned N = 0; N < Fn->getNumParams(); N++) {
+if (Fn->getParamDecl(N)->isParameterPack()) {
+  isVariadic = true;
+  break;
+}
+  }
+
   std::string FnDesc;
   std::pair FnKindPair =
   ClassifyOverloadCandidate(S, Cand->FoundDecl, Fn, Cand->getRewriteKind(),
@@ -11100,8 +11108,9 @@ static void DiagnoseBadConversion(Sema , 
OverloadCandidate *Cand,
   Expr *FromExpr = Conv.Bad.FromExpr;
   QualType FromTy = Conv.Bad.getFromType();
   QualType ToTy = Conv.Bad.getToType();
-  SourceRange ToParamRange =
-  !isObjectArgument ? Fn->getParamDecl(I)->getSourceRange() : 
SourceRange();
+  SourceRange ToParamRange = !isObjectArgument && !isVariadic
+ ? Fn->getParamDecl(I)->getSourceRange()
+ : SourceRange();
 
   if (FromTy == S.Context.OverloadTy) {
 assert(FromExpr && "overload set argument came from implicit argument?");
diff --git a/clang/test/SemaCXX/GH70280.cpp b/clang/test/SemaCXX/GH70280.cpp
new file mode 100644
index 00..c7f62ffbf27b35
--- /dev/null
+++ b/clang/test/SemaCXX/GH70280.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+namespace PR70280 {
+  typedef a; // expected-error {{a type specifier is required for all 
declarations}}
+  using b = char*;
+  template  void d(c...) = d(0, ""); // expected-error 
{{no matching function for call to 'd'}}
+  // expected-error@-1 {{illegal initializer (only variables can be 
initialized)}}
+  // expected-note@-2 {{candidate function template not viable: no known 
conversion from 'const char[1]' to 'a' (aka 'int') for 2nd argument}}
+}
\ No newline at end of file

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

[clang] [clang][Sema] Resolving Inconsistent Arguments Panic in Variadic Template Variables (PR #70280)

[via cfe-commits]

https://github.com/knightXun updated 
https://github.com/llvm/llvm-project/pull/70280

>From 23a1a74bfef2c974f2fd99569e124ee4a82bbadf Mon Sep 17 00:00:00 2001
From: knightXun 
Date: Thu, 26 Oct 2023 09:25:58 +0800
Subject: [PATCH 1/2] [clang][Sema] Resolving Panic Caused by Inconsistent
 Arguments in Variadic Template Variables

When template variables are variadic, sema may panic, potentially leading to a 
situation
 where the number of function variables exceeds the number of template 
variables.
The sema compares the template signature and function signature parameters one 
by one,
 which can trigger an assertion error. This PR, when encountering variadic 
templates,
avoids comparing the template signature and function signature parameters one 
by one.

issue: https://github.com/llvm/llvm-project/issues/70191
---
 clang/docs/ReleaseNotes.rst |  3 +++
 clang/lib/Sema/SemaOverload.cpp | 13 +++--
 clang/test/SemaCXX/GH70280.cpp  |  9 +
 3 files changed, 23 insertions(+), 2 deletions(-)
 create mode 100644 clang/test/SemaCXX/GH70280.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 4cc148905d4e13..be6161f12ceeea 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -804,6 +804,9 @@ Static Analyzer
   `#65888 `_, and
   `#65887 `_
 
+- Resolving Inconsistent Arguments Panic in Variadic Template Variables.
+  (`#70280: `_).
+
 .. _release-notes-sanitizers:
 
 Sanitizers
diff --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index db386fef0661c0..4e89f4f50b8a6f 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -11044,6 +11044,14 @@ static void DiagnoseBadConversion(Sema , 
OverloadCandidate *Cand,
   I--;
   }
 
+  bool isVariadic = false;
+  for (unsigned N = 0; N < Fn->getNumParams(); N++) {
+if (Fn->getParamDecl(N)->isParameterPack()) {
+  isVariadic = true;
+  break;
+}
+  }
+
   std::string FnDesc;
   std::pair FnKindPair =
   ClassifyOverloadCandidate(S, Cand->FoundDecl, Fn, Cand->getRewriteKind(),
@@ -11052,8 +11060,9 @@ static void DiagnoseBadConversion(Sema , 
OverloadCandidate *Cand,
   Expr *FromExpr = Conv.Bad.FromExpr;
   QualType FromTy = Conv.Bad.getFromType();
   QualType ToTy = Conv.Bad.getToType();
-  SourceRange ToParamRange =
-  !isObjectArgument ? Fn->getParamDecl(I)->getSourceRange() : 
SourceRange();
+  SourceRange ToParamRange = !isObjectArgument && !isVariadic
+ ? Fn->getParamDecl(I)->getSourceRange()
+ : SourceRange();
 
   if (FromTy == S.Context.OverloadTy) {
 assert(FromExpr && "overload set argument came from implicit argument?");
diff --git a/clang/test/SemaCXX/GH70280.cpp b/clang/test/SemaCXX/GH70280.cpp
new file mode 100644
index 00..c7f62ffbf27b35
--- /dev/null
+++ b/clang/test/SemaCXX/GH70280.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+namespace PR70280 {
+  typedef a; // expected-error {{a type specifier is required for all 
declarations}}
+  using b = char*;
+  template  void d(c...) = d(0, ""); // expected-error 
{{no matching function for call to 'd'}}
+  // expected-error@-1 {{illegal initializer (only variables can be 
initialized)}}
+  // expected-note@-2 {{candidate function template not viable: no known 
conversion from 'const char[1]' to 'a' (aka 'int') for 2nd argument}}
+}
\ No newline at end of file

>From 6ef0719dcfd3f82d779cf45e45c17e23ee4e6fb6 Mon Sep 17 00:00:00 2001
From: knightXun 
Date: Tue, 12 Dec 2023 15:05:46 +0800
Subject: [PATCH 2/2] fix format

---
 clang/include/clang/Basic/DiagnosticParseKinds.td | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clang/include/clang/Basic/DiagnosticParseKinds.td 
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index d6652e6a610c1b..902fbf4a0d692c 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1349,7 +1349,7 @@ def warn_omp_extra_tokens_at_eol : Warning<
   "extra tokens at the end of '#pragma omp %0' are ignored">,
   InGroup;
 def err_omp_multiple_step_or_linear_modifier : Error<
-  "multiple %select{'step size'|'linear modifier'}0 found in linear clause">; 
+  "multiple %select{'step size'|'linear modifier'}0 found in linear clause">;
 def warn_pragma_expected_colon_r_paren : Warning<
   "missing ':' or ')' after %0 - ignoring">, InGroup;
 def err_omp_unknown_directive : Error<

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

[compiler-rt] [clang] [libc] [clang-tools-extra] [libcxx] [llvm] [flang] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

[Yeoul Na via cfe-commits]

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

[clang] [clang-format] Fix parsing of `operator<() {}` (PR #75144)

[via cfe-commits]

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

[clang] [Clang][InstrProf] Allow mix-up of absolute path with relative path on command line when using -fprofile-list= (PR #67519)

[Petr Hosek via cfe-commits]

petrhosek wrote:

I think we should close it, the current behavior is as expected.

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

[clang] [Clang][InstrProf] Allow mix-up of absolute path with relative path on command line when using -fprofile-list= (PR #67519)

[Petr Hosek via cfe-commits]

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

[clang] [clang][Interp] Implement inc/dec for IntegralAP (PR #69597)

[Timm Baeder via cfe-commits]

https://github.com/tbaederr updated 
https://github.com/llvm/llvm-project/pull/69597

>From d97047b5ac828e8ed3cfbe606ed4c3616dc5ee44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Timm=20B=C3=A4der?= 
Date: Wed, 18 Oct 2023 15:36:13 +0200
Subject: [PATCH] [clang][Interp] Implement inc/dec for IntegralAP

---
 clang/lib/AST/Interp/IntegralAP.h | 12 ++
 clang/test/AST/Interp/intap.cpp   | 66 ++-
 2 files changed, 68 insertions(+), 10 deletions(-)

diff --git a/clang/lib/AST/Interp/IntegralAP.h 
b/clang/lib/AST/Interp/IntegralAP.h
index 9019f32e6cef2a..d5f46409d231d4 100644
--- a/clang/lib/AST/Interp/IntegralAP.h
+++ b/clang/lib/AST/Interp/IntegralAP.h
@@ -182,17 +182,13 @@ template  class IntegralAP final {
   }
 
   static bool increment(IntegralAP A, IntegralAP *R) {
-// FIXME: Implement.
-assert(false);
-*R = IntegralAP(A.V - 1);
-return false;
+IntegralAP One(1, A.bitWidth());
+return add(A, One, A.bitWidth() + 1, R);
   }
 
   static bool decrement(IntegralAP A, IntegralAP *R) {
-// FIXME: Implement.
-assert(false);
-*R = IntegralAP(A.V - 1);
-return false;
+IntegralAP One(1, A.bitWidth());
+return sub(A, One, A.bitWidth() + 1, R);
   }
 
   static bool add(IntegralAP A, IntegralAP B, unsigned OpBits, IntegralAP *R) {
diff --git a/clang/test/AST/Interp/intap.cpp b/clang/test/AST/Interp/intap.cpp
index c93ec331296647..b99422dc8f9312 100644
--- a/clang/test/AST/Interp/intap.cpp
+++ b/clang/test/AST/Interp/intap.cpp
@@ -57,9 +57,25 @@ namespace APCast {
 }
 
 #ifdef __SIZEOF_INT128__
+typedef __int128 int128_t;
+typedef unsigned __int128 uint128_t;
+static const __uint128_t UINT128_MAX =__uint128_t(__int128_t(-1L));
+static_assert(UINT128_MAX == -1, "");
+static_assert(UINT128_MAX == 1, ""); // expected-error {{static assertion 
failed}} \
+ // expected-note 
{{'340282366920938463463374607431768211455 == 1'}} \
+ // ref-error {{static assertion failed}} \
+ // ref-note 
{{'340282366920938463463374607431768211455 == 1'}}
+
+static const __int128_t INT128_MAX = UINT128_MAX >> (__int128_t)1;
+static_assert(INT128_MAX != 0, "");
+static_assert(INT128_MAX == 0, ""); // expected-error {{failed}} \
+// expected-note {{evaluates to 
'170141183460469231731687303715884105727 == 0'}} \
+// ref-error {{failed}} \
+// ref-note {{evaluates to 
'170141183460469231731687303715884105727 == 0'}}
+static const __int128_t INT128_MIN = -INT128_MAX - 1;
+
 namespace i128 {
-  typedef __int128 int128_t;
-  typedef unsigned __int128 uint128_t;
+
   constexpr int128_t I128_1 = 12;
   static_assert(I128_1 == 12, "");
   static_assert(I128_1 != 10, "");
@@ -200,4 +216,50 @@ namespace BitOps {
   static_assert((Max ^ UZero) == Max, "");
 }
 
+namespace IncDec {
+#if __cplusplus >= 201402L
+  constexpr int128_t maxPlus1(bool Pre) {
+int128_t a = INT128_MAX;
+
+if (Pre)
+  ++a; // ref-note {{value 170141183460469231731687303715884105728 is 
outside the range}} \
+   // expected-note {{value 170141183460469231731687303715884105728 is 
outside the range}}
+else
+  a++; // ref-note {{value 170141183460469231731687303715884105728 is 
outside the range}} \
+   // expected-note {{value 170141183460469231731687303715884105728 is 
outside the range}}
+return a;
+  }
+  static_assert(maxPlus1(true) == 0, ""); // ref-error {{not an integral 
constant expression}} \
+  // ref-note {{in call to}} \
+  // expected-error {{not an integral 
constant expression}} \
+  // expected-note {{in call to}}
+  static_assert(maxPlus1(false) == 0, ""); // ref-error {{not an integral 
constant expression}} \
+   // ref-note {{in call to}} \
+   // expected-error {{not an integral 
constant expression}} \
+   // expected-note {{in call to}}
+
+  constexpr int128_t inc1(bool Pre) {
+int128_t A = 0;
+if (Pre)
+  ++A;
+else
+  A++;
+return A;
+  }
+  static_assert(inc1(true) == 1, "");
+  static_assert(inc1(false) == 1, "");
+
+  constexpr int128_t dec1(bool Pre) {
+int128_t A = 2;
+if (Pre)
+  --A;
+else
+  A--;
+return A;
+  }
+  static_assert(dec1(true) == 1, "");
+  static_assert(dec1(false) == 1, "");
+#endif
+}
+
 #endif

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

[clang] [clang][Sema] Resolving Inconsistent Arguments Panic in Variadic Template Variables (PR #70280)

[via cfe-commits]

https://github.com/knightXun updated 
https://github.com/llvm/llvm-project/pull/70280

>From 23a1a74bfef2c974f2fd99569e124ee4a82bbadf Mon Sep 17 00:00:00 2001
From: knightXun 
Date: Thu, 26 Oct 2023 09:25:58 +0800
Subject: [PATCH] [clang][Sema] Resolving Panic Caused by Inconsistent
 Arguments in Variadic Template Variables

When template variables are variadic, sema may panic, potentially leading to a 
situation
 where the number of function variables exceeds the number of template 
variables.
The sema compares the template signature and function signature parameters one 
by one,
 which can trigger an assertion error. This PR, when encountering variadic 
templates,
avoids comparing the template signature and function signature parameters one 
by one.

issue: https://github.com/llvm/llvm-project/issues/70191
---
 clang/docs/ReleaseNotes.rst |  3 +++
 clang/lib/Sema/SemaOverload.cpp | 13 +++--
 clang/test/SemaCXX/GH70280.cpp  |  9 +
 3 files changed, 23 insertions(+), 2 deletions(-)
 create mode 100644 clang/test/SemaCXX/GH70280.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 4cc148905d4e13..be6161f12ceeea 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -804,6 +804,9 @@ Static Analyzer
   `#65888 `_, and
   `#65887 `_
 
+- Resolving Inconsistent Arguments Panic in Variadic Template Variables.
+  (`#70280: `_).
+
 .. _release-notes-sanitizers:
 
 Sanitizers
diff --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index db386fef0661c0..4e89f4f50b8a6f 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -11044,6 +11044,14 @@ static void DiagnoseBadConversion(Sema , 
OverloadCandidate *Cand,
   I--;
   }
 
+  bool isVariadic = false;
+  for (unsigned N = 0; N < Fn->getNumParams(); N++) {
+if (Fn->getParamDecl(N)->isParameterPack()) {
+  isVariadic = true;
+  break;
+}
+  }
+
   std::string FnDesc;
   std::pair FnKindPair =
   ClassifyOverloadCandidate(S, Cand->FoundDecl, Fn, Cand->getRewriteKind(),
@@ -11052,8 +11060,9 @@ static void DiagnoseBadConversion(Sema , 
OverloadCandidate *Cand,
   Expr *FromExpr = Conv.Bad.FromExpr;
   QualType FromTy = Conv.Bad.getFromType();
   QualType ToTy = Conv.Bad.getToType();
-  SourceRange ToParamRange =
-  !isObjectArgument ? Fn->getParamDecl(I)->getSourceRange() : 
SourceRange();
+  SourceRange ToParamRange = !isObjectArgument && !isVariadic
+ ? Fn->getParamDecl(I)->getSourceRange()
+ : SourceRange();
 
   if (FromTy == S.Context.OverloadTy) {
 assert(FromExpr && "overload set argument came from implicit argument?");
diff --git a/clang/test/SemaCXX/GH70280.cpp b/clang/test/SemaCXX/GH70280.cpp
new file mode 100644
index 00..c7f62ffbf27b35
--- /dev/null
+++ b/clang/test/SemaCXX/GH70280.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+namespace PR70280 {
+  typedef a; // expected-error {{a type specifier is required for all 
declarations}}
+  using b = char*;
+  template  void d(c...) = d(0, ""); // expected-error 
{{no matching function for call to 'd'}}
+  // expected-error@-1 {{illegal initializer (only variables can be 
initialized)}}
+  // expected-note@-2 {{candidate function template not viable: no known 
conversion from 'const char[1]' to 'a' (aka 'int') for 2nd argument}}
+}
\ No newline at end of file

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

[clang] [clang-format] Fix parsing of `operator<() {}` (PR #75144)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang-format

Author: None (XDeme)


Changes

Fixes llvm/llvm-project#74876.

During the parsing of `operator(Foo) {}`, there was no handling for 
the operator, so it called `consumeToken()` again starting from 
`(Foo)`, causing the `AnnotationParser::Scopes` to have one additional 
left brace each time it tried to parse it, leaving it unbalanced.
Because of this, in the following code:
```cpp
class Foo {
  void operator(Foo) {}
  Foo f;
};
```
The `` in the reference member, was being interpreted as 
`TT_BinaryOperator` instead of  `TT_PointerOrReference`.

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


3 Files Affected:

- (modified) clang/lib/Format/TokenAnnotator.cpp (+9) 
- (modified) clang/unittests/Format/FormatTest.cpp (+7) 
- (modified) clang/unittests/Format/TokenAnnotatorTest.cpp (+11) 


``diff
diff --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index eaccb5881ca30f..957612088c7bb0 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -23,6 +23,9 @@
 
 namespace clang {
 namespace format {
+static bool isFunctionDeclarationName(bool IsCpp, const FormatToken ,
+  const AnnotatedLine ,
+  FormatToken *);
 
 static bool mustBreakAfterAttributes(const FormatToken ,
  const FormatStyle ) {
@@ -164,6 +167,12 @@ class AnnotatingParser {
TT_OverloadedOperatorLParen))) {
 return false;
   }
+  FormatToken *ClosingParen = nullptr;
+  if (Previous.Previous->is(tok::kw_operator) &&
+  isFunctionDeclarationName(Style.isCpp(), *Previous.Previous, Line,
+ClosingParen)) {
+return false;
+  }
 }
 
 FormatToken *Left = CurrentToken->Previous;
diff --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 24b2fd599dc397..79013a473a7c2e 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -11727,6 +11727,13 @@ TEST_F(FormatTest, UnderstandsUsesOfStarAndAmp) {
"  void func(type ) { a & member; }\n"
"  anotherType \n"
"}");
+
+  Style.ReferenceAlignment = FormatStyle::RAS_Left;
+  verifyFormat("class Foo {\n"
+   "  void operator<(Foo&) {}\n"
+   "  Foo& f;\n"
+   "};",
+   Style);
 }
 
 TEST_F(FormatTest, UnderstandsAttributes) {
diff --git a/clang/unittests/Format/TokenAnnotatorTest.cpp 
b/clang/unittests/Format/TokenAnnotatorTest.cpp
index 65b1f0f4b57659..58a782f909d6aa 100644
--- a/clang/unittests/Format/TokenAnnotatorTest.cpp
+++ b/clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -298,6 +298,17 @@ TEST_F(TokenAnnotatorTest, UnderstandsUsesOfStarAndAmp) {
   ASSERT_EQ(Tokens.size(), 12u) << Tokens;
   EXPECT_TOKEN(Tokens[2], tok::identifier, TT_TypeName);
   EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
+
+  Tokens = annotate("class Foo {\n"
+"void operator<(Foo&) {}\n"
+"Foo& f;\n"
+"};");
+  ASSERT_EQ(Tokens.size(), 19u) << Tokens;
+  EXPECT_TOKEN(Tokens[4], tok::kw_operator, TT_FunctionDeclarationName);
+  EXPECT_TOKEN(Tokens[5], tok::less, TT_OverloadedOperator);
+  EXPECT_TOKEN(Tokens[6], tok::l_paren, TT_OverloadedOperatorLParen);
+  EXPECT_TOKEN(Tokens[10], tok::l_brace, TT_FunctionLBrace);
+  EXPECT_TOKEN(Tokens[13], tok::amp, TT_PointerOrReference);
 }
 
 TEST_F(TokenAnnotatorTest, UnderstandsUsesOfPlusAndMinus) {

``




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

[clang] [clang-format] Fix parsing of `operator<() {}` (PR #75144)

[via cfe-commits]

https://github.com/XDeme created https://github.com/llvm/llvm-project/pull/75144

Fixes llvm/llvm-project#74876.

During the parsing of `operator<(Foo&) {}`, there was no handling for the 
operator<, so it called `consumeToken()` again starting from `(Foo&)`, causing 
the `AnnotationParser::Scopes` to have one additional left brace each time it 
tried to parse it, leaving it unbalanced.
Because of this, in the following code:
```cpp
class Foo {
  void operator<(Foo&) {}
  Foo& f;
};
```
The `&` in the reference member, was being interpreted as `TT_BinaryOperator` 
instead of  `TT_PointerOrReference`.

>From dddc20d967498c739baedb8d67303a28596f09e0 Mon Sep 17 00:00:00 2001
From: XDeme 
Date: Tue, 12 Dec 2023 03:06:56 -0300
Subject: [PATCH] Fix operator<() parsing

---
 clang/lib/Format/TokenAnnotator.cpp   |  9 +
 clang/unittests/Format/FormatTest.cpp |  7 +++
 clang/unittests/Format/TokenAnnotatorTest.cpp | 11 +++
 3 files changed, 27 insertions(+)

diff --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index eaccb5881ca30f..957612088c7bb0 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -23,6 +23,9 @@
 
 namespace clang {
 namespace format {
+static bool isFunctionDeclarationName(bool IsCpp, const FormatToken ,
+  const AnnotatedLine ,
+  FormatToken *);
 
 static bool mustBreakAfterAttributes(const FormatToken ,
  const FormatStyle ) {
@@ -164,6 +167,12 @@ class AnnotatingParser {
TT_OverloadedOperatorLParen))) {
 return false;
   }
+  FormatToken *ClosingParen = nullptr;
+  if (Previous.Previous->is(tok::kw_operator) &&
+  isFunctionDeclarationName(Style.isCpp(), *Previous.Previous, Line,
+ClosingParen)) {
+return false;
+  }
 }
 
 FormatToken *Left = CurrentToken->Previous;
diff --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 24b2fd599dc397..79013a473a7c2e 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -11727,6 +11727,13 @@ TEST_F(FormatTest, UnderstandsUsesOfStarAndAmp) {
"  void func(type ) { a & member; }\n"
"  anotherType \n"
"}");
+
+  Style.ReferenceAlignment = FormatStyle::RAS_Left;
+  verifyFormat("class Foo {\n"
+   "  void operator<(Foo&) {}\n"
+   "  Foo& f;\n"
+   "};",
+   Style);
 }
 
 TEST_F(FormatTest, UnderstandsAttributes) {
diff --git a/clang/unittests/Format/TokenAnnotatorTest.cpp 
b/clang/unittests/Format/TokenAnnotatorTest.cpp
index 65b1f0f4b57659..58a782f909d6aa 100644
--- a/clang/unittests/Format/TokenAnnotatorTest.cpp
+++ b/clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -298,6 +298,17 @@ TEST_F(TokenAnnotatorTest, UnderstandsUsesOfStarAndAmp) {
   ASSERT_EQ(Tokens.size(), 12u) << Tokens;
   EXPECT_TOKEN(Tokens[2], tok::identifier, TT_TypeName);
   EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
+
+  Tokens = annotate("class Foo {\n"
+"void operator<(Foo&) {}\n"
+"Foo& f;\n"
+"};");
+  ASSERT_EQ(Tokens.size(), 19u) << Tokens;
+  EXPECT_TOKEN(Tokens[4], tok::kw_operator, TT_FunctionDeclarationName);
+  EXPECT_TOKEN(Tokens[5], tok::less, TT_OverloadedOperator);
+  EXPECT_TOKEN(Tokens[6], tok::l_paren, TT_OverloadedOperatorLParen);
+  EXPECT_TOKEN(Tokens[10], tok::l_brace, TT_FunctionLBrace);
+  EXPECT_TOKEN(Tokens[13], tok::amp, TT_PointerOrReference);
 }
 
 TEST_F(TokenAnnotatorTest, UnderstandsUsesOfPlusAndMinus) {

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

[clang] [clang] Crash when referencing capture in static lambda (PR #74661)

[Timm Baeder via cfe-commits]

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

[clang] c88d731 - [clang] Crash when referencing capture in static lambda (#74661)

[via cfe-commits]

Author: Ben Jackson
Date: 2023-12-12T07:30:23+01:00
New Revision: c88d73164a3960c5ef3ff578631f0e765b893809

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

LOG: [clang] Crash when referencing capture in static lambda (#74661)

The constant evaluator could try to reference a lambda capture in a
static lambda call operator. Static lambdas can't have captures, so we
simply abort. Either the lambda needs to be made non-static, or the
capture (and reference to it) need to be removed.

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/AST/ExprConstant.cpp
clang/test/Parser/cxx2b-lambdas.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index d6719680d2ac70..b62293a33bb9ff 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -870,6 +870,10 @@ Miscellaneous Clang Crashes Fixed
   `Issue 41302 `_
 - Fixed a crash when ``-ast-dump=json`` was used for code using class
   template deduction guides.
+- Fixed a crash when a lambda marked as ``static`` referenced a captured
+  variable in an expression.
+  `Issue 74608 `_
+
 
 OpenACC Specific Changes
 

diff  --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index f035c1419f4c98..f6aeee1a4e935d 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -8514,14 +8514,24 @@ bool LValueExprEvaluator::VisitVarDecl(const Expr *E, 
const VarDecl *VD) {
   return false;
 
 if (auto *FD = Info.CurrentCall->LambdaCaptureFields.lookup(VD)) {
+  const auto *MD = cast(Info.CurrentCall->Callee);
+
+  // Static lambda function call operators can't have captures. We already
+  // diagnosed this, so bail out here.
+  if (MD->isStatic()) {
+assert(Info.CurrentCall->This == nullptr &&
+   "This should not be set for a static call operator");
+return false;
+  }
+
   // Start with 'Result' referring to the complete closure object...
-  if (auto *MD = cast(Info.CurrentCall->Callee);
-  MD->isExplicitObjectMemberFunction()) {
+  if (MD->isExplicitObjectMemberFunction()) {
 APValue *RefValue =
 Info.getParamSlot(Info.CurrentCall->Arguments, 
MD->getParamDecl(0));
 Result.setFrom(Info.Ctx, *RefValue);
   } else
 Result = *Info.CurrentCall->This;
+
   // ... then update it to refer to the field of the closure object
   // that represents the capture.
   if (!HandleLValueMember(Info, E, Result, FD))

diff  --git a/clang/test/Parser/cxx2b-lambdas.cpp 
b/clang/test/Parser/cxx2b-lambdas.cpp
index bb9ed226afffaf..ad975a17b6e476 100644
--- a/clang/test/Parser/cxx2b-lambdas.cpp
+++ b/clang/test/Parser/cxx2b-lambdas.cpp
@@ -66,3 +66,15 @@ void static_captures() {
 }
   };
 }
+
+constexpr auto static_capture_constexpr() {
+  char n = 'n';
+  return [n] static { return n; }(); // expected-error {{a static lambda 
cannot have any captures}}
+}
+static_assert(static_capture_constexpr()); // expected-error {{static 
assertion expression is not an integral constant expression}}
+
+constexpr auto capture_constexpr() {
+  char n = 'n';
+  return [n] { return n; }();
+}
+static_assert(capture_constexpr());



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

[clang] [clang] Skip tautological comparison if the comparison involves the 'size_t' type (PR #74427)

[Shivam Gupta via cfe-commits]

xgupta wrote:

Ping @cor3ntin, do you have any more comments for this PR?

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

[clang] [Clang][InstrProf] Allow mix-up of absolute path with relative path on command line when using -fprofile-list= (PR #67519)

[Shivam Gupta via cfe-commits]

xgupta wrote:

@ellishg, @gulfemsavrun  shall we close this PR, or it is of any use? For me, 
it is not much now since it was my mistake to understand the use of 
-fprofile-list.

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

[clang] [clang][Interp] Implement __builtin_rotate{right, left} (PR #72984)

[Timm Baeder via cfe-commits]

https://github.com/tbaederr updated 
https://github.com/llvm/llvm-project/pull/72984

>From 1a2bda9e9b28a4f99e723bf6265cb769e048a315 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Timm=20B=C3=A4der?= 
Date: Tue, 21 Nov 2023 13:44:07 +0100
Subject: [PATCH] [clang][Interp] Implement __builtin_rotate{right,left}

---
 clang/lib/AST/Interp/InterpBuiltin.cpp  | 49 +
 clang/test/AST/Interp/builtin-functions.cpp | 14 ++
 2 files changed, 63 insertions(+)

diff --git a/clang/lib/AST/Interp/InterpBuiltin.cpp 
b/clang/lib/AST/Interp/InterpBuiltin.cpp
index 4384ace6b6be5e..deba38e4e9ddc0 100644
--- a/clang/lib/AST/Interp/InterpBuiltin.cpp
+++ b/clang/lib/AST/Interp/InterpBuiltin.cpp
@@ -579,6 +579,29 @@ static bool interp__builtin_expect(InterpState , CodePtr 
OpPC,
   return true;
 }
 
+/// rotateleft(value, amount)
+static bool interp__builtin_rotate(InterpState , CodePtr OpPC,
+   const InterpFrame *Frame,
+   const Function *Func, const CallExpr *Call,
+   bool Right) {
+  PrimType ArgT = *S.getContext().classify(Call->getArg(0)->getType());
+  assert(ArgT == *S.getContext().classify(Call->getArg(1)->getType()));
+
+  APSInt Amount = peekToAPSInt(S.Stk, ArgT);
+  APSInt Value = peekToAPSInt(S.Stk, ArgT, align(primSize(ArgT)) * 2);
+
+  APSInt Result;
+  if (Right)
+Result = APSInt(Value.rotr(Amount.urem(Value.getBitWidth())),
+/*IsUnsigned=*/true);
+  else // Left.
+Result = APSInt(Value.rotl(Amount.urem(Value.getBitWidth())),
+/*IsUnsigned=*/true);
+
+  pushAPSInt(S, Result);
+  return true;
+}
+
 bool InterpretBuiltin(InterpState , CodePtr OpPC, const Function *F,
   const CallExpr *Call) {
   InterpFrame *Frame = S.Current;
@@ -754,6 +777,32 @@ bool InterpretBuiltin(InterpState , CodePtr OpPC, const 
Function *F,
   return false;
 break;
 
+  case Builtin::BI__builtin_rotateleft8:
+  case Builtin::BI__builtin_rotateleft16:
+  case Builtin::BI__builtin_rotateleft32:
+  case Builtin::BI__builtin_rotateleft64:
+  case Builtin::BI_rotl8: // Microsoft variants of rotate left
+  case Builtin::BI_rotl16:
+  case Builtin::BI_rotl:
+  case Builtin::BI_lrotl:
+  case Builtin::BI_rotl64:
+if (!interp__builtin_rotate(S, OpPC, Frame, F, Call, /*Right=*/false))
+  return false;
+break;
+
+  case Builtin::BI__builtin_rotateright8:
+  case Builtin::BI__builtin_rotateright16:
+  case Builtin::BI__builtin_rotateright32:
+  case Builtin::BI__builtin_rotateright64:
+  case Builtin::BI_rotr8: // Microsoft variants of rotate right
+  case Builtin::BI_rotr16:
+  case Builtin::BI_rotr:
+  case Builtin::BI_lrotr:
+  case Builtin::BI_rotr64:
+if (!interp__builtin_rotate(S, OpPC, Frame, F, Call, /*Right=*/true))
+  return false;
+break;
+
   default:
 return false;
   }
diff --git a/clang/test/AST/Interp/builtin-functions.cpp 
b/clang/test/AST/Interp/builtin-functions.cpp
index 35a1f9a75092a0..62fe9b081c78fa 100644
--- a/clang/test/AST/Interp/builtin-functions.cpp
+++ b/clang/test/AST/Interp/builtin-functions.cpp
@@ -339,3 +339,17 @@ namespace expect {
   static_assert(__builtin_expect(a(),1) == 12, "");
   static_assert(__builtin_expect_with_probability(a(), 1, 1.0) == 12, "");
 }
+
+namespace rotateleft {
+  char rotateleft1[__builtin_rotateleft8(0x01, 5) == 0x20 ? 1 : -1];
+  char rotateleft2[__builtin_rotateleft16(0x3210, 11) == 0x8190 ? 1 : -1];
+  char rotateleft3[__builtin_rotateleft32(0x76543210, 22) == 0x841D950C ? 1 : 
-1];
+  char rotateleft4[__builtin_rotateleft64(0xFEDCBA9876543210ULL, 55) == 
0x87F6E5D4C3B2A19ULL ? 1 : -1];
+}
+
+namespace rotateright {
+  char rotateright1[__builtin_rotateright8(0x01, 5) == 0x08 ? 1 : -1];
+  char rotateright2[__builtin_rotateright16(0x3210, 11) == 0x4206 ? 1 : -1];
+  char rotateright3[__builtin_rotateright32(0x76543210, 22) == 0x50C841D9 ? 1 
: -1];
+  char rotateright4[__builtin_rotateright64(0xFEDCBA9876543210ULL, 55) == 
0xB97530ECA86421FDULL ? 1 : -1];
+}

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

[clang] [clang-tools-extra] [clang][modules] Deprecate module.map in favor of module.modulemap (PR #75142)

[via cfe-commits]

llvmbot wrote:



@llvm/pr-subscribers-clang-modules

@llvm/pr-subscribers-clangd

Author: Michael Spencer (Bigcheese)


Changes

This patch deprecates `module.map` in favor of `module.modulemap`, which has 
been the preferred form since 2014. The eventual goal is to remove support for 
`module.map` to reduce the number of stats Clang needs to do while searching 
for module map files.

This patch touches a lot of files, but the majority of them are just renaming 
tests or references to the file in comments or documentation.

The relevant files are:
* lib/Lex/HeaderSearch.cpp
* include/clang/Basic/DiagnosticGroups.td
* include/clang/Basic/DiagnosticLexKinds.td

---

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


142 Files Affected:

- (modified) clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp (+2-2) 
- (modified) clang-tools-extra/docs/modularize.rst (+1-1) 
- (renamed) 
clang-tools-extra/include-cleaner/test/Inputs/modules/module.modulemap () 
- (modified) clang-tools-extra/modularize/Modularize.cpp (+6-6) 
- (modified) clang-tools-extra/modularize/ModularizeUtilities.cpp (+2-2) 
- (modified) clang-tools-extra/modularize/ModularizeUtilities.h (+2-2) 
- (modified) 
clang-tools-extra/test/modularize/Inputs/CompileError/module.modulemap (+1-1) 
- (modified) 
clang-tools-extra/test/modularize/Inputs/CoverageNoProblems/module.modulemap 
(+1-1) 
- (modified) 
clang-tools-extra/test/modularize/Inputs/CoverageProblems/module.modulemap 
(+1-1) 
- (modified) 
clang-tools-extra/test/modularize/Inputs/MissingHeader/module.modulemap (+1-1) 
- (renamed) clang-tools-extra/test/pp-trace/Inputs/module.modulemap (+1-1) 
- (modified) clang/include/clang-c/BuildSystem.h (+3-3) 
- (modified) clang/include/clang/Basic/DiagnosticGroups.td (+1) 
- (modified) clang/include/clang/Basic/DiagnosticLexKinds.td (+3) 
- (modified) clang/lib/Lex/HeaderSearch.cpp (+17-5) 
- (renamed) clang/test/ARCMT/Inputs/module.modulemap () 
- (renamed) clang/test/Index/Inputs/Frameworks/module.modulemap () 
- (renamed) clang/test/Index/Inputs/Headers/module.modulemap () 
- (renamed) clang/test/Index/Inputs/Headers/nested/module.modulemap () 
- (renamed) clang/test/Index/Inputs/module.modulemap () 
- (modified) clang/test/Index/Inputs/vfsoverlay.yaml (+2-2) 
- (renamed) clang/test/Modules/Inputs/Conflicts/module.modulemap () 
- (renamed) 
clang/test/Modules/Inputs/DependsOnModule.framework/Modules/module.modulemap () 
- (renamed) 
clang/test/Modules/Inputs/DependsOnModule.framework/Modules/module.private.modulemap
 () 
- (renamed) 
clang/test/Modules/Inputs/GNUAsm/NeedsGNUInlineAsm.framework/Modules/module.modulemap
 () 
- (renamed) clang/test/Modules/Inputs/Modified/module.modulemap () 
- (renamed) clang/test/Modules/Inputs/ModuleDiags/module.modulemap () 
- (added) clang/test/Modules/Inputs/ModuleMapLocations/Module_Map/a.h (+1) 
- (added) clang/test/Modules/Inputs/ModuleMapLocations/Module_Map/module.map 
(+3) 
- (added) 
clang/test/Modules/Inputs/ModuleMapLocations/Module_Map/module_private.map (+3) 
- (added) clang/test/Modules/Inputs/ModuleMapLocations/Module_Map/private.h () 
- (added) 
clang/test/Modules/Inputs/ModuleMapLocations/Module_Map_F.framework/Headers/a.h 
() 
- (added) 
clang/test/Modules/Inputs/ModuleMapLocations/Module_Map_F.framework/PrivateHeaders/private.h
 () 
- (added) 
clang/test/Modules/Inputs/ModuleMapLocations/Module_Map_F.framework/module.map 
(+3) 
- (added) 
clang/test/Modules/Inputs/ModuleMapLocations/Module_Map_F.framework/module_private.map
 (+3) 
- (renamed) 
clang/test/Modules/Inputs/NoUmbrella.framework/Modules/module.modulemap () 
- (renamed) 
clang/test/Modules/Inputs/NoUmbrella.framework/Modules/module.private.modulemap 
() 
- (renamed) clang/test/Modules/Inputs/StdDef/module.modulemap () 
- (renamed) clang/test/Modules/Inputs/System/usr/include/module.modulemap () 
- (renamed) clang/test/Modules/Inputs/UseAfterFree/module.modulemap () 
- (renamed) clang/test/Modules/Inputs/UseAfterFree/module.private.modulemap () 
- (renamed) 
clang/test/Modules/Inputs/crash-recovery/usr/include/module.modulemap () 
- (renamed) clang/test/Modules/Inputs/declare-use/module.modulemap () 
- (renamed) clang/test/Modules/Inputs/elsewhere/module.modulemap () 
- (renamed) clang/test/Modules/Inputs/exclude-header/module.modulemap () 
- (renamed) 
clang/test/Modules/Inputs/implicit-private-without-public/DeprecatedModuleMapLocation.framework/module.private.modulemap
 () 
- (renamed) clang/test/Modules/Inputs/include-relative/module.modulemap () 
- (renamed) clang/test/Modules/Inputs/lookup-assert-protocol/module.modulemap 
() 
- (renamed) clang/test/Modules/Inputs/lookup-assert/module.modulemap () 
- (renamed) clang/test/Modules/Inputs/macro-undef-through-pch/module.modulemap 
() 
- (renamed) clang/test/Modules/Inputs/malformed/module.modulemap () 
- (renamed) clang/test/Modules/Inputs/module.modulemap () 
- (renamed) 

[clang] [clang][Interp] Implement __builtin_rotate{right, left} (PR #72984)

[Timm Baeder via cfe-commits]

https://github.com/tbaederr updated 
https://github.com/llvm/llvm-project/pull/72984

>From d728e5a0a38ee24040b360c3aa53ba9575d5c897 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Timm=20B=C3=A4der?= 
Date: Tue, 21 Nov 2023 13:44:07 +0100
Subject: [PATCH] [clang][Interp] Implement __builtin_rotate{right,left}

---
 clang/lib/AST/Interp/InterpBuiltin.cpp  | 49 +
 clang/test/AST/Interp/builtin-functions.cpp | 15 +++
 2 files changed, 64 insertions(+)

diff --git a/clang/lib/AST/Interp/InterpBuiltin.cpp 
b/clang/lib/AST/Interp/InterpBuiltin.cpp
index 4384ace6b6be5e..deba38e4e9ddc0 100644
--- a/clang/lib/AST/Interp/InterpBuiltin.cpp
+++ b/clang/lib/AST/Interp/InterpBuiltin.cpp
@@ -579,6 +579,29 @@ static bool interp__builtin_expect(InterpState , CodePtr 
OpPC,
   return true;
 }
 
+/// rotateleft(value, amount)
+static bool interp__builtin_rotate(InterpState , CodePtr OpPC,
+   const InterpFrame *Frame,
+   const Function *Func, const CallExpr *Call,
+   bool Right) {
+  PrimType ArgT = *S.getContext().classify(Call->getArg(0)->getType());
+  assert(ArgT == *S.getContext().classify(Call->getArg(1)->getType()));
+
+  APSInt Amount = peekToAPSInt(S.Stk, ArgT);
+  APSInt Value = peekToAPSInt(S.Stk, ArgT, align(primSize(ArgT)) * 2);
+
+  APSInt Result;
+  if (Right)
+Result = APSInt(Value.rotr(Amount.urem(Value.getBitWidth())),
+/*IsUnsigned=*/true);
+  else // Left.
+Result = APSInt(Value.rotl(Amount.urem(Value.getBitWidth())),
+/*IsUnsigned=*/true);
+
+  pushAPSInt(S, Result);
+  return true;
+}
+
 bool InterpretBuiltin(InterpState , CodePtr OpPC, const Function *F,
   const CallExpr *Call) {
   InterpFrame *Frame = S.Current;
@@ -754,6 +777,32 @@ bool InterpretBuiltin(InterpState , CodePtr OpPC, const 
Function *F,
   return false;
 break;
 
+  case Builtin::BI__builtin_rotateleft8:
+  case Builtin::BI__builtin_rotateleft16:
+  case Builtin::BI__builtin_rotateleft32:
+  case Builtin::BI__builtin_rotateleft64:
+  case Builtin::BI_rotl8: // Microsoft variants of rotate left
+  case Builtin::BI_rotl16:
+  case Builtin::BI_rotl:
+  case Builtin::BI_lrotl:
+  case Builtin::BI_rotl64:
+if (!interp__builtin_rotate(S, OpPC, Frame, F, Call, /*Right=*/false))
+  return false;
+break;
+
+  case Builtin::BI__builtin_rotateright8:
+  case Builtin::BI__builtin_rotateright16:
+  case Builtin::BI__builtin_rotateright32:
+  case Builtin::BI__builtin_rotateright64:
+  case Builtin::BI_rotr8: // Microsoft variants of rotate right
+  case Builtin::BI_rotr16:
+  case Builtin::BI_rotr:
+  case Builtin::BI_lrotr:
+  case Builtin::BI_rotr64:
+if (!interp__builtin_rotate(S, OpPC, Frame, F, Call, /*Right=*/true))
+  return false;
+break;
+
   default:
 return false;
   }
diff --git a/clang/test/AST/Interp/builtin-functions.cpp 
b/clang/test/AST/Interp/builtin-functions.cpp
index 35a1f9a75092a0..0e50bfe5d6e30e 100644
--- a/clang/test/AST/Interp/builtin-functions.cpp
+++ b/clang/test/AST/Interp/builtin-functions.cpp
@@ -332,10 +332,25 @@ namespace bitreverse {
   char bitreverse4[__builtin_bitreverse64(0x0123456789ABCDEFULL) == 
0xF7B3D591E6A2C480 ? 1 : -1];
 }
 
+<<< HEAD
 namespace expect {
   constexpr int a() {
 return 12;
   }
   static_assert(__builtin_expect(a(),1) == 12, "");
   static_assert(__builtin_expect_with_probability(a(), 1, 1.0) == 12, "");
+===
+namespace rotateleft {
+  char rotateleft1[__builtin_rotateleft8(0x01, 5) == 0x20 ? 1 : -1];
+  char rotateleft2[__builtin_rotateleft16(0x3210, 11) == 0x8190 ? 1 : -1];
+  char rotateleft3[__builtin_rotateleft32(0x76543210, 22) == 0x841D950C ? 1 : 
-1];
+  char rotateleft4[__builtin_rotateleft64(0xFEDCBA9876543210ULL, 55) == 
0x87F6E5D4C3B2A19ULL ? 1 : -1];
+}
+
+namespace rotateright {
+  char rotateright1[__builtin_rotateright8(0x01, 5) == 0x08 ? 1 : -1];
+  char rotateright2[__builtin_rotateright16(0x3210, 11) == 0x4206 ? 1 : -1];
+  char rotateright3[__builtin_rotateright32(0x76543210, 22) == 0x50C841D9 ? 1 
: -1];
+  char rotateright4[__builtin_rotateright64(0xFEDCBA9876543210ULL, 55) == 
0xB97530ECA86421FDULL ? 1 : -1];
+>>> 6417ae298a1a ([clang][Interp] Implement __builtin_rotate{right,left})
 }

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

[clang] [clang][Interp] Decay arrays to the first element (PR #72660)

[Timm Baeder via cfe-commits]

https://github.com/tbaederr updated 
https://github.com/llvm/llvm-project/pull/72660

>From b7277a29fe5bee1197e7ef93730265a9152e36c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Timm=20B=C3=A4der?= 
Date: Fri, 17 Nov 2023 15:54:02 +0100
Subject: [PATCH] [clang][Interp] Decay pointers to the first element

---
 clang/lib/AST/Interp/Interp.h| 6 --
 clang/test/AST/Interp/arrays.cpp | 4 
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/clang/lib/AST/Interp/Interp.h b/clang/lib/AST/Interp/Interp.h
index 4f7778bdd2ff33..4f22259ea51494 100644
--- a/clang/lib/AST/Interp/Interp.h
+++ b/clang/lib/AST/Interp/Interp.h
@@ -1822,10 +1822,12 @@ inline bool ArrayElemPtr(InterpState , CodePtr OpPC) {
 /// Just takes a pointer and checks if its' an incomplete
 /// array type.
 inline bool ArrayDecay(InterpState , CodePtr OpPC) {
-  const Pointer  = S.Stk.peek();
+  const Pointer  = S.Stk.pop();
 
-  if (!Ptr.isUnknownSizeArray())
+  if (!Ptr.isUnknownSizeArray()) {
+S.Stk.push(Ptr.atIndex(0));
 return true;
+  }
 
   const SourceInfo  = S.Current->getSource(OpPC);
   S.FFDiag(E, diag::note_constexpr_unsupported_unsized_array);
diff --git a/clang/test/AST/Interp/arrays.cpp b/clang/test/AST/Interp/arrays.cpp
index 34e0086fb9ee8c..c455731e76699f 100644
--- a/clang/test/AST/Interp/arrays.cpp
+++ b/clang/test/AST/Interp/arrays.cpp
@@ -27,6 +27,10 @@ static_assert(foo[2][3] == , "");
 static_assert(foo[2][4] == nullptr, "");
 
 
+constexpr int SomeInt[] = {1};
+constexpr int getSomeInt() { return *SomeInt; }
+static_assert(getSomeInt() == 1, "");
+
 /// A init list for a primitive value.
 constexpr int f{5};
 static_assert(f == 5, "");

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

[clang] [llvm] [RISCV] Add MC layer support for Zicfiss. (PR #66043)

[Yeting Kuo via cfe-commits]

yetingk wrote:

Rebase and bump to 0.4

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

[clang] [llvm] [RISCV] Add MC layer support for Zicfiss. (PR #66043)

[Yeting Kuo via cfe-commits]

https://github.com/yetingk updated 
https://github.com/llvm/llvm-project/pull/66043

>From 834bb96261b3e7b65a0bbd8f2651c3d307f1de79 Mon Sep 17 00:00:00 2001
From: Yeting Kuo 
Date: Tue, 12 Sep 2023 12:28:00 +0800
Subject: [PATCH 1/6] [RISCV] Add MC layer support for Zicfiss.

The patch adds the instructions in Zicfiss extension. Zicfiss extension is
to support shadow stack for control flow integrity.

Differential Revision: https://reviews.llvm.org/D152793
---
 .../test/Preprocessor/riscv-target-features.c |   9 ++
 llvm/docs/RISCVUsage.rst  |   3 +
 llvm/lib/Support/RISCVISAInfo.cpp |   2 +
 .../RISCV/Disassembler/RISCVDisassembler.cpp  |  29 +
 llvm/lib/Target/RISCV/RISCVFeatures.td|   7 ++
 llvm/lib/Target/RISCV/RISCVInstrInfo.td   |   9 +-
 .../lib/Target/RISCV/RISCVInstrInfoZicfiss.td |  86 +++
 llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp   |   3 +
 llvm/lib/Target/RISCV/RISCVRegisterInfo.td|   9 ++
 llvm/test/MC/RISCV/attribute-arch.s   |   3 +
 llvm/test/MC/RISCV/rv32zicfiss-invalid.s  |  20 
 llvm/test/MC/RISCV/rv32zicfiss-valid.s| 103 ++
 llvm/test/MC/RISCV/rv64zicfiss-invalid.s  |  20 
 llvm/test/MC/RISCV/rv64zicfiss-valid.s| 103 ++
 14 files changed, 402 insertions(+), 4 deletions(-)
 create mode 100644 llvm/lib/Target/RISCV/RISCVInstrInfoZicfiss.td
 create mode 100644 llvm/test/MC/RISCV/rv32zicfiss-invalid.s
 create mode 100644 llvm/test/MC/RISCV/rv32zicfiss-valid.s
 create mode 100644 llvm/test/MC/RISCV/rv64zicfiss-invalid.s
 create mode 100644 llvm/test/MC/RISCV/rv64zicfiss-valid.s

diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 6fc921a8c6ee15..79cf98c2c53b19 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -119,6 +119,7 @@
 // CHECK-NOT: __riscv_zfa {{.*$}}
 // CHECK-NOT: __riscv_zfbfmin {{.*$}}
 // CHECK-NOT: __riscv_zicfilp {{.*$}}
+// CHECK-NOT: __riscv_zicfiss {{.*$}}
 // CHECK-NOT: __riscv_zicond {{.*$}}
 // CHECK-NOT: __riscv_ztso {{.*$}}
 // CHECK-NOT: __riscv_zvbb {{.*$}}
@@ -1278,3 +1279,11 @@
 // RUN: %clang --target=riscv64-unknown-linux-gnu -march=rv64i -E -dM %s \
 // RUN:   -munaligned-access -o - | FileCheck %s 
--check-prefix=CHECK-MISALIGNED-FAST
 // CHECK-MISALIGNED-FAST: __riscv_misaligned_fast 1
+
+// RUN: %clang -target riscv32 -menable-experimental-extensions \
+// RUN: -march=rv32izicfiss0p3 -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZICFISS-EXT %s
+// RUN: %clang -target riscv64 -menable-experimental-extensions \
+// RUN: -march=rv64izicfiss0p3 -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZICFISS-EXT %s
+// CHECK-ZICFISS-EXT: __riscv_zicfiss 3000{{$}}
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 65dd0d83448ed1..e3b0c42c0f9855 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -199,6 +199,9 @@ The primary goal of experimental support is to assist in 
the process of ratifica
 ``experimental-zicfilp``
   LLVM implements the `0.2 draft specification 
`__.
 
+``experimental-zicfiss``
+  LLVM implements the `0.3.1 draft specification 
`__.
+
 ``experimental-zicond``
   LLVM implements the `1.0-rc1 draft specification 
`__.
 
diff --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 6322748430063c..95b326cf559b4d 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -175,6 +175,8 @@ static const RISCVSupportedExtension 
SupportedExperimentalExtensions[] = {
 {"zfbfmin", RISCVExtensionVersion{0, 8}},
 
 {"zicfilp", RISCVExtensionVersion{0, 2}},
+{"zicfiss", RISCVExtensionVersion{0, 3}},
+
 {"zicond", RISCVExtensionVersion{1, 0}},
 
 {"ztso", RISCVExtensionVersion{0, 1}},
diff --git a/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp 
b/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
index 53e2b6b4d94ea0..90c340ccd4f39e 100644
--- a/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
+++ b/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
@@ -74,6 +74,17 @@ static DecodeStatus DecodeGPRRegisterClass(MCInst , 
uint32_t RegNo,
   return MCDisassembler::Success;
 }
 
+static DecodeStatus DecodeGPRRARegisterClass(MCInst , uint32_t RegNo,
+ uint64_t Address,
+ const MCDisassembler *Decoder) {
+  MCRegister Reg = RISCV::X0 + RegNo;
+  if (Reg != RISCV::X1 && Reg != RISCV::X5)
+return MCDisassembler::Fail;
+
+  Inst.addOperand(MCOperand::createReg(Reg));
+  return MCDisassembler::Success;
+}
+
 static DecodeStatus DecodeFPR16RegisterClass(MCInst , 

[clang] [llvm] [RISCV] Update the interface of sifive vqmaccqoq (PR #74284)

[Wang Pengcheng via cfe-commits]

@@ -130,18 +138,18 @@ multiclass RVVVFNRCLIPBuiltinSet;
-defm sf_vqmacc_2x8x2 : RVVVQMACCBuiltinSet<[["", "v", 
"vv(FixedSEW:8)Sv(FixedSEW:8)v"]]>;
-defm sf_vqmaccus_2x8x2 : RVVVQMACCBuiltinSet<[["", "v", 
"vv(FixedSEW:8)SUv(FixedSEW:8)v"]]>;
-defm sf_vqmaccsu_2x8x2 : RVVVQMACCBuiltinSet<[["", "v", 
"vv(FixedSEW:8)Sv(FixedSEW:8)Uv"]]>;
+defm sf_vqmaccu_2x8x2 : RVVVQMACCDODBuiltinSet<[["", "v", 
"vv(FixedSEW:8)SUv(FixedSEW:8)Uv"]]>;
+defm sf_vqmacc_2x8x2 : RVVVQMACCDODBuiltinSet<[["", "v", 
"vv(FixedSEW:8)Sv(FixedSEW:8)v"]]>;
+defm sf_vqmaccus_2x8x2 : RVVVQMACCDODBuiltinSet<[["", "v", 
"vv(FixedSEW:8)SUv(FixedSEW:8)v"]]>;
+defm sf_vqmaccsu_2x8x2 : RVVVQMACCDODBuiltinSet<[["", "v", 
"vv(FixedSEW:8)Sv(FixedSEW:8)Uv"]]>;
   }
 
 let UnMaskedPolicyScheme = HasPolicyOperand in
   let RequiredFeatures = ["Xsfvqmaccqoq"] in {
-defm sf_vqmaccu_4x8x4 : RVVVQMACCBuiltinSet<[["", "v", 
"vv(FixedSEW:8)SUv(FixedSEW:8)Uv"]]>;
-defm sf_vqmacc_4x8x4 : RVVVQMACCBuiltinSet<[["", "v", 
"vv(FixedSEW:8)Sv(FixedSEW:8)v"]]>;
-defm sf_vqmaccus_4x8x4 : RVVVQMACCBuiltinSet<[["", "v", 
"vv(FixedSEW:8)SUv(FixedSEW:8)v"]]>;
-defm sf_vqmaccsu_4x8x4 : RVVVQMACCBuiltinSet<[["", "v", 
"vv(FixedSEW:8)Sv(FixedSEW:8)Uv"]]>;
+defm sf_vqmaccu_4x8x4 : RVVVQMACCQOQBuiltinSet<[["", "w", 
"ww(FixedSEW:8)SUv(FixedSEW:8)Uw"]]>;

wangpc-pp wrote:

It causes assertion `VTM == VectorTypeModifier::NoModifier && 
"VectorTypeModifier should only have one modifier"`.

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

[polly] [clang] [llvm] [polly][ScheduleOptimizer] Fix long compile time(hang) reported in polly (PR #75141)

[Karthika Devi C via cfe-commits]

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

[clang] [llvm] [polly] [polly][ScheduleOptimizer] Fix long compile time(hang) reported in polly (PR #75141)

[Karthika Devi C via cfe-commits]

https://github.com/kartcq created 
https://github.com/llvm/llvm-project/pull/75141




[polly][ScheduleOptimizer] Bail out on exceeding Schedule compute's ISL  quota. 
There is no upper cap set on current Schedule Optimizer to compute schedule. In 
some cases a very long compile time taken to compute the schedule resulting in 
hang kind of behavior. This patch introduces a flag 'polly-schedule-computeout' 
to pass the cap which is initialized to 30. This patch handles the compute 
out cases by bailing out and exiting gracefully.




This patch fixes the bug reported under polly : 
[https://github.com/llvm/llvm-project/issues/69090](https://github.com/llvm/llvm-project/issues/69090)

>From 98745d850c588eaf9b5d2ac6f71c79873107501f Mon Sep 17 00:00:00 2001
From: kartcq 
Date: Mon, 11 Dec 2023 05:22:33 -0800
Subject: [PATCH] [polly][ScheduleOptimizer] Bail out on exceeding Schedule
 compute's ISL  quota

There is no upper cap set on current Schedule Optimizer to compute schedule. In
some cases a very long compile time taken to compute the schedule resulting in
hang kind of behavior. This patch introduces a flag 'polly-schedule-computeout'
to pass the cap which is initialized to 30. This patch handles the compute
out cases by bailing out and exiting gracefully.

Change-Id: Id506832df4ae8d3f140579ba10cf570e18efac62
---
 polly/lib/Transform/ScheduleOptimizer.cpp | 25 +
 .../ScheduleOptimizer/schedule_computeout.ll  | 97 +++
 2 files changed, 122 insertions(+)
 create mode 100644 polly/test/ScheduleOptimizer/schedule_computeout.ll

diff --git a/polly/lib/Transform/ScheduleOptimizer.cpp 
b/polly/lib/Transform/ScheduleOptimizer.cpp
index 35a0a4def0403d..8ee2b66339adbc 100644
--- a/polly/lib/Transform/ScheduleOptimizer.cpp
+++ b/polly/lib/Transform/ScheduleOptimizer.cpp
@@ -96,6 +96,13 @@ static cl::opt
   cl::desc("Maximize the band depth (yes/no)"), cl::Hidden,
   cl::init("yes"), cl::cat(PollyCategory));
 
+static cl::opt
+ScheduleComputeOut("polly-schedule-computeout",
+   cl::desc("Bound the scheduler by maximal amount"
+"of computational steps. "),
+   cl::Hidden, cl::init(30), cl::ZeroOrMore,
+   cl::cat(PollyCategory));
+
 static cl::opt
 GreedyFusion("polly-loopfusion-greedy",
  cl::desc("Aggressively try to fuse everything"), cl::Hidden,
@@ -860,7 +867,25 @@ static void runIslScheduleOptimizer(
 SC = SC.set_proximity(Proximity);
 SC = SC.set_validity(Validity);
 SC = SC.set_coincidence(Validity);
+
+// Save error handling behavior
+long MaxOperations = isl_ctx_get_max_operations(Ctx);
+isl_ctx_set_max_operations(Ctx, ScheduleComputeOut);
 Schedule = SC.compute_schedule();
+bool ScheduleQuota = false;
+if (isl_ctx_last_error(Ctx) == isl_error_quota) {
+  isl_ctx_reset_error(Ctx);
+  LLVM_DEBUG(
+  dbgs() << "Schedule optimizer calculation exceeds ISL quota\n");
+  ScheduleQuota = true;
+}
+isl_options_set_on_error(Ctx, ISL_ON_ERROR_ABORT);
+isl_ctx_reset_operations(Ctx);
+isl_ctx_set_max_operations(Ctx, MaxOperations);
+
+if (ScheduleQuota)
+  return;
+
 isl_options_set_on_error(Ctx, OnErrorStatus);
 
 ScopsRescheduled++;
diff --git a/polly/test/ScheduleOptimizer/schedule_computeout.ll 
b/polly/test/ScheduleOptimizer/schedule_computeout.ll
new file mode 100644
index 00..3e768e02c8a740
--- /dev/null
+++ b/polly/test/ScheduleOptimizer/schedule_computeout.ll
@@ -0,0 +1,97 @@
+; RUN: opt -S -polly-optree -polly-delicm  -polly-opt-isl 
-polly-schedule-computeout=10 -debug-only="polly-opt-isl" < %s 2>&1 | 
FileCheck %s
+; Bailout if the computations of schedule compute exceeds the max scheduling 
quota.
+; Max compute out is initialized to 30, Here it is set to 10 for test 
purpose.
+
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-unknown-linux-gnu"
+
+@a = dso_local local_unnamed_addr global ptr null, align 8
+@b = dso_local local_unnamed_addr global ptr null, align 8
+@c = dso_local local_unnamed_addr global ptr null, align 8
+
+define dso_local void @foo(i32 noundef %I, i32 noundef %J, i32 noundef %K1, 
i32 noundef %K2, i32 noundef %L1, i32 noundef %L2) local_unnamed_addr {
+entry:
+  %j = alloca i32, align 4
+  store volatile i32 0, ptr %j, align 4
+  %j.0.j.0.j.0.54 = load volatile i32, ptr %j, align 4
+  %cmp55 = icmp slt i32 %j.0.j.0.j.0.54, %J
+  br i1 %cmp55, label %for.body.lr.ph, label %for.cond.cleanup
+
+for.body.lr.ph:   ; preds = %entry
+  %0 = load ptr, ptr @a, align 8
+  %1 = load ptr, ptr @b, align 8
+  %2 = load ptr, ptr %1, align 8
+  %cmp352 = icmp slt i32 %L1, %L2
+  %cmp750 = icmp slt i32 %K1, %K2
+  %3 = sext i32 %K1 to i64
+  %4 = sext i32 %L1 to i64
+  br label %for.body
+
+for.cond.cleanup:  

[clang] [clang][sema] make sure arguments of __atomic_exchange complete type (PR #75135)

[via cfe-commits]

knightXun wrote:

cc @shafik @cor3ntin 

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

[llvm] [clang] [RISCV] Update the interface of sifive vqmaccqoq (PR #74284)

[Brandon Wu via cfe-commits]

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

[clang] [OpenMP][Clang] Force use of `num_teams` and `thread_limit` for bare kernel (PR #68373)

[Shilei Tian via cfe-commits]

https://github.com/shiltian updated 
https://github.com/llvm/llvm-project/pull/68373

>From 380046a1117cef08e40f9bcdce2c51c3fe73a26f Mon Sep 17 00:00:00 2001
From: Shilei Tian 
Date: Tue, 12 Dec 2023 00:11:13 -0500
Subject: [PATCH] [OpenMP][Clang] Force use of `num_teams` and `thread_limit`
 for bare kernel

This patch makes `num_teams` and `thread_limit` mandatory for bare kernels,
similar to a reguar kernel language that when launching a kernel, the grid size
has to be set explicitly.
---
 .../clang/Basic/DiagnosticSemaKinds.td|   2 +
 clang/lib/Sema/SemaOpenMP.cpp |  13 ++
 .../nvptx_target_teams_ompx_bare_codegen.cpp  |   2 +-
 clang/test/OpenMP/ompx_bare_messages.c|   7 +-
 clang/test/OpenMP/target_teams_ast_print.cpp  |   4 +-
 clang/test/OpenMP/target_teams_codegen.cpp| 206 +-
 6 files changed, 130 insertions(+), 104 deletions(-)

diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 94e97a891baedc..8b2f5d2746f7fc 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11368,6 +11368,8 @@ def err_openmp_vla_in_task_untied : Error<
 def warn_omp_unterminated_declare_target : Warning<
   "expected '#pragma omp end declare target' at end of file to match '#pragma 
omp %0'">,
   InGroup;
+def err_ompx_bare_no_grid : Error<
+  "'ompx_bare' clauses requires explicit grid size via 'num_teams' and 
'thread_limit' clauses">;
 } // end of OpenMP category
 
 let CategoryName = "Related Result Type Issue" in {
diff --git a/clang/lib/Sema/SemaOpenMP.cpp b/clang/lib/Sema/SemaOpenMP.cpp
index e400f248d15aa3..3826994ef2126c 100644
--- a/clang/lib/Sema/SemaOpenMP.cpp
+++ b/clang/lib/Sema/SemaOpenMP.cpp
@@ -14658,6 +14658,19 @@ StmtResult 
Sema::ActOnOpenMPTargetTeamsDirective(ArrayRef Clauses,
   }
   setFunctionHasBranchProtectedScope();
 
+  const OMPClause *BareClause = nullptr;
+  bool HasThreadLimitAndNumTeamsClause = hasClauses(Clauses, OMPC_num_teams) &&
+ hasClauses(Clauses, 
OMPC_thread_limit);
+  bool HasBareClause = llvm::any_of(Clauses, [&](const OMPClause *C) {
+BareClause = C;
+return C->getClauseKind() == OMPC_ompx_bare;
+  });
+
+  if (HasBareClause && !HasThreadLimitAndNumTeamsClause) {
+Diag(BareClause->getBeginLoc(), diag::err_ompx_bare_no_grid);
+return StmtError();
+  }
+
   return OMPTargetTeamsDirective::Create(Context, StartLoc, EndLoc, Clauses,
  AStmt);
 }
diff --git a/clang/test/OpenMP/nvptx_target_teams_ompx_bare_codegen.cpp 
b/clang/test/OpenMP/nvptx_target_teams_ompx_bare_codegen.cpp
index 9f8046acb09703..2e6f0a9ce0169f 100644
--- a/clang/test/OpenMP/nvptx_target_teams_ompx_bare_codegen.cpp
+++ b/clang/test/OpenMP/nvptx_target_teams_ompx_bare_codegen.cpp
@@ -10,7 +10,7 @@ template
 tx ftemplate(int n) {
   tx a = 0;
 
-  #pragma omp target teams ompx_bare
+  #pragma omp target teams ompx_bare num_teams(1) thread_limit(32)
   {
 a = 2;
   }
diff --git a/clang/test/OpenMP/ompx_bare_messages.c 
b/clang/test/OpenMP/ompx_bare_messages.c
index a1b3c380285287..19ceee5625feec 100644
--- a/clang/test/OpenMP/ompx_bare_messages.c
+++ b/clang/test/OpenMP/ompx_bare_messages.c
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -verify -fopenmp -triple x86_64-unknown-unknown %s
- // RUN: %clang_cc1 -verify -fopenmp-simd -triple x86_64-unknown-unknown %s
- // RUN: %clang_cc1 -verify -fopenmp -triple x86_64-unknown-unknown 
-fopenmp-targets=nvptx64 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -triple x86_64-unknown-unknown %s
+// RUN: %clang_cc1 -verify -fopenmp -triple x86_64-unknown-unknown 
-fopenmp-targets=nvptx64 %s
 
 void foo() {
 }
@@ -18,4 +18,7 @@ void bar() {
 #pragma omp target
 #pragma omp teams ompx_bare // expected-error {{unexpected OpenMP clause 
'ompx_bare' in directive '#pragma omp teams'}} expected-note {{OpenMP extension 
clause 'ompx_bare' only allowed with '#pragma omp target teams'}}
   foo();
+
+#pragma omp target teams ompx_bare // expected-error {{'ompx_bare' clauses 
requires explicit grid size via 'num_teams' and 'thread_limit' clauses}}
+  foo();
 }
diff --git a/clang/test/OpenMP/target_teams_ast_print.cpp 
b/clang/test/OpenMP/target_teams_ast_print.cpp
index 5f1040be01a25f..8eaf4cbf249331 100644
--- a/clang/test/OpenMP/target_teams_ast_print.cpp
+++ b/clang/test/OpenMP/target_teams_ast_print.cpp
@@ -111,8 +111,8 @@ int main (int argc, char **argv) {
 // CHECK-NEXT: #pragma omp target teams
   a=2;
 // CHECK-NEXT: a = 2;
-#pragma omp target teams ompx_bare
-// CHECK-NEXT: #pragma omp target teams ompx_bare
+#pragma omp target teams ompx_bare num_teams(1) thread_limit(32)
+// CHECK-NEXT: #pragma omp target teams ompx_bare num_teams(1) thread_limit(32)
   a=3;
 // CHECK-NEXT: a = 3;
 #pragma omp target teams default(none), private(argc,b) num_teams(f) 
firstprivate(argv) reduction(| : c, d) reduction(* : e) 

[clang] [clang][sema] make sure arguments of __atomic_exchange complete type (PR #75135)

[via cfe-commits]

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

[clang] [clang][sema] check args of __atomic_exchange is complete type (PR #75135)

[via cfe-commits]

https://github.com/knightXun updated 
https://github.com/llvm/llvm-project/pull/75135

>From dc3714573f92b2303ca3bad046b355ccb66c2957 Mon Sep 17 00:00:00 2001
From: knightXun 
Date: Tue, 12 Dec 2023 12:23:54 +0800
Subject: [PATCH 1/2] [clang][sema] check args of __atomic_exchange is complete
 type make sure the args of __atomic_exchange is complete type, make it
 consistent with GCC issue: https://github.com/llvm/llvm-project/issues/74464

---
 clang/lib/Sema/SemaChecking.cpp | 12 
 clang/test/Sema/atomic-ops.c|  4 +++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index cdb6e9584e955..a88d3a6928edd 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -7885,6 +7885,18 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange, 
SourceRange ExprRange,
   if ((IsOpenCL || IsHIP || IsScoped) &&
   Op != AtomicExpr::AO__opencl_atomic_init)
 ++AdjustedNumArgs;
+
+  // Check if the arguments are CompleteType
+  if (Op == AtomicExpr::AO__atomic_exchange) {
+for (auto Arg : Args) {
+  auto ValType = Arg->getType();
+  if (ValType->isPointerType() && !ValType->isNullPtrType() &&
+  RequireCompleteType(Arg->getBeginLoc(), ValType->getPointeeType(),
+  diag::err_incomplete_type)) {
+return ExprError();
+  }
+}
+  }
   // Check we have the right number of arguments.
   if (Args.size() < AdjustedNumArgs) {
 Diag(CallRange.getEnd(), diag::err_typecheck_call_too_few_args)
diff --git a/clang/test/Sema/atomic-ops.c b/clang/test/Sema/atomic-ops.c
index 4fa1223b3038f..6f1d3c4b86ef9 100644
--- a/clang/test/Sema/atomic-ops.c
+++ b/clang/test/Sema/atomic-ops.c
@@ -19,6 +19,7 @@
 
 // Basic parsing/Sema tests for __c11_atomic_*
 
+#include "clang-c/Index.h"
 #include 
 
 struct S { char c[3]; };
@@ -130,7 +131,7 @@ _Static_assert(__atomic_always_lock_free(8, ), "");
 void f(_Atomic(int) *i, const _Atomic(int) *ci,
_Atomic(int*) *p, _Atomic(float) *f, _Atomic(double) *d,
_Atomic(long double) *ld,
-   int *I, const int *CI,
+   int *I, const int *CI,char c[],
int **P, float *F, double *D, struct S *s1, struct S *s2) {
   __c11_atomic_init(I, 5); // expected-error {{pointer to _Atomic}}
   __c11_atomic_init(ci, 5); // expected-error {{address argument to atomic 
operation must be a pointer to non-const _Atomic type ('const _Atomic(int) *' 
invalid)}}
@@ -192,6 +193,7 @@ void f(_Atomic(int) *i, const _Atomic(int) *ci,
   (int)__atomic_exchange(s1, s2, s2, memory_order_seq_cst); // expected-error 
{{operand of type 'void'}}
   __atomic_exchange(I, I, I, memory_order_seq_cst);
   __atomic_exchange(CI, I, I, memory_order_seq_cst); // expected-error 
{{address argument to atomic operation must be a pointer to non-const type 
('const int *' invalid)}}
+  __atomic_exchange(, I, I, memory_order_seq_cst); // expected-error 
{{incomplete type 'char[]' where a complete type is required}}
   __atomic_exchange(I, I, CI, memory_order_seq_cst); // expected-warning 
{{passing 'const int *' to parameter of type 'int *' discards qualifiers}}
 
   __c11_atomic_fetch_add(i, 1, memory_order_seq_cst);

>From ba0f684674610a0c6d7600859088cdace5480126 Mon Sep 17 00:00:00 2001
From: knightXun 
Date: Tue, 12 Dec 2023 13:05:56 +0800
Subject: [PATCH 2/2] fix ut

---
 clang/lib/Sema/SemaChecking.cpp | 2 +-
 clang/test/Sema/atomic-ops.c| 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index a88d3a6928edd..60706e4195bc5 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -7886,7 +7886,7 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange, 
SourceRange ExprRange,
   Op != AtomicExpr::AO__opencl_atomic_init)
 ++AdjustedNumArgs;
 
-  // Check if the arguments are CompleteType
+  // Verify if the arguments are of type CompleteType
   if (Op == AtomicExpr::AO__atomic_exchange) {
 for (auto Arg : Args) {
   auto ValType = Arg->getType();
diff --git a/clang/test/Sema/atomic-ops.c b/clang/test/Sema/atomic-ops.c
index 6f1d3c4b86ef9..d3402b97818d1 100644
--- a/clang/test/Sema/atomic-ops.c
+++ b/clang/test/Sema/atomic-ops.c
@@ -18,8 +18,6 @@
 // RUN:   -mabi=quadword-atomics -target-cpu pwr8 -DPPC64_PWR8
 
 // Basic parsing/Sema tests for __c11_atomic_*
-
-#include "clang-c/Index.h"
 #include 
 
 struct S { char c[3]; };
@@ -131,7 +129,7 @@ _Static_assert(__atomic_always_lock_free(8, ), "");
 void f(_Atomic(int) *i, const _Atomic(int) *ci,
_Atomic(int*) *p, _Atomic(float) *f, _Atomic(double) *d,
_Atomic(long double) *ld,
-   int *I, const int *CI,char c[],
+   int *I, const int *CI,
int **P, float *F, double *D, struct S *s1, struct S *s2) {
   __c11_atomic_init(I, 5); // expected-error {{pointer to _Atomic}}
   __c11_atomic_init(ci, 5); // expected-error 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

https://github.com/rapidsna commented:

Thanks @AaronBallman for your feedback! I left inlined comments to answer these 
and updated documents.

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

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

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

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [BoundsSafety] Initial documentation for -fbounds-safety (PR #70749)

[Yeoul Na via cfe-commits]

@@ -0,0 +1,362 @@
+==
+``-fbounds-safety``: Enforcing bounds safety for C
+==
+
+.. contents::
+   :local:
+
+Overview
+
+
+``-fbounds-safety`` is a C extension to enforce bounds safety to prevent 
out-of-bounds (OOB) memory accesses, which remain a major source of security 
vulnerabilities in C. ``-fbounds-safety`` aims to eliminate this class of bugs 
by turning OOB accesses into deterministic traps.
+
+The ``-fbounds-safety`` extension offers bounds annotations that programmers 
can use to attach bounds to pointers. For example, programmers can add the 
``__counted_by(N)`` annotation to parameter ``ptr``, indicating that the 
pointer has ``N`` valid elements:
+
+.. code-block:: c
+
+   void foo(int *__counted_by(N) ptr, size_t N);
+
+Using this bounds information, the compiler inserts bounds checks on every 
pointer dereference, ensuring that the program does not access memory outside 
the specified bounds. The compiler requires programmers to provide enough 
bounds information so that the accesses can be checked at either run time or 
compile time — and it rejects code if it cannot.
+
+The most important contribution of ``-fbounds-safety`` is how it reduces the 
programmer’s annotation burden by reconciling bounds annotations at ABI 
boundaries with the use of implicit wide pointers (a.k.a. “fat” pointers) that 
carry bounds information on local variables without the need for annotations. 
We designed this model so that it preserves ABI compatibility with C while 
minimizing adoption effort.
+
+The ``-fbounds-safety`` extension has been adopted on millions of lines of 
production C code and proven to work in a consumer operating system setting. 
The extension was designed to enable incremental adoption — a key requirement 
in real-world settings where modifying an entire project and its dependencies 
all at once is often not possible. It also addresses multiple of other 
practical challenges that have made existing approaches to safer C dialects 
difficult to adopt, offering these properties that make it widely adoptable in 
practice:
+
+* It is designed to preserve the Application Binary Interface (ABI).
+* It interoperates well with plain C code.
+* It can be adopted partially and incrementally while still providing safety 
benefits.
+* It is syntactically and semantically compatible with C.
+* Consequently, source code that adopts the extension can continue to be 
compiled by toolchains that do not support the extension.
+* It has a relatively low adoption cost.
+* It can be implemented on top of Clang.
+
+This document discusses the key designs of ``-fbounds-safety``. The document 
is subject to be actively updated with a more detailed specification. The 
implementation plan can be found in `Implementation plans for -fbounds-safety 
`_.
+
+Programming Model
+=
+
+Overview
+
+
+``-fbounds-safety`` ensures that pointers are not used to access memory beyond 
their bounds by performing bounds checking. If a bounds check fails, the 
program will deterministically trap before out-of-bounds memory is accessed.
+
+In our model, every pointer has an explicit or implicit bounds attribute that 
determines its bounds and ensures guaranteed bounds checking. Consider the 
example below where the ``__counted_by(count)`` annotation indicates that 
parameter ``p`` points to a buffer of integers containing ``count`` elements. 
An off-by-one error is present in the loop condition, leading to ``p[i]`` being 
out-of-bounds access during the loop’s final iteration. The compiler inserts a 
bounds check before ``p`` is dereferenced to ensure that the access remains 
within the specified bounds.
+
+.. code-block:: c
+
+   void fill_array_with_indices(int *__counted_by(count) p, unsigned count) {
+   // off-by-one error (i < count)
+  for (unsigned i = 0; i <= count; ++i) {
+ // bounds check inserted:
+ //   if (i >= count) trap();
+ p[i] = i;
+  }
+   }
+
+A bounds annotation defines an invariant for the pointer type, and the model 
ensures that this invariant remains true. In the example below, pointer ``p`` 
annotated with ``__counted_by(count)`` must always point to a memory buffer 
containing at least ``count`` elements of the pointee type. Increasing the 
value of ``count``, like in the example below, would violate this invariant and 
permit out-of-bounds access to the pointer. To avoid this, the compiler emits 
either a compile-time error or a run-time trap. Section `Maintaining 
correctness of bounds annotations`_ provides more details about the programming 
model.
+
+.. code-block:: c
+
+   void foo(int *__counted_by(count) p, size_t count) {
+  count++; // violates the invariant of __counted_by
+   }
+
+The requirement to annotate all pointers with explicit bounds information 
could present a significant adoption burden. To tackle 

[clang] [clang][sema] check args of __atomic_exchange is complete type (PR #75135)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: flyingcat  (knightXun)


Changes

make sure the args of __atomic_exchange is complete type, make it consistent 
with GCC issue: https://github.com/llvm/llvm-project/issues/74464

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


2 Files Affected:

- (modified) clang/lib/Sema/SemaChecking.cpp (+12) 
- (modified) clang/test/Sema/atomic-ops.c (+3-1) 


``diff
diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index cdb6e9584e955..a88d3a6928edd 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -7885,6 +7885,18 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange, 
SourceRange ExprRange,
   if ((IsOpenCL || IsHIP || IsScoped) &&
   Op != AtomicExpr::AO__opencl_atomic_init)
 ++AdjustedNumArgs;
+
+  // Check if the arguments are CompleteType
+  if (Op == AtomicExpr::AO__atomic_exchange) {
+for (auto Arg : Args) {
+  auto ValType = Arg->getType();
+  if (ValType->isPointerType() && !ValType->isNullPtrType() &&
+  RequireCompleteType(Arg->getBeginLoc(), ValType->getPointeeType(),
+  diag::err_incomplete_type)) {
+return ExprError();
+  }
+}
+  }
   // Check we have the right number of arguments.
   if (Args.size() < AdjustedNumArgs) {
 Diag(CallRange.getEnd(), diag::err_typecheck_call_too_few_args)
diff --git a/clang/test/Sema/atomic-ops.c b/clang/test/Sema/atomic-ops.c
index 4fa1223b3038f..6f1d3c4b86ef9 100644
--- a/clang/test/Sema/atomic-ops.c
+++ b/clang/test/Sema/atomic-ops.c
@@ -19,6 +19,7 @@
 
 // Basic parsing/Sema tests for __c11_atomic_*
 
+#include "clang-c/Index.h"
 #include 
 
 struct S { char c[3]; };
@@ -130,7 +131,7 @@ _Static_assert(__atomic_always_lock_free(8, ), "");
 void f(_Atomic(int) *i, const _Atomic(int) *ci,
_Atomic(int*) *p, _Atomic(float) *f, _Atomic(double) *d,
_Atomic(long double) *ld,
-   int *I, const int *CI,
+   int *I, const int *CI,char c[],
int **P, float *F, double *D, struct S *s1, struct S *s2) {
   __c11_atomic_init(I, 5); // expected-error {{pointer to _Atomic}}
   __c11_atomic_init(ci, 5); // expected-error {{address argument to atomic 
operation must be a pointer to non-const _Atomic type ('const _Atomic(int) *' 
invalid)}}
@@ -192,6 +193,7 @@ void f(_Atomic(int) *i, const _Atomic(int) *ci,
   (int)__atomic_exchange(s1, s2, s2, memory_order_seq_cst); // expected-error 
{{operand of type 'void'}}
   __atomic_exchange(I, I, I, memory_order_seq_cst);
   __atomic_exchange(CI, I, I, memory_order_seq_cst); // expected-error 
{{address argument to atomic operation must be a pointer to non-const type 
('const int *' invalid)}}
+  __atomic_exchange(, I, I, memory_order_seq_cst); // expected-error 
{{incomplete type 'char[]' where a complete type is required}}
   __atomic_exchange(I, I, CI, memory_order_seq_cst); // expected-warning 
{{passing 'const int *' to parameter of type 'int *' discards qualifiers}}
 
   __c11_atomic_fetch_add(i, 1, memory_order_seq_cst);

``




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

[clang] [clang][sema] check args of __atomic_exchange is complete type (PR #75135)

[via cfe-commits]

https://github.com/knightXun created 
https://github.com/llvm/llvm-project/pull/75135

make sure the args of __atomic_exchange is complete type, make it consistent 
with GCC issue: https://github.com/llvm/llvm-project/issues/74464

>From dc3714573f92b2303ca3bad046b355ccb66c2957 Mon Sep 17 00:00:00 2001
From: knightXun 
Date: Tue, 12 Dec 2023 12:23:54 +0800
Subject: [PATCH] [clang][sema] check args of __atomic_exchange is complete
 type make sure the args of __atomic_exchange is complete type, make it
 consistent with GCC issue: https://github.com/llvm/llvm-project/issues/74464

---
 clang/lib/Sema/SemaChecking.cpp | 12 
 clang/test/Sema/atomic-ops.c|  4 +++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index cdb6e9584e9554..a88d3a6928eddd 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -7885,6 +7885,18 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange, 
SourceRange ExprRange,
   if ((IsOpenCL || IsHIP || IsScoped) &&
   Op != AtomicExpr::AO__opencl_atomic_init)
 ++AdjustedNumArgs;
+
+  // Check if the arguments are CompleteType
+  if (Op == AtomicExpr::AO__atomic_exchange) {
+for (auto Arg : Args) {
+  auto ValType = Arg->getType();
+  if (ValType->isPointerType() && !ValType->isNullPtrType() &&
+  RequireCompleteType(Arg->getBeginLoc(), ValType->getPointeeType(),
+  diag::err_incomplete_type)) {
+return ExprError();
+  }
+}
+  }
   // Check we have the right number of arguments.
   if (Args.size() < AdjustedNumArgs) {
 Diag(CallRange.getEnd(), diag::err_typecheck_call_too_few_args)
diff --git a/clang/test/Sema/atomic-ops.c b/clang/test/Sema/atomic-ops.c
index 4fa1223b3038f3..6f1d3c4b86ef9a 100644
--- a/clang/test/Sema/atomic-ops.c
+++ b/clang/test/Sema/atomic-ops.c
@@ -19,6 +19,7 @@
 
 // Basic parsing/Sema tests for __c11_atomic_*
 
+#include "clang-c/Index.h"
 #include 
 
 struct S { char c[3]; };
@@ -130,7 +131,7 @@ _Static_assert(__atomic_always_lock_free(8, ), "");
 void f(_Atomic(int) *i, const _Atomic(int) *ci,
_Atomic(int*) *p, _Atomic(float) *f, _Atomic(double) *d,
_Atomic(long double) *ld,
-   int *I, const int *CI,
+   int *I, const int *CI,char c[],
int **P, float *F, double *D, struct S *s1, struct S *s2) {
   __c11_atomic_init(I, 5); // expected-error {{pointer to _Atomic}}
   __c11_atomic_init(ci, 5); // expected-error {{address argument to atomic 
operation must be a pointer to non-const _Atomic type ('const _Atomic(int) *' 
invalid)}}
@@ -192,6 +193,7 @@ void f(_Atomic(int) *i, const _Atomic(int) *ci,
   (int)__atomic_exchange(s1, s2, s2, memory_order_seq_cst); // expected-error 
{{operand of type 'void'}}
   __atomic_exchange(I, I, I, memory_order_seq_cst);
   __atomic_exchange(CI, I, I, memory_order_seq_cst); // expected-error 
{{address argument to atomic operation must be a pointer to non-const type 
('const int *' invalid)}}
+  __atomic_exchange(, I, I, memory_order_seq_cst); // expected-error 
{{incomplete type 'char[]' where a complete type is required}}
   __atomic_exchange(I, I, CI, memory_order_seq_cst); // expected-warning 
{{passing 'const int *' to parameter of type 'int *' discards qualifiers}}
 
   __c11_atomic_fetch_add(i, 1, memory_order_seq_cst);

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

[clang] [analyzer] Move alpha checker EnumCastOutOfRange to optin (PR #67157)

[Gábor Horváth via cfe-commits]

Xazax-hun wrote:

I am a bit concerned about the bad user experience with bitwise enums, but I 
think that is probably OK since this is an optin check. That being said, I 
think:
* It would be easy to address this, there is already a clang tidy check for 
bitwise enums, the heuristics to recognize them could be reused from there and 
used to suppress bogus warnings.
* As long as this limitation is documented, I am happy to get this merged as is.

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

[clang] [clang][ASTImporter] add processing of SubstNonTypeTemplateParmExpr in isAncestorDeclContextOf (PR #74991)

[Qizhi Hu via cfe-commits]

https://github.com/jcsxky updated 
https://github.com/llvm/llvm-project/pull/74991

>From e5a6b1423919ded1ae11b431b2afa7213d052c41 Mon Sep 17 00:00:00 2001
From: huqizhi 
Date: Sun, 10 Dec 2023 21:01:49 +0800
Subject: [PATCH] [clang][ASTImporter] add processing of
 SubstNonTypeTemplateParmExpr in isAncestorDeclContextOf

---
 clang/lib/AST/ASTImporter.cpp   |  8 +++-
 clang/unittests/AST/ASTImporterTest.cpp | 20 
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index f1f335118f37a4..e0eed03ce22b51 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -3418,10 +3418,16 @@ static bool isAncestorDeclContextOf(const DeclContext 
*DC, const Stmt *S) {
   while (!ToProcess.empty()) {
 const Stmt *CurrentS = ToProcess.pop_back_val();
 ToProcess.append(CurrentS->child_begin(), CurrentS->child_end());
-if (const auto *DeclRef = dyn_cast(CurrentS))
+if (const auto *DeclRef = dyn_cast(CurrentS)) {
   if (const Decl *D = DeclRef->getDecl())
 if (isAncestorDeclContextOf(DC, D))
   return true;
+} else if (const auto *E =
+   dyn_cast_or_null(CurrentS)) {
+  if (const Decl *D = E->getAssociatedDecl())
+if (isAncestorDeclContextOf(DC, D))
+  return true;
+}
   }
   return false;
 }
diff --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index 4dd7510bf8ddf8..7ab9db4251e80b 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -9284,6 +9284,26 @@ TEST_P(ASTImporterOptionSpecificTestBase,
   // EXPECT_EQ(ToF1Imported->getPreviousDecl(), ToF1);
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, ImportFunctionAutoType) {
+  const char *Code =
+  R"(
+  template
+  struct array {};
+
+  template 
+  auto foo() { return array(); }
+
+  void bar() { foo<0>(); }
+  )";
+  Decl *FromTU = getTuDecl(Code, Lang_CXX17);
+
+  auto *FromBar = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("bar")));
+
+  auto *ToBar = Import(FromBar, Lang_CXX17);
+  EXPECT_TRUE(ToBar);
+}
+
 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][ASTImporter] add processing of SubstNonTypeTemplateParmExpr in isAncestorDeclContextOf (PR #74991)

[Qizhi Hu via cfe-commits]

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

[clang] [clang][ASTImporter] add processing of SubstNonTypeTemplateParmExpr in isAncestorDeclContextOf (PR #74991)

[Qizhi Hu via cfe-commits]

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

[clang] [clang][ASTImporter] delay import funtion return type (PR #74991)

[Qizhi Hu via cfe-commits]

https://github.com/jcsxky updated 
https://github.com/llvm/llvm-project/pull/74991

>From 07b7415da7af38c45f4d22ba4d42f435c6a9fe68 Mon Sep 17 00:00:00 2001
From: huqizhi 
Date: Sun, 10 Dec 2023 21:01:49 +0800
Subject: [PATCH] [clang][ASTImporter] add processing of
 SubstNonTypeTemplateParmExpr in isAncestorDeclContextOf

---
 clang/lib/AST/ASTImporter.cpp   |  7 ++-
 clang/unittests/AST/ASTImporterTest.cpp | 20 
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index f1f335118f37a4..8c8be7c1d8b24b 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -3418,10 +3418,15 @@ static bool isAncestorDeclContextOf(const DeclContext 
*DC, const Stmt *S) {
   while (!ToProcess.empty()) {
 const Stmt *CurrentS = ToProcess.pop_back_val();
 ToProcess.append(CurrentS->child_begin(), CurrentS->child_end());
-if (const auto *DeclRef = dyn_cast(CurrentS))
+if (const auto *DeclRef = dyn_cast(CurrentS)) {
   if (const Decl *D = DeclRef->getDecl())
 if (isAncestorDeclContextOf(DC, D))
   return true;
+} else if (const auto *E =
+   dyn_cast_or_null(CurrentS)) {
+  if (isAncestorDeclContextOf(DC, E->getAssociatedDecl()))
+return true;
+}
   }
   return false;
 }
diff --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index 4dd7510bf8ddf8..7ab9db4251e80b 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -9284,6 +9284,26 @@ TEST_P(ASTImporterOptionSpecificTestBase,
   // EXPECT_EQ(ToF1Imported->getPreviousDecl(), ToF1);
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, ImportFunctionAutoType) {
+  const char *Code =
+  R"(
+  template
+  struct array {};
+
+  template 
+  auto foo() { return array(); }
+
+  void bar() { foo<0>(); }
+  )";
+  Decl *FromTU = getTuDecl(Code, Lang_CXX17);
+
+  auto *FromBar = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("bar")));
+
+  auto *ToBar = Import(FromBar, Lang_CXX17);
+  EXPECT_TRUE(ToBar);
+}
+
 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][ASTImporter] delay import funtion return type (PR #74991)

[Qizhi Hu via cfe-commits]

https://github.com/jcsxky updated 
https://github.com/llvm/llvm-project/pull/74991

>From 8dc4955fad0147db16bddfe8fc7d227ae69b89a1 Mon Sep 17 00:00:00 2001
From: huqizhi 
Date: Sun, 10 Dec 2023 21:01:49 +0800
Subject: [PATCH] [clang][ASTImporter] add processing of
 SubstNonTypeTemplateParmExpr in isAncestorDeclContextOf

---
 clang/lib/AST/ASTImporter.cpp   | 15 ++-
 clang/unittests/AST/ASTImporterTest.cpp | 20 
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index f1f335118f37a4..8f360e9443011f 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -3418,10 +3418,15 @@ static bool isAncestorDeclContextOf(const DeclContext 
*DC, const Stmt *S) {
   while (!ToProcess.empty()) {
 const Stmt *CurrentS = ToProcess.pop_back_val();
 ToProcess.append(CurrentS->child_begin(), CurrentS->child_end());
-if (const auto *DeclRef = dyn_cast(CurrentS))
+if (const auto *DeclRef = dyn_cast(CurrentS)) {
   if (const Decl *D = DeclRef->getDecl())
 if (isAncestorDeclContextOf(DC, D))
   return true;
+} else if (const auto *E =
+   dyn_cast_or_null(CurrentS)) {
+  if (isAncestorDeclContextOf(DC, E->getAssociatedDecl()))
+return true;
+}
   }
   return false;
 }
@@ -3745,15 +3750,15 @@ ExpectedDecl 
ASTNodeImporter::VisitFunctionDecl(FunctionDecl *D) {
 // E.g.: auto foo() { struct X{}; return X(); }
 // To avoid an infinite recursion when importing, create the FunctionDecl
 // with a simplified return type.
-if (hasAutoReturnTypeDeclaredInside(D)) {
-  FromReturnTy = Importer.getFromContext().VoidTy;
-  UsedDifferentProtoType = true;
-}
 FunctionProtoType::ExtProtoInfo FromEPI = FromFPT->getExtProtoInfo();
 // FunctionProtoType::ExtProtoInfo's ExceptionSpecDecl can point to the
 // FunctionDecl that we are importing the FunctionProtoType for.
 // To avoid an infinite recursion when importing, create the FunctionDecl
 // with a simplified function type.
+if (hasAutoReturnTypeDeclaredInside(D)) {
+  FromReturnTy = Importer.getFromContext().VoidTy;
+  UsedDifferentProtoType = true;
+}
 if (FromEPI.ExceptionSpec.SourceDecl ||
 FromEPI.ExceptionSpec.SourceTemplate ||
 FromEPI.ExceptionSpec.NoexceptExpr) {
diff --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index 4dd7510bf8ddf8..7ab9db4251e80b 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -9284,6 +9284,26 @@ TEST_P(ASTImporterOptionSpecificTestBase,
   // EXPECT_EQ(ToF1Imported->getPreviousDecl(), ToF1);
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, ImportFunctionAutoType) {
+  const char *Code =
+  R"(
+  template
+  struct array {};
+
+  template 
+  auto foo() { return array(); }
+
+  void bar() { foo<0>(); }
+  )";
+  Decl *FromTU = getTuDecl(Code, Lang_CXX17);
+
+  auto *FromBar = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("bar")));
+
+  auto *ToBar = Import(FromBar, Lang_CXX17);
+  EXPECT_TRUE(ToBar);
+}
+
 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

[compiler-rt] [clang] [clang-tools-extra] [llvm] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

[Teresa Johnson via cfe-commits]

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

LGTM other than a couple of minor comments and pending resolution of the LLVM 
IR test. Thanks!

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

[clang] [llvm] [RISCV] Bump zicfilp to 0.4 (PR #75134)

[Craig Topper via cfe-commits]

@@ -736,7 +736,7 @@ R"(All available -march extensions for RISC-V
 xventanacondops 1.0
 
 Experimental extensions
-zicfilp 0.2   This is a long dummy description
+zicfilp 0.4   This is a long dummy description

topperc wrote:

What does "This is a long dummy description" mean here?

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

[compiler-rt] [clang] [clang-tools-extra] [llvm] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

[Teresa Johnson via cfe-commits]

@@ -352,6 +366,8 @@ std::string getIRPGOFuncName(const Function , bool InLTO) 
{
   return getIRPGOObjectName(F, InLTO, getPGOFuncNameMetadata(F));
 }
 
+// DEPRECATED. Use `getIRPGOFuncName`for new code. See that function for

teresajohnson wrote:

In the header it is described as for FE instrumentation. Probably want the 
comments to be consistent?

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

[clang] [llvm] [CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (PR #67454)

[John McCall via cfe-commits]

@@ -232,110 +279,133 @@ class CGBuilderTy : public CGBuilderBaseTy {
   /// where i64 is actually the target word size.
   Address CreateConstGEP(Address Addr, uint64_t Index,
  const llvm::Twine  = "") {
+llvm::Type *ElTy = Addr.getElementType();
 const llvm::DataLayout  = BB->getParent()->getParent()->getDataLayout();
-CharUnits EltSize =
-CharUnits::fromQuantity(DL.getTypeAllocSize(Addr.getElementType()));
+CharUnits EltSize = CharUnits::fromQuantity(DL.getTypeAllocSize(ElTy));
 
-return Address(CreateGEP(Addr.getElementType(), Addr.getPointer(),
- getSize(Index), Name),
+return Address(CreateGEP(ElTy, Addr.getBasePointer(), getSize(Index), 
Name),
Addr.getElementType(),
-   Addr.getAlignment().alignmentAtOffset(Index * EltSize),
-   NotKnownNonNull);
+   Addr.getAlignment().alignmentAtOffset(Index * EltSize));
   }
 
   /// Create GEP with single dynamic index. The address alignment is reduced
   /// according to the element size.
   using CGBuilderBaseTy::CreateGEP;
-  Address CreateGEP(Address Addr, llvm::Value *Index,
+  Address CreateGEP(CodeGenFunction , Address Addr, llvm::Value *Index,
 const llvm::Twine  = "") {
 const llvm::DataLayout  = BB->getParent()->getParent()->getDataLayout();
 CharUnits EltSize =
 CharUnits::fromQuantity(DL.getTypeAllocSize(Addr.getElementType()));
 
 return Address(
-CreateGEP(Addr.getElementType(), Addr.getPointer(), Index, Name),
+CreateGEP(Addr.getElementType(), Addr.getRawPointer(CGF), Index, Name),
 Addr.getElementType(),
-Addr.getAlignment().alignmentOfArrayElement(EltSize), NotKnownNonNull);
+Addr.getAlignment().alignmentOfArrayElement(EltSize));
   }
 
   /// Given a pointer to i8, adjust it by a given constant offset.
   Address CreateConstInBoundsByteGEP(Address Addr, CharUnits Offset,
  const llvm::Twine  = "") {
 assert(Addr.getElementType() == TypeCache.Int8Ty);
-return Address(CreateInBoundsGEP(Addr.getElementType(), Addr.getPointer(),
- getSize(Offset), Name),
-   Addr.getElementType(),
-   Addr.getAlignment().alignmentAtOffset(Offset),
-   Addr.isKnownNonNull());
+return Address(
+CreateInBoundsGEP(Addr.getElementType(), Addr.getBasePointer(),
+  getSize(Offset), Name),
+Addr.getElementType(), Addr.getAlignment().alignmentAtOffset(Offset),
+Addr.isKnownNonNull());
   }
+
   Address CreateConstByteGEP(Address Addr, CharUnits Offset,
  const llvm::Twine  = "") {
 assert(Addr.getElementType() == TypeCache.Int8Ty);
-return Address(CreateGEP(Addr.getElementType(), Addr.getPointer(),
+return Address(CreateGEP(Addr.getElementType(), Addr.getBasePointer(),
  getSize(Offset), Name),
Addr.getElementType(),
-   Addr.getAlignment().alignmentAtOffset(Offset),
-   NotKnownNonNull);
+   Addr.getAlignment().alignmentAtOffset(Offset));
   }
 
   using CGBuilderBaseTy::CreateConstInBoundsGEP2_32;
   Address CreateConstInBoundsGEP2_32(Address Addr, unsigned Idx0, unsigned 
Idx1,
  const llvm::Twine  = "") {
-const llvm::DataLayout  = BB->getParent()->getParent()->getDataLayout();
+return createConstGEP2_32(Addr, Idx0, Idx1, Name);
+  }
 
-auto *GEP = cast(CreateConstInBoundsGEP2_32(
-Addr.getElementType(), Addr.getPointer(), Idx0, Idx1, Name));
-llvm::APInt Offset(
-DL.getIndexSizeInBits(Addr.getType()->getPointerAddressSpace()), 0,
-/*isSigned=*/true);
-if (!GEP->accumulateConstantOffset(DL, Offset))
-  llvm_unreachable("offset of GEP with constants is always computable");
-return Address(GEP, GEP->getResultElementType(),
-   Addr.getAlignment().alignmentAtOffset(
-   CharUnits::fromQuantity(Offset.getSExtValue())),
-   Addr.isKnownNonNull());
+  using CGBuilderBaseTy::CreateConstGEP2_32;
+  Address CreateConstGEP2_32(Address Addr, unsigned Idx0, unsigned Idx1,
+ const llvm::Twine  = "") {
+return createConstGEP2_32(Addr, Idx0, Idx1, Name);
+  }
+
+  Address CreateGEP(Address Addr, ArrayRef IdxList,
+llvm::Type *ElementType, CharUnits Align,
+const Twine  = "") {
+llvm::Value *Ptr = getRawPointerFromAddress(Addr);
+return RawAddress(CreateGEP(Addr.getElementType(), Ptr, IdxList, Name),
+  ElementType, Align);
+  }
+
+  using CGBuilderBaseTy::CreateInBoundsGEP;
+  Address CreateInBoundsGEP(Address Addr, ArrayRef IdxList,
+llvm::Type *ElementType, 

[clang] [llvm] [RISCV] Bump zicfilp to 0.4 (PR #75134)

[via cfe-commits]

llvmbot wrote:



@llvm/pr-subscribers-llvm-support

@llvm/pr-subscribers-clang

Author: Yeting Kuo (yetingk)


Changes

Bump to https://github.com/riscv/riscv-cfi/releases/tag/v0.4.0. Actually there 
is no functional change here.

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


6 Files Affected:

- (modified) clang/test/Preprocessor/riscv-target-features.c (+3-3) 
- (modified) llvm/docs/RISCVUsage.rst (+1-1) 
- (modified) llvm/lib/Support/RISCVISAInfo.cpp (+1-1) 
- (modified) llvm/test/CodeGen/RISCV/attributes.ll (+2-2) 
- (modified) llvm/test/MC/RISCV/attribute-arch.s (+2-2) 
- (modified) llvm/unittests/Support/RISCVISAInfoTest.cpp (+1-1) 


``diff
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 6fc921a8c6ee15..35208b2eae8fbd 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -1056,12 +1056,12 @@
 // CHECK-ZFBFMIN-EXT: __riscv_zfbfmin 8000{{$}}
 
 // RUN: %clang --target=riscv32 -menable-experimental-extensions \
-// RUN: -march=rv32i_zicfilp0p2 -x c -E -dM %s \
+// RUN: -march=rv32i_zicfilp0p4 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZICFILP-EXT %s
 // RUN: %clang --target=riscv64 -menable-experimental-extensions \
-// RUN: -march=rv64i_zicfilp0p2 -x c -E -dM %s \
+// RUN: -march=rv64i_zicfilp0p4 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZICFILP-EXT %s
-// CHECK-ZICFILP-EXT: __riscv_zicfilp 2000{{$}}
+// CHECK-ZICFILP-EXT: __riscv_zicfilp 4000{{$}}
 
 // RUN: %clang --target=riscv32 -menable-experimental-extensions \
 // RUN: -march=rv32i_zicond1p0 -x c -E -dM %s \
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 65dd0d83448ed1..842ebf45305952 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -197,7 +197,7 @@ The primary goal of experimental support is to assist in 
the process of ratifica
   LLVM implements assembler support for the `0.8.0 draft specification 
`_.
 
 ``experimental-zicfilp``
-  LLVM implements the `0.2 draft specification 
`__.
+  LLVM implements the `0.4 draft specification 
`__.
 
 ``experimental-zicond``
   LLVM implements the `1.0-rc1 draft specification 
`__.
diff --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 6322748430063c..85c34dd6206307 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -174,7 +174,7 @@ static const RISCVSupportedExtension 
SupportedExperimentalExtensions[] = {
 
 {"zfbfmin", RISCVExtensionVersion{0, 8}},
 
-{"zicfilp", RISCVExtensionVersion{0, 2}},
+{"zicfilp", RISCVExtensionVersion{0, 4}},
 {"zicond", RISCVExtensionVersion{1, 0}},
 
 {"ztso", RISCVExtensionVersion{0, 1}},
diff --git a/llvm/test/CodeGen/RISCV/attributes.ll 
b/llvm/test/CodeGen/RISCV/attributes.ll
index 030ae06af6d282..b34ccb3ff0f937 100644
--- a/llvm/test/CodeGen/RISCV/attributes.ll
+++ b/llvm/test/CodeGen/RISCV/attributes.ll
@@ -271,7 +271,7 @@
 ; RV32ZVFBFMIN: .attribute 5, 
"rv32i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvl32b1p0"
 ; RV32ZVFBFWMA: .attribute 5, 
"rv32i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvfbfwma0p8_zvl32b1p0"
 ; RV32ZACAS: .attribute 5, "rv32i2p1_a2p1_zacas1p0"
-; RV32ZICFILP: .attribute 5, "rv32i2p1_zicfilp0p2"
+; RV32ZICFILP: .attribute 5, "rv32i2p1_zicfilp0p4"
 
 ; RV64M: .attribute 5, "rv64i2p1_m2p0"
 ; RV64ZMMUL: .attribute 5, "rv64i2p1_zmmul1p0"
@@ -360,7 +360,7 @@
 ; RV64ZVFBFMIN: .attribute 5, 
"rv64i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvl32b1p0"
 ; RV64ZVFBFWMA: .attribute 5, 
"rv64i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvfbfwma0p8_zvl32b1p0"
 ; RV64ZACAS: .attribute 5, "rv64i2p1_a2p1_zacas1p0"
-; RV64ZICFILP: .attribute 5, "rv64i2p1_zicfilp0p2"
+; RV64ZICFILP: .attribute 5, "rv64i2p1_zicfilp0p4"
 
 define i32 @addi(i32 %a) {
   %1 = add i32 %a, 1
diff --git a/llvm/test/MC/RISCV/attribute-arch.s 
b/llvm/test/MC/RISCV/attribute-arch.s
index aa919f266592f4..3ed48401e43fc8 100644
--- a/llvm/test/MC/RISCV/attribute-arch.s
+++ b/llvm/test/MC/RISCV/attribute-arch.s
@@ -309,5 +309,5 @@
 .attribute arch, "rv32i_xcvbi"
 # CHECK: attribute  5, "rv32i2p1_xcvbi1p0"
 
-.attribute arch, "rv32i_zicfilp0p2"
-# CHECK: attribute  5, "rv32i2p1_zicfilp0p2"
+.attribute arch, "rv32i_zicfilp0p4"
+# CHECK: attribute  5, "rv32i2p1_zicfilp0p4"
diff --git a/llvm/unittests/Support/RISCVISAInfoTest.cpp 
b/llvm/unittests/Support/RISCVISAInfoTest.cpp
index 549964eed55518..3de14907899eb6 100644
--- a/llvm/unittests/Support/RISCVISAInfoTest.cpp
+++ b/llvm/unittests/Support/RISCVISAInfoTest.cpp
@@ -736,7 +736,7 @@ 

[clang] [llvm] [RISCV] Bump zicfilp to 0.4 (PR #75134)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-backend-risc-v

Author: Yeting Kuo (yetingk)


Changes

Bump to https://github.com/riscv/riscv-cfi/releases/tag/v0.4.0. Actually there 
is no functional change here.

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


6 Files Affected:

- (modified) clang/test/Preprocessor/riscv-target-features.c (+3-3) 
- (modified) llvm/docs/RISCVUsage.rst (+1-1) 
- (modified) llvm/lib/Support/RISCVISAInfo.cpp (+1-1) 
- (modified) llvm/test/CodeGen/RISCV/attributes.ll (+2-2) 
- (modified) llvm/test/MC/RISCV/attribute-arch.s (+2-2) 
- (modified) llvm/unittests/Support/RISCVISAInfoTest.cpp (+1-1) 


``diff
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 6fc921a8c6ee15..35208b2eae8fbd 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -1056,12 +1056,12 @@
 // CHECK-ZFBFMIN-EXT: __riscv_zfbfmin 8000{{$}}
 
 // RUN: %clang --target=riscv32 -menable-experimental-extensions \
-// RUN: -march=rv32i_zicfilp0p2 -x c -E -dM %s \
+// RUN: -march=rv32i_zicfilp0p4 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZICFILP-EXT %s
 // RUN: %clang --target=riscv64 -menable-experimental-extensions \
-// RUN: -march=rv64i_zicfilp0p2 -x c -E -dM %s \
+// RUN: -march=rv64i_zicfilp0p4 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZICFILP-EXT %s
-// CHECK-ZICFILP-EXT: __riscv_zicfilp 2000{{$}}
+// CHECK-ZICFILP-EXT: __riscv_zicfilp 4000{{$}}
 
 // RUN: %clang --target=riscv32 -menable-experimental-extensions \
 // RUN: -march=rv32i_zicond1p0 -x c -E -dM %s \
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 65dd0d83448ed1..842ebf45305952 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -197,7 +197,7 @@ The primary goal of experimental support is to assist in 
the process of ratifica
   LLVM implements assembler support for the `0.8.0 draft specification 
`_.
 
 ``experimental-zicfilp``
-  LLVM implements the `0.2 draft specification 
`__.
+  LLVM implements the `0.4 draft specification 
`__.
 
 ``experimental-zicond``
   LLVM implements the `1.0-rc1 draft specification 
`__.
diff --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 6322748430063c..85c34dd6206307 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -174,7 +174,7 @@ static const RISCVSupportedExtension 
SupportedExperimentalExtensions[] = {
 
 {"zfbfmin", RISCVExtensionVersion{0, 8}},
 
-{"zicfilp", RISCVExtensionVersion{0, 2}},
+{"zicfilp", RISCVExtensionVersion{0, 4}},
 {"zicond", RISCVExtensionVersion{1, 0}},
 
 {"ztso", RISCVExtensionVersion{0, 1}},
diff --git a/llvm/test/CodeGen/RISCV/attributes.ll 
b/llvm/test/CodeGen/RISCV/attributes.ll
index 030ae06af6d282..b34ccb3ff0f937 100644
--- a/llvm/test/CodeGen/RISCV/attributes.ll
+++ b/llvm/test/CodeGen/RISCV/attributes.ll
@@ -271,7 +271,7 @@
 ; RV32ZVFBFMIN: .attribute 5, 
"rv32i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvl32b1p0"
 ; RV32ZVFBFWMA: .attribute 5, 
"rv32i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvfbfwma0p8_zvl32b1p0"
 ; RV32ZACAS: .attribute 5, "rv32i2p1_a2p1_zacas1p0"
-; RV32ZICFILP: .attribute 5, "rv32i2p1_zicfilp0p2"
+; RV32ZICFILP: .attribute 5, "rv32i2p1_zicfilp0p4"
 
 ; RV64M: .attribute 5, "rv64i2p1_m2p0"
 ; RV64ZMMUL: .attribute 5, "rv64i2p1_zmmul1p0"
@@ -360,7 +360,7 @@
 ; RV64ZVFBFMIN: .attribute 5, 
"rv64i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvl32b1p0"
 ; RV64ZVFBFWMA: .attribute 5, 
"rv64i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvfbfwma0p8_zvl32b1p0"
 ; RV64ZACAS: .attribute 5, "rv64i2p1_a2p1_zacas1p0"
-; RV64ZICFILP: .attribute 5, "rv64i2p1_zicfilp0p2"
+; RV64ZICFILP: .attribute 5, "rv64i2p1_zicfilp0p4"
 
 define i32 @addi(i32 %a) {
   %1 = add i32 %a, 1
diff --git a/llvm/test/MC/RISCV/attribute-arch.s 
b/llvm/test/MC/RISCV/attribute-arch.s
index aa919f266592f4..3ed48401e43fc8 100644
--- a/llvm/test/MC/RISCV/attribute-arch.s
+++ b/llvm/test/MC/RISCV/attribute-arch.s
@@ -309,5 +309,5 @@
 .attribute arch, "rv32i_xcvbi"
 # CHECK: attribute  5, "rv32i2p1_xcvbi1p0"
 
-.attribute arch, "rv32i_zicfilp0p2"
-# CHECK: attribute  5, "rv32i2p1_zicfilp0p2"
+.attribute arch, "rv32i_zicfilp0p4"
+# CHECK: attribute  5, "rv32i2p1_zicfilp0p4"
diff --git a/llvm/unittests/Support/RISCVISAInfoTest.cpp 
b/llvm/unittests/Support/RISCVISAInfoTest.cpp
index 549964eed55518..3de14907899eb6 100644
--- a/llvm/unittests/Support/RISCVISAInfoTest.cpp
+++ b/llvm/unittests/Support/RISCVISAInfoTest.cpp
@@ -736,7 +736,7 @@ R"(All available -march 

[llvm] [clang] [RISCV] Bump zicfilp to 0.4 (PR #75134)

[Yeting Kuo via cfe-commits]

https://github.com/yetingk created 
https://github.com/llvm/llvm-project/pull/75134

Bump to https://github.com/riscv/riscv-cfi/releases/tag/v0.4.0. Actually there 
is no functional change here.

>From ec87b87a67acdcb8faedec327e0938476ddb0893 Mon Sep 17 00:00:00 2001
From: Yeting Kuo 
Date: Tue, 12 Dec 2023 11:46:17 +0800
Subject: [PATCH] [RISCV] Bump zicfilp to 0.4

---
 clang/test/Preprocessor/riscv-target-features.c | 6 +++---
 llvm/docs/RISCVUsage.rst| 2 +-
 llvm/lib/Support/RISCVISAInfo.cpp   | 2 +-
 llvm/test/CodeGen/RISCV/attributes.ll   | 4 ++--
 llvm/test/MC/RISCV/attribute-arch.s | 4 ++--
 llvm/unittests/Support/RISCVISAInfoTest.cpp | 2 +-
 6 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 6fc921a8c6ee15..35208b2eae8fbd 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -1056,12 +1056,12 @@
 // CHECK-ZFBFMIN-EXT: __riscv_zfbfmin 8000{{$}}
 
 // RUN: %clang --target=riscv32 -menable-experimental-extensions \
-// RUN: -march=rv32i_zicfilp0p2 -x c -E -dM %s \
+// RUN: -march=rv32i_zicfilp0p4 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZICFILP-EXT %s
 // RUN: %clang --target=riscv64 -menable-experimental-extensions \
-// RUN: -march=rv64i_zicfilp0p2 -x c -E -dM %s \
+// RUN: -march=rv64i_zicfilp0p4 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZICFILP-EXT %s
-// CHECK-ZICFILP-EXT: __riscv_zicfilp 2000{{$}}
+// CHECK-ZICFILP-EXT: __riscv_zicfilp 4000{{$}}
 
 // RUN: %clang --target=riscv32 -menable-experimental-extensions \
 // RUN: -march=rv32i_zicond1p0 -x c -E -dM %s \
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 65dd0d83448ed1..842ebf45305952 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -197,7 +197,7 @@ The primary goal of experimental support is to assist in 
the process of ratifica
   LLVM implements assembler support for the `0.8.0 draft specification 
`_.
 
 ``experimental-zicfilp``
-  LLVM implements the `0.2 draft specification 
`__.
+  LLVM implements the `0.4 draft specification 
`__.
 
 ``experimental-zicond``
   LLVM implements the `1.0-rc1 draft specification 
`__.
diff --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 6322748430063c..85c34dd6206307 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -174,7 +174,7 @@ static const RISCVSupportedExtension 
SupportedExperimentalExtensions[] = {
 
 {"zfbfmin", RISCVExtensionVersion{0, 8}},
 
-{"zicfilp", RISCVExtensionVersion{0, 2}},
+{"zicfilp", RISCVExtensionVersion{0, 4}},
 {"zicond", RISCVExtensionVersion{1, 0}},
 
 {"ztso", RISCVExtensionVersion{0, 1}},
diff --git a/llvm/test/CodeGen/RISCV/attributes.ll 
b/llvm/test/CodeGen/RISCV/attributes.ll
index 030ae06af6d282..b34ccb3ff0f937 100644
--- a/llvm/test/CodeGen/RISCV/attributes.ll
+++ b/llvm/test/CodeGen/RISCV/attributes.ll
@@ -271,7 +271,7 @@
 ; RV32ZVFBFMIN: .attribute 5, 
"rv32i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvl32b1p0"
 ; RV32ZVFBFWMA: .attribute 5, 
"rv32i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvfbfwma0p8_zvl32b1p0"
 ; RV32ZACAS: .attribute 5, "rv32i2p1_a2p1_zacas1p0"
-; RV32ZICFILP: .attribute 5, "rv32i2p1_zicfilp0p2"
+; RV32ZICFILP: .attribute 5, "rv32i2p1_zicfilp0p4"
 
 ; RV64M: .attribute 5, "rv64i2p1_m2p0"
 ; RV64ZMMUL: .attribute 5, "rv64i2p1_zmmul1p0"
@@ -360,7 +360,7 @@
 ; RV64ZVFBFMIN: .attribute 5, 
"rv64i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvl32b1p0"
 ; RV64ZVFBFWMA: .attribute 5, 
"rv64i2p1_f2p2_zicsr2p0_zfbfmin0p8_zve32f1p0_zve32x1p0_zvfbfmin0p8_zvfbfwma0p8_zvl32b1p0"
 ; RV64ZACAS: .attribute 5, "rv64i2p1_a2p1_zacas1p0"
-; RV64ZICFILP: .attribute 5, "rv64i2p1_zicfilp0p2"
+; RV64ZICFILP: .attribute 5, "rv64i2p1_zicfilp0p4"
 
 define i32 @addi(i32 %a) {
   %1 = add i32 %a, 1
diff --git a/llvm/test/MC/RISCV/attribute-arch.s 
b/llvm/test/MC/RISCV/attribute-arch.s
index aa919f266592f4..3ed48401e43fc8 100644
--- a/llvm/test/MC/RISCV/attribute-arch.s
+++ b/llvm/test/MC/RISCV/attribute-arch.s
@@ -309,5 +309,5 @@
 .attribute arch, "rv32i_xcvbi"
 # CHECK: attribute  5, "rv32i2p1_xcvbi1p0"
 
-.attribute arch, "rv32i_zicfilp0p2"
-# CHECK: attribute  5, "rv32i2p1_zicfilp0p2"
+.attribute arch, "rv32i_zicfilp0p4"
+# CHECK: attribute  5, "rv32i2p1_zicfilp0p4"
diff --git a/llvm/unittests/Support/RISCVISAInfoTest.cpp 
b/llvm/unittests/Support/RISCVISAInfoTest.cpp
index 549964eed55518..3de14907899eb6 100644
--- 

[compiler-rt] [clang-tools-extra] [clang] [llvm] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

[Teresa Johnson via cfe-commits]

@@ -0,0 +1,115 @@
+// This is a regression test for ThinLTO indirect-call-promotion when candidate
+// callees need to be imported from another IR module.  In the C++ test case,
+// `main` calls `global_func` which is defined in another module. `global_func`
+// has two indirect callees, one has external linkage and one has local 
linkage.
+// All three functions should be imported into the IR module of main.
+
+// What the test does:
+// - Generate raw profiles from executables and convert it to indexed profiles.
+//   During the conversion, a profiled callee address in raw profiles will be
+//   converted to function hash in indexed profiles.
+// - Run IRPGO profile use and ThinTLO prelink pipeline and get LLVM bitcodes
+//   for both cpp files in the C++ test case.
+// - Generate ThinLTO summary file with LLVM bitcodes, and run 
`function-import` pass.
+// - Run `pgo-icall-prom` pass for the IR module which needs to import callees.
+
+// Use lld as linker for more robust test. We need to REQUIRE LLVMgold.so for
+// LTO if default linker is GNU ld or gold anyway.
+// REQUIRES: lld-available
+
+// Test should fail where linkage-name and mangled-name diverges, see issue 
https://github.com/llvm/llvm-project/issues/74565).
+// Currently, this name divergence happens on Mach-O object file format, or on
+// many (but not all) 32-bit Windows systems.
+//
+// XFAIL: system-darwin
+//
+// Mark 32-bit Windows as UNSUPPORTED for now as opposed to XFAIL. This test
+// should fail on many (but not all) 32-bit Windows systems and succeed on the
+// rest. The flexibility in triple string parsing makes it tricky to capture
+// both sets accurately. i[3-9]86 specifies arch as Triple::ArchType::x86, 
(win32|windows)
+// specifies OS as Triple::OS::Win32
+//
+// UNSUPPORTED: target={{i[3-9]86-.*-(win32|windows).*}}
+
+// RUN: rm -rf %t && split-file %s %t && cd %t
+
+// Do setup work for all below tests.
+// Generate raw profiles from real programs and convert it into indexed 
profiles.
+// Use clangxx_pgogen for IR level instrumentation for C++.
+// RUN: %clangxx_pgogen -fuse-ld=lld -O2 lib.cpp main.cpp -o main
+// RUN: env LLVM_PROFILE_FILE=main.profraw %run ./main
+// RUN: llvm-profdata merge main.profraw -o main.profdata
+
+// Use profile on lib and get bitcode, test that local function callee0 has
+// expected !PGOFuncName metadata and external function callee1 doesn't have
+// !PGOFuncName metadata. Explicitly skip ICP pass to test ICP happens as
+// expected in the IR module that imports functions from lib.
+// RUN: %clang -mllvm -disable-icp -fprofile-use=main.profdata -flto=thin -O2 
-c lib.cpp -o lib.bc
+// RUN: llvm-dis lib.bc -o - | FileCheck %s --check-prefix=PGOName
+
+// Use profile on main and get bitcode.
+// RUN: %clang -fprofile-use=main.profdata -flto=thin -O2 -c main.cpp -o 
main.bc
+
+// Run llvm-lto to get summary file.
+// RUN: llvm-lto -thinlto -o summary main.bc lib.bc
+
+// Test the imports of functions. Default import thresholds would work but do
+// explicit override to be more futureproof. Note all functions have one basic
+// block with a function-entry-count of one, so they are actually hot functions
+// per default profile summary hotness cutoff.
+// RUN: opt -passes=function-import -import-instr-limit=100 
-import-cold-multiplier=1 -summary-file summary.thinlto.bc main.bc -o 
main.import.bc -print-imports 2>&1 | FileCheck %s --check-prefix=IMPORTS
+// Test that '_Z11global_funcv' has indirect calls annotated with value 
profiles.
+// RUN: llvm-dis main.import.bc -o - | FileCheck %s --check-prefix=IR
+
+// Test that both candidates are ICP'ed and there is no `!VP` in the IR.
+// RUN: opt main.import.bc -icp-lto -passes=pgo-icall-prom -S 
-pass-remarks=pgo-icall-prom 2>&1 | FileCheck %s 
--check-prefixes=ICP-IR,ICP-REMARK --implicit-check-not="!VP"
+
+// IMPORTS: main.cpp: Import _Z7callee1v
+// IMPORTS: main.cpp: Import _ZL7callee0v.llvm.[[#]]
+// IMPORTS: main.cpp: Import _Z11global_funcv
+
+// PGOName: define dso_local void @_Z7callee1v() {{.*}} !prof ![[#]] {
+// PGOName: define internal void @_ZL7callee0v() {{.*}} !prof ![[#]] 
!PGOFuncName ![[#MD:]] {
+// PGOName: ![[#MD]] = !{!"{{.*}}lib.cpp;_ZL7callee0v"}
+
+// IR-LABEL: define available_externally {{.*}} void @_Z11global_funcv() 
{{.*}} !prof ![[#]] {
+// IR-NEXT: entry:
+// IR-NEXT:  %0 = load ptr, ptr @calleeAddrs
+// IR-NEXT:  tail call void %0(), !prof ![[#PROF1:]]
+// IR-NEXT:  %1 = load ptr, ptr getelementptr inbounds ([2 x ptr], ptr 
@calleeAddrs,
+// IR-NEXT:  tail call void %1(), !prof ![[#PROF2:]]
+
+// The GUID of indirect callee is the MD5 hash of 
`/path/to/lib.cpp:_ZL7callee0v`

teresajohnson wrote:

should this have the semicolon separator not a colon?

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

[compiler-rt] [clang-tools-extra] [clang] [llvm] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

[Teresa Johnson via cfe-commits]

@@ -1,39 +0,0 @@
-; Do setup work for all below tests: generate bitcode and combined index

teresajohnson wrote:

Without use of the raw profile, this test would not have caught the regression. 
If we think the new compiler-rt test is enough to catch this case in the 
future, then perhaps we don't need this LLVM test at all (there should already 
be some ICP tests). But if the compiler-rt test is not enough, because some 
people don't run those, then this should stay and use a raw profile as input.

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

[clang] [clang] Add per-global code model attribute (PR #72078)

[Fangrui Song via cfe-commits]

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

[clang] [clang] Add per-global code model attribute (PR #72078)

[Fangrui Song via cfe-commits]

@@ -4841,6 +4841,19 @@ CodeGenModule::GetOrCreateLLVMGlobal(StringRef 
MangledName, llvm::Type *Ty,
 isExternallyVisible(D->getLinkageAndVisibility().getLinkage()))
   GV->setSection(".cp.rodata");
 
+// Handle code model attribute
+if (D->hasAttr()) {
+  if (const CodeModelAttr *CMA = D->getAttr()) {

MaskRay wrote:

`const auto *`

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

[clang] [clang] Add per-global code model attribute (PR #72078)

[Fangrui Song via cfe-commits]

@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 -emit-llvm -triple loongarch64 %s -o - | FileCheck %s
+
+// CHECK: @_ZL2v1 ={{.*}} global i32 0, code_model "small"
+static int v1 __attribute__((model("normal")));
+
+void use1() {
+  v1 = 1;
+}
+
+// CHECK: @v2 ={{.*}} global i32 0, code_model "medium"
+int v2 __attribute__((model("medium")));
+
+// CHECK: @v3 ={{.*}} global float 0.00e+00, code_model "large"
+float v3 __attribute__((model("extreme")));
+
+// CHECK: @_ZL2v4IiE ={{.*}} global i32 0, code_model "medium"
+template 
+static T v4 __attribute__((model("medium")));
+
+void use2() {
+  v4 = 1;
+}
+
+// CHECK: @v5 ={{.*}} global i32 0, code_model "large"
+thread_local int v5 __attribute__((model("extreme")));

MaskRay wrote:

Should this be an error? (if so, test it in `test/Sema{,CXX}`)

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

[clang] [Sema] atomic_compare_exchange: check failure memory order (PR #74959)

[Fangrui Song via cfe-commits]

MaskRay wrote:

> PR description needs to be updated after changes. Otherwise LGTM.

Thanks. Updated the description.

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

[clang] [Sema] atomic_compare_exchange: check failure memory order (PR #74959)

[Fangrui Song via cfe-commits]

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

[clang] [Sema] atomic_compare_exchange: check failure memory order (PR #74959)

[James Y Knight via cfe-commits]

jyknight wrote:

PR description needs to be updated after changes. Otherwise LGTM.

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

[llvm] [clang] [CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (PR #67454)

[Akira Hatanaka via cfe-commits]

@@ -232,19 +232,19 @@ static Value *MakeBinaryAtomicValue(
 
 static Value *EmitNontemporalStore(CodeGenFunction , const CallExpr *E) {
   Value *Val = CGF.EmitScalarExpr(E->getArg(0));
-  Value *Address = CGF.EmitScalarExpr(E->getArg(1));
+  Address Addr = CGF.EmitPointerWithAlignment(E->getArg(1));
 
   Val = CGF.EmitToMemory(Val, E->getArg(0)->getType());
-  LValue LV = CGF.MakeNaturalAlignAddrLValue(Address, E->getArg(0)->getType());
+  LValue LV = CGF.MakeAddrLValue(Addr, E->getArg(0)->getType());
   LV.setNontemporal(true);
   CGF.EmitStoreOfScalar(Val, LV, false);
   return nullptr;
 }
 
 static Value *EmitNontemporalLoad(CodeGenFunction , const CallExpr *E) {
-  Value *Address = CGF.EmitScalarExpr(E->getArg(0));
+  Address Addr = CGF.EmitPointerWithAlignment(E->getArg(0));
 
-  LValue LV = CGF.MakeNaturalAlignAddrLValue(Address, E->getType());
+  LValue LV = CGF.MakeAddrLValue(Addr, E->getType());

ahatanak wrote:

My thinking was that the call to `EmitPointerWithAlignment`, which sets `Addr`, 
would compute the correct alignment.

Do you have an example that shows the alignment is lower after this change?

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

[clang] [clang] Fix logic in APValue::LValueBase::getType() (PR #75131)

[Chenyang Gao via cfe-commits]

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

[clang] [clang] Fix logic in APValue::LValueBase::getType() (PR #75131)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Chenyang Gao (cygao90)


Changes

See #69468.

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


1 Files Affected:

- (modified) clang/lib/AST/APValue.cpp (+3-1) 


``diff
diff --git a/clang/lib/AST/APValue.cpp b/clang/lib/AST/APValue.cpp
index 4eae308ef5b34c..648540c42b3e75 100644
--- a/clang/lib/AST/APValue.cpp
+++ b/clang/lib/AST/APValue.cpp
@@ -70,8 +70,10 @@ QualType APValue::LValueBase::getType() const {
 // constexpr int *p = [1]; // valid?
 //
 // For now, we take the most complete type we can find.
-for (auto *Redecl = cast(D->getMostRecentDecl()); Redecl;
+for (auto *Redecl = cast(D->getMostRecentDecl());
+ Redecl && !Redecl->isInvalidDecl();
  Redecl = cast_or_null(Redecl->getPreviousDecl())) {
+  D = Redecl;
   QualType T = Redecl->getType();
   if (!T->isIncompleteArrayType())
 return T;

``




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

[clang] [Clang][AST] Fix crash in APValue::LValueBase::getType when we have invalid decl (PR #75130)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Shafik Yaghmour (shafik)


Changes

In some cases when calling APValue::LValueBase::getType() when we have a 
ValueDecl in some cases we don't handle invalid decls. We iterating over 
redeclarations we reset the current decl to the current most recent decl and we 
check the next redeclaration to ensure it is not invalid.

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

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


2 Files Affected:

- (modified) clang/lib/AST/APValue.cpp (+3-1) 
- (added) clang/test/AST/gh69468.cpp (+14) 


``diff
diff --git a/clang/lib/AST/APValue.cpp b/clang/lib/AST/APValue.cpp
index 4eae308ef5b34..2ccd83a1d4823 100644
--- a/clang/lib/AST/APValue.cpp
+++ b/clang/lib/AST/APValue.cpp
@@ -70,11 +70,13 @@ QualType APValue::LValueBase::getType() const {
 // constexpr int *p = [1]; // valid?
 //
 // For now, we take the most complete type we can find.
-for (auto *Redecl = cast(D->getMostRecentDecl()); Redecl;
+for (auto *Redecl = cast(D->getMostRecentDecl());
+ Redecl && !Redecl->isInvalidDecl();
  Redecl = cast_or_null(Redecl->getPreviousDecl())) {
   QualType T = Redecl->getType();
   if (!T->isIncompleteArrayType())
 return T;
+  D = Redecl;
 }
 return D->getType();
   }
diff --git a/clang/test/AST/gh69468.cpp b/clang/test/AST/gh69468.cpp
new file mode 100644
index 0..8c93fa5e828ac
--- /dev/null
+++ b/clang/test/AST/gh69468.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -verify %s
+
+
+a[i] = b[i]; // expected-error {{use of undeclared identifier 'i'}} \
+ // expected-error {{a type specifier is required for all 
declarations}} \
+// expected-error {{use of undeclared identifier 'b'}} \
+// expected-error {{use of undeclared identifier 'i'}}
+extern char b[];
+extern char a[];
+
+void foo(int j) {
+  // This used to crash here
+  a[j] = b[j];
+}

``




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

[clang] [clang] Fix logic in APValue::LValueBase::getType() (PR #75131)

[Chenyang Gao via cfe-commits]

https://github.com/cygao90 created 
https://github.com/llvm/llvm-project/pull/75131

See #69468.

>From ffc9b634427a117cacfd06d9247fdb98cb6bbb30 Mon Sep 17 00:00:00 2001
From: Chenyang Gao 
Date: Tue, 12 Dec 2023 03:22:31 +0800
Subject: [PATCH] [clang] Fix logic in APValue::LValueBase::getType()

---
 clang/lib/AST/APValue.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/clang/lib/AST/APValue.cpp b/clang/lib/AST/APValue.cpp
index 4eae308ef5b34c..648540c42b3e75 100644
--- a/clang/lib/AST/APValue.cpp
+++ b/clang/lib/AST/APValue.cpp
@@ -70,8 +70,10 @@ QualType APValue::LValueBase::getType() const {
 // constexpr int *p = [1]; // valid?
 //
 // For now, we take the most complete type we can find.
-for (auto *Redecl = cast(D->getMostRecentDecl()); Redecl;
+for (auto *Redecl = cast(D->getMostRecentDecl());
+ Redecl && !Redecl->isInvalidDecl();
  Redecl = cast_or_null(Redecl->getPreviousDecl())) {
+  D = Redecl;
   QualType T = Redecl->getType();
   if (!T->isIncompleteArrayType())
 return T;

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

[clang] [Clang][AST] Fix crash in APValue::LValueBase::getType when we have invalid decl (PR #75130)

[Shafik Yaghmour via cfe-commits]

https://github.com/shafik created 
https://github.com/llvm/llvm-project/pull/75130

In some cases when calling APValue::LValueBase::getType() when we have a 
ValueDecl in some cases we don't handle invalid decls. We iterating over 
redeclarations we reset the current decl to the current most recent decl and we 
check the next redeclaration to ensure it is not invalid.

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

>From 6e056bed30a15a0b7b657f10500ef69196f5366b Mon Sep 17 00:00:00 2001
From: Shafik Yaghmour 
Date: Mon, 11 Dec 2023 18:35:57 -0800
Subject: [PATCH] [Clang][AST] Fix crash in APValue::LValueBase::getType when
 we have invalid decl

In some cases when calling APValue::LValueBase::getType() when we have a
ValueDecl in some cases we don't handle invalid decls. We iterating over
redeclarations we reset the current decl to the current most recent decl and
we check the next redeclaration to ensure it is not invalid.

Fixes: https://github.com/llvm/llvm-project/issues/69468
---
 clang/lib/AST/APValue.cpp  |  4 +++-
 clang/test/AST/gh69468.cpp | 14 ++
 2 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 clang/test/AST/gh69468.cpp

diff --git a/clang/lib/AST/APValue.cpp b/clang/lib/AST/APValue.cpp
index 4eae308ef5b34c..2ccd83a1d4823d 100644
--- a/clang/lib/AST/APValue.cpp
+++ b/clang/lib/AST/APValue.cpp
@@ -70,11 +70,13 @@ QualType APValue::LValueBase::getType() const {
 // constexpr int *p = [1]; // valid?
 //
 // For now, we take the most complete type we can find.
-for (auto *Redecl = cast(D->getMostRecentDecl()); Redecl;
+for (auto *Redecl = cast(D->getMostRecentDecl());
+ Redecl && !Redecl->isInvalidDecl();
  Redecl = cast_or_null(Redecl->getPreviousDecl())) {
   QualType T = Redecl->getType();
   if (!T->isIncompleteArrayType())
 return T;
+  D = Redecl;
 }
 return D->getType();
   }
diff --git a/clang/test/AST/gh69468.cpp b/clang/test/AST/gh69468.cpp
new file mode 100644
index 00..8c93fa5e828ac7
--- /dev/null
+++ b/clang/test/AST/gh69468.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -verify %s
+
+
+a[i] = b[i]; // expected-error {{use of undeclared identifier 'i'}} \
+ // expected-error {{a type specifier is required for all 
declarations}} \
+// expected-error {{use of undeclared identifier 'b'}} \
+// expected-error {{use of undeclared identifier 'i'}}
+extern char b[];
+extern char a[];
+
+void foo(int j) {
+  // This used to crash here
+  a[j] = b[j];
+}

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

[clang] [llvm] [compiler-rt] [clang-tools-extra] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

[Fangrui Song via cfe-commits]

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

[clang-tools-extra] [clangd] Add test for GH75115 (PR #75116)

[Matheus Izvekov via cfe-commits]

https://github.com/mizvekov updated 
https://github.com/llvm/llvm-project/pull/75116

>From 7c18785d74556001cf19d9ae84c8f32f8d95801e Mon Sep 17 00:00:00 2001
From: Matheus Izvekov 
Date: Mon, 11 Dec 2023 17:36:44 -0300
Subject: [PATCH] [clangd] Add test for GH75115

Add test for https://github.com/llvm/llvm-project/issues/75115
---
 clang-tools-extra/clangd/test/GH75115.test | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 clang-tools-extra/clangd/test/GH75115.test

diff --git a/clang-tools-extra/clangd/test/GH75115.test 
b/clang-tools-extra/clangd/test/GH75115.test
new file mode 100644
index 00..030392f1d69b30
--- /dev/null
+++ b/clang-tools-extra/clangd/test/GH75115.test
@@ -0,0 +1,12 @@
+// RUN: rm -rf %t.dir && mkdir -p %t.dir
+// RUN: echo '[{"directory": "%/t.dir", "command": "clang 
--target=x86_64-pc-windows-msvc -x c GH75115.test", "file": "GH75115.test"}]' > 
%t.dir/compile_commands.json
+// RUN: not --crash clangd -enable-config=0 --compile-commands-dir=%t.dir 
-check=%s 2>&1 | FileCheck -strict-whitespace %s
+
+// FIXME: Crashes
+
+// CHECK: Building preamble...
+// CHECK-NEXT: Built preamble
+// CHECK-NEXT: Indexing headers...
+// CHECK-NEXT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, 
TombstoneKey) && "Empty/Tombstone value shouldn't be inserted into map!"
+
+#define assert

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

[clang] [clang-tools-extra] [llvm] [compiler-rt] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

[Fangrui Song via cfe-commits]

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

LGTM once these changes are made.

* unused `%clangxx_pgouse=`
* profraw => proftext for the PGOProfile test
* lld-available -fuse-ld=lld and windows triple simplification for the 
compiler-rt test

It seems useful to wait for others' opinions as well.

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

[clang] [clang-tools-extra] [llvm] [compiler-rt] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

[Fangrui Song via cfe-commits]

@@ -0,0 +1,97 @@
+// This is a regression test for ThinLTO indirect-call-promotion when candidate
+// callees need to be imported from another IR module.  In the C++ test case,
+// `main` calls `global_func` which is defined in another module. `global_func`
+// has two indirect callees, one has external linkage and one has local 
linkage.
+// All three functions should be imported into the IR module of main.
+
+// What the test does:
+// - Generate raw profiles from executables and convert it to indexed profiles.
+//   During the conversion, a profiled callee address in raw profiles will be
+//   converted to function hash in indexed profiles.
+// - Run IRPGO profile use and ThinTLO prelink pipeline and get LLVM bitcodes
+//   for both cpp files in the C++ test case.
+// - Generate ThinLTO summary file with LLVM bitcodes, and run 
`function-import` pass.
+// - Run `pgo-icall-prom` pass for the IR module which needs to import callees.
+
+// RUN: rm -rf %t && split-file %s %t && cd %t
+
+// Use clang*_{pgogen,pgouse} for IR level instrumentation, and use clangxx* 
for
+// C++.
+//
+// Do setup work for all below tests.
+// Generate raw profiles from real programs and convert it into indexed 
profiles.
+// RUN: %clangxx_pgogen -fuse-ld=lld -O2 lib.cpp main.cpp -o main
+// RUN: env LLVM_PROFILE_FILE=main.profraw %run ./main
+// RUN: llvm-profdata merge main.profraw -o main.profdata
+
+// Use profile on lib and get bitcode, test that local function callee0 has
+// expected !PGOFuncName metadata and external function callee1 doesn't have
+// !PGOFuncName metadata. Explicitly skip ICP pass to test ICP happens as
+// expected in the IR module that imports functions from lib.
+// RUN: %clang -target x86_64-unknown-linux-gnu -mllvm -disable-icp 
-fprofile-use=main.profdata -flto=thin -O2 -c lib.cpp -o lib.bc

MaskRay wrote:

To match 32-bit Windows triples, `i.86.*windows` suffices. The normalized 
triples don't use `win32`.

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

[clang] [clang-tools-extra] [llvm] [compiler-rt] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

[Fangrui Song via cfe-commits]

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

[clang] [clang-tools-extra] [llvm] [compiler-rt] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

[Fangrui Song via cfe-commits]

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

[clang] [clang-tools-extra] [llvm] [compiler-rt] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

[Fangrui Song via cfe-commits]

@@ -1,39 +0,0 @@
-; Do setup work for all below tests: generate bitcode and combined index

MaskRay wrote:

It looks like that we had 3 precanned profraw files and this patch is adding 
another one. Since the raw profile isn't stable, this is going to add some 
inconvenience whenever the version is bumped.
`thinlto_indirect_call_promotion.profraw` probably should be rewritten as 
`.proftext` and `llvm-profdata merge`
```
% fd -e profraw
Transforms/PGOProfile/Inputs/thinlto_indirect_call_promotion.profraw
tools/llvm-profdata/Inputs/basic.profraw
tools/llvm-profdata/Inputs/compressed.profraw
tools/llvm-profdata/Inputs/c-general.profraw
```

It seems that there is an earlier comment that proftext may not cover the use 
case well, so we also utilize a runtime test in `compiler-rt/test`.

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

[clang] [clang] Add size filter for stack auto init (PR #74777)

[Vitaly Buka via cfe-commits]

@@ -1759,20 +1759,29 @@ void 
CodeGenFunction::emitZeroOrPatternForAutoVarInit(QualType type,
   const VarDecl ,
   Address Loc) {
   auto trivialAutoVarInit = getContext().getLangOpts().getTrivialAutoVarInit();
+  auto trivialAutoVarInitSizeBound =
+  getContext().getLangOpts().TrivialAutoVarInitSizeBound;
   CharUnits Size = getContext().getTypeSizeInChars(type);
   bool isVolatile = type.isVolatileQualified();
   if (!Size.isZero()) {
+auto allocSize = 
CGM.getDataLayout().getTypeAllocSize(Loc.getElementType());

vitalybuka wrote:

After second thought 
what if we have a large array of structs with a few uninitialized fields.
Initializing the rest will cost us anyway about the same.

Would it be better to check insize of 
`emitStoresForZeroInit`/`emitStoresForPatternInit`, more precicely in 
`emitStoresForConstant` before memset if IsAutoInit? 


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