[clang] clang-format: Add IncludeSortKey option (PR #137840)
https://github.com/DaanDeMeyer updated
https://github.com/llvm/llvm-project/pull/137840
>From 06b9d2dffe560eedb28f15630252d361b881c71f Mon Sep 17 00:00:00 2001
From: Daan De Meyer
Date: Tue, 29 Apr 2025 18:26:36 +0200
Subject: [PATCH] clang-format: Add IgnoreExtension option to
SortIncludesOptions
Sorting without taking the file extension into account gives nicer results
when various header file names are substrings of other header file names,
for example, a CLI application with a main header named analyze.h and a
analyze-xxx.h header for each subcommand currently will always put analyze.h
last after all the analyze-xxx.h headers, but putting analyze.h first instead
of last is arguable nicer to read.
TLDR; Instead of
"""
/#include "analyze-blame.h"
/#include "analyze.h"
"""
You'd get
"""
/#include "analyze.h"
/#include "analyze-blame.h"
"""
Let's allow sorting without taking the file extension into account unless two
headers otherwise compare equal by introducing a new boolean option
IgnoreExtension
for SortIncludesOptions.
---
clang/docs/ClangFormatStyleOptions.rst | 10 +
clang/include/clang/Format/Format.h | 12 +-
clang/lib/Format/Format.cpp | 45 +
clang/unittests/Format/ConfigParseTest.cpp | 7 ++--
clang/unittests/Format/SortIncludesTest.cpp | 20 +
5 files changed, 74 insertions(+), 20 deletions(-)
diff --git a/clang/docs/ClangFormatStyleOptions.rst
b/clang/docs/ClangFormatStyleOptions.rst
index 0e21ef0244f78..d662ab1404a91 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -6015,6 +6015,16 @@ the configuration (without a prefix: ``Auto``).
#include "B/A.h" #include "B/a.h"
#include "B/a.h" #include "a/b.h"
+ * ``bool IgnoreExtension`` When sorting includes in each block, only take
file extensions into
+account if two includes compare equal otherwise.
+
+.. code-block:: c++
+
+ true: false:
+ # include "A.h" vs.# include "A-util.h"
+ # include "A.inc" # include "A.h"
+ # include "A-util.h" # include "A.inc"
+
.. _SortJavaStaticImport:
diff --git a/clang/include/clang/Format/Format.h
b/clang/include/clang/Format/Format.h
index b4f2a87fe7e83..70406d06d48c6 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -4385,8 +4385,18 @@ struct FormatStyle {
///#include "B/a.h" #include "a/b.h"
/// \endcode
bool IgnoreCase;
+/// When sorting includes in each block, only take file extensions into
+/// account if two includes compare equal otherwise.
+/// \code
+///true: false:
+///# include "A.h" vs.# include "A-util.h"
+///# include "A.inc" # include "A.h"
+///# include "A-util.h" # include "A.inc"
+/// \endcode
+bool IgnoreExtension;
bool operator==(const SortIncludesOptions &R) const {
- return Enabled == R.Enabled && IgnoreCase == R.IgnoreCase;
+ return Enabled == R.Enabled && IgnoreCase == R.IgnoreCase &&
+ IgnoreExtension == R.IgnoreExtension;
}
bool operator!=(const SortIncludesOptions &R) const {
return !(*this == R);
diff --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 78c09be458f0a..62feb3db0ed5e 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -665,21 +665,25 @@ template <> struct
MappingTraits {
IO.enumCase(Value, "Never", FormatStyle::SortIncludesOptions({}));
IO.enumCase(Value, "CaseInsensitive",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/true}));
+ /*IgnoreCase=*/true,
+ /*IgnoreExtension=*/false}));
IO.enumCase(Value, "CaseSensitive",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/false}));
+ /*IgnoreCase=*/false,
+ /*IgnoreExtension=*/false}));
// For backward compatibility.
IO.enumCase(Value, "false", FormatStyle::SortIncludesOptions({}));
IO.enumCase(Value, "true",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/false}));
+ /*IgnoreCase=*/false,
+ /*IgnoreExtension=*/false}));
}
static void mapping(IO &IO, FormatStyle::SortIncludesOptions &Value) {
IO.mapOptional("Enabled", Value.Enabled);
IO.mapOptional("IgnoreCase", Value.IgnoreCase);
+IO.mapOptional("IgnoreExtensi
[clang] [llvm] [VectorCombine] Shrink loads used in shufflevector rebroadcasts (PR #128938)
@@ -3691,6 +3696,132 @@ bool
VectorCombine::foldInterleaveIntrinsics(Instruction &I) {
return true;
}
+// Attempt to shrink loads that are only used by shufflevector instructions.
+bool VectorCombine::shrinkLoadForShuffles(Instruction &I) {
+ auto *OldLoad = dyn_cast(&I);
+ if (!OldLoad || !OldLoad->isSimple())
+return false;
+
+ auto *OldLoadTy = dyn_cast(OldLoad->getType());
+ if (!OldLoadTy)
+return false;
+
+ unsigned const OldNumElements = OldLoadTy->getNumElements();
+
+ // Search all uses of load. If all uses are shufflevector instructions, and
+ // the second operands are all poison values, find the minimum and maximum
+ // indices of the vector elements referenced by all shuffle masks.
+ // Otherwise return `std::nullopt`.
+ using IndexRange = std::pair;
+ auto GetIndexRangeInShuffles = [&]() -> std::optional {
+IndexRange OutputRange = IndexRange(OldNumElements, -1);
+for (llvm::Use &Use : I.uses()) {
+ // Ensure all uses match the required pattern.
+ User *Shuffle = Use.getUser();
+ ArrayRef Mask;
+
+ if (!match(Shuffle,
+ m_Shuffle(m_Specific(OldLoad), m_Undef(), m_Mask(Mask
+return std::nullopt;
+
+ // Ignore shufflevector instructions that have no uses.
+ if (Shuffle->use_empty())
+continue;
+
+ // Find the min and max indices used by the shufflevector instruction.
+ for (int Index : Mask) {
+if (Index >= 0 && Index < static_cast(OldNumElements)) {
+ OutputRange.first = std::min(Index, OutputRange.first);
+ OutputRange.second = std::max(Index, OutputRange.second);
+}
+ }
+}
+
+if (OutputRange.second < OutputRange.first)
+ return std::nullopt;
+
+return OutputRange;
+ };
+
+ // Get the range of vector elements used by shufflevector instructions.
+ if (std::optional Indices = GetIndexRangeInShuffles()) {
+unsigned const NewNumElements = Indices->second + 1u;
+
+// If the range of vector elements is smaller than the full load, attempt
+// to create a smaller load.
+if (NewNumElements < OldNumElements) {
+ IRBuilder Builder(&I);
+ Builder.SetCurrentDebugLocation(I.getDebugLoc());
+
+ // Calculate costs of old and new ops.
+ Type *ElemTy = OldLoadTy->getElementType();
+ FixedVectorType *NewLoadTy = FixedVectorType::get(ElemTy,
NewNumElements);
+ Value *PtrOp = OldLoad->getPointerOperand();
+
+ InstructionCost OldCost = TTI.getMemoryOpCost(
+ Instruction::Load, OldLoad->getType(), OldLoad->getAlign(),
+ OldLoad->getPointerAddressSpace(), CostKind);
+ InstructionCost NewCost =
+ TTI.getMemoryOpCost(Instruction::Load, NewLoadTy,
OldLoad->getAlign(),
+ OldLoad->getPointerAddressSpace(), CostKind);
+
+ using UseEntry = std::pair>;
+ SmallVector NewUses;
+ unsigned const SizeDiff = OldNumElements - NewNumElements;
+
+ for (llvm::Use &Use : I.uses()) {
+auto *Shuffle = cast(Use.getUser());
+ArrayRef OldMask = Shuffle->getShuffleMask();
+
+// Create entry for new use.
+NewUses.push_back({Shuffle, {}});
+std::vector &NewMask = NewUses.back().second;
+for (int Index : OldMask)
+ NewMask.push_back(Index >= static_cast(OldNumElements)
+? Index - SizeDiff
RKSimon wrote:
whats the purpose of this? we might be better not to allow any shuffles that
reference the second (undef) operand in GetIndexRangeInShuffles - and here just
assert (Index <= Indices->second)
https://github.com/llvm/llvm-project/pull/128938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] clang-format: Add IncludeSortKey option (PR #137840)
https://github.com/DaanDeMeyer updated
https://github.com/llvm/llvm-project/pull/137840
>From 22a095db11bf132dd9fd5c5bcc887397b2766206 Mon Sep 17 00:00:00 2001
From: Daan De Meyer
Date: Tue, 29 Apr 2025 18:26:36 +0200
Subject: [PATCH] clang-format: Add IgnoreExtension option to
SortIncludesOptions
Sorting without taking the file extension into account gives nicer results
when various header file names are substrings of other header file names,
for example, a CLI application with a main header named analyze.h and a
analyze-xxx.h header for each subcommand currently will always put analyze.h
last after all the analyze-xxx.h headers, but putting analyze.h first instead
of last is arguable nicer to read.
TLDR; Instead of
"""
/#include "analyze-blame.h"
/#include "analyze.h"
"""
You'd get
"""
/#include "analyze.h"
/#include "analyze-blame.h"
"""
Let's allow sorting without taking the file extension into account unless two
headers otherwise compare equal by introducing a new boolean option
IgnoreExtension
for SortIncludesOptions.
---
clang/docs/ClangFormatStyleOptions.rst | 10 +
clang/include/clang/Format/Format.h | 12 +-
clang/lib/Format/Format.cpp | 45 +
clang/unittests/Format/ConfigParseTest.cpp | 22 +-
clang/unittests/Format/SortIncludesTest.cpp | 20 +
5 files changed, 83 insertions(+), 26 deletions(-)
diff --git a/clang/docs/ClangFormatStyleOptions.rst
b/clang/docs/ClangFormatStyleOptions.rst
index 0e21ef0244f78..4827cdb471690 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -6015,6 +6015,16 @@ the configuration (without a prefix: ``Auto``).
#include "B/A.h" #include "B/a.h"
#include "B/a.h" #include "a/b.h"
+ * ``bool IgnoreExtension`` When sorting includes in each block, only take
file extensions into
+account if two includes compare equal otherwise.
+
+.. code-block:: c++
+
+ true: false:
+ # include "A.h" vs.# include "A-util.h"
+ # include "A.inc" # include "A.h"
+ # include "A-util.h" # include "A.inc"
+
.. _SortJavaStaticImport:
diff --git a/clang/include/clang/Format/Format.h
b/clang/include/clang/Format/Format.h
index b4f2a87fe7e83..70406d06d48c6 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -4385,8 +4385,18 @@ struct FormatStyle {
///#include "B/a.h" #include "a/b.h"
/// \endcode
bool IgnoreCase;
+/// When sorting includes in each block, only take file extensions into
+/// account if two includes compare equal otherwise.
+/// \code
+///true: false:
+///# include "A.h" vs.# include "A-util.h"
+///# include "A.inc" # include "A.h"
+///# include "A-util.h" # include "A.inc"
+/// \endcode
+bool IgnoreExtension;
bool operator==(const SortIncludesOptions &R) const {
- return Enabled == R.Enabled && IgnoreCase == R.IgnoreCase;
+ return Enabled == R.Enabled && IgnoreCase == R.IgnoreCase &&
+ IgnoreExtension == R.IgnoreExtension;
}
bool operator!=(const SortIncludesOptions &R) const {
return !(*this == R);
diff --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 78c09be458f0a..62feb3db0ed5e 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -665,21 +665,25 @@ template <> struct
MappingTraits {
IO.enumCase(Value, "Never", FormatStyle::SortIncludesOptions({}));
IO.enumCase(Value, "CaseInsensitive",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/true}));
+ /*IgnoreCase=*/true,
+ /*IgnoreExtension=*/false}));
IO.enumCase(Value, "CaseSensitive",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/false}));
+ /*IgnoreCase=*/false,
+ /*IgnoreExtension=*/false}));
// For backward compatibility.
IO.enumCase(Value, "false", FormatStyle::SortIncludesOptions({}));
IO.enumCase(Value, "true",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/false}));
+ /*IgnoreCase=*/false,
+ /*IgnoreExtension=*/false}));
}
static void mapping(IO &IO, FormatStyle::SortIncludesOptions &Value) {
IO.mapOptional("Enabled", Value.Enabled);
IO.mapOptional("IgnoreCase", Value.IgnoreCase);
+IO.mapO
[clang] [llvm] [CodeGen] Fix VNInfo mapping in LiveRange::assign (PR #148790)
pzzp wrote: This isssue lead to a crash on our private target., but we did not reproduce it in x86 or AMDGPU crash stacktrace: llc: /root/baidu/xpu/llvm19/llvm/lib/CodeGen/LiveIntervals.cpp:397: void llvm::LiveIntervals::extendSegmentsToUses(llvm::LiveRange&, llvm::LiveIntervals::ShrinkToUsesWorkList&, llvm::Register, llvm::LaneBitmask): Assertion `ExtVNI == VNI && "Unexpected existing value number"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: bin/llc /root/baidu/xpu/llvm19/llvm/test/CodeGen/XCN/register_coalescer_crash.ll 1. Running pass 'CallGraph Pass Manager' on module '/root/baidu/xpu/llvm19/llvm/test/CodeGen/XCN/register_coalescer_crash.ll'. 2. Running pass 'Register Coalescer' on function '@_ZN3cub26DeviceHistogramSweepKernelINS_17DispatchHistogramILi4ELi3EPtiiiE23PtxHistogramSweepPolicyELi0ELi4ELi3ES2_iNS3_14ScaleTransformENS3_17PassThruTransformEiEEvT3_NS_12ArrayWrapperIiXT2_EEES9_NS8_IPT4_XT2_EEESC_NS8_IT6_XT2_EEENS8_IT5_XT2_EEET7_SH_SH_iNS_9GridQueueIiEE' #0 0x555666017d10 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (bin/llc+0x2c09d10) #1 0x55566601511f llvm::sys::RunSignalHandlers() (bin/llc+0x2c0711f) #2 0x555666015275 SignalHandler(int) Signals.cpp:0:0 #3 0x7f69f3b27520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x7f69f3b7b9fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #5 0x7f69f3b27476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #6 0x7f69f3b0d7f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #7 0x7f69f3b0d71b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b) #8 0x7f69f3b1ee96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96) #9 0x555664eabbde llvm::LiveIntervals::extendSegmentsToUses(llvm::LiveRange&, llvm::SmallVector, 16u>&, llvm::Register, llvm::LaneBitmask) (bin/llc+0x1a9dbde) #10 0x555664eabdeb llvm::LiveIntervals::shrinkToUses(llvm::LiveInterval::SubRange&, llvm::Register) (bin/llc+0x1a9ddeb) #11 0x555664eac316 llvm::LiveIntervals::shrinkToUses(llvm::LiveInterval*, llvm::SmallVectorImpl*) (bin/llc+0x1a9e316) #12 0x55566519104f (anonymous namespace)::RegisterCoalescer::shrinkToUses(llvm::LiveInterval*, llvm::SmallVectorImpl*) RegisterCoalescer.cpp:0:0 #13 0x5556651a0782 (anonymous namespace)::RegisterCoalescer::joinCopy(llvm::MachineInstr*, bool&, llvm::SmallPtrSetImpl&) (.constprop.0) RegisterCoalescer.cpp:0:0 #14 0x5556651a27fc (anonymous namespace)::RegisterCoalescer::copyCoalesceWorkList(llvm::MutableArrayRef) RegisterCoalescer.cpp:0:0 #15 0x5556651a36fd (anonymous namespace)::RegisterCoalescer::coalesceLocals() RegisterCoalescer.cpp:0:0 #16 0x5556651a6213 (anonymous namespace)::RegisterCoalescer::runOnMachineFunction(llvm::MachineFunction&) RegisterCoalescer.cpp:0:0 #17 0x555664f82607 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0 #18 0x555665572b26 llvm::FPPassManager::runOnFunction(llvm::Function&) (bin/llc+0x2164b26) #19 0x555664a74f5a (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) CallGraphSCCPass.cpp:0:0 #20 0x5556655736e5 llvm::legacy::PassManagerImpl::run(llvm::Module&) (bin/llc+0x21656e5) #21 0x555663ac32de compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0 #22 0x5556639ee3f6 main (bin/llc+0x5e03f6) #23 0x7f69f3b0ed90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90) #24 0x7f69f3b0ee40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40) #25 0x555663ab9b85 _start (bin/llc+0x6abb85 https://github.com/llvm/llvm-project/pull/148790 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] clang-format: Add IncludeSortKey option (PR #137840)
https://github.com/DaanDeMeyer updated
https://github.com/llvm/llvm-project/pull/137840
>From f17570565365d0dc94cb2dd2a63e303bc1f92493 Mon Sep 17 00:00:00 2001
From: Daan De Meyer
Date: Tue, 29 Apr 2025 18:26:36 +0200
Subject: [PATCH] clang-format: Add IgnoreExtension option to
SortIncludesOptions
Sorting without taking the file extension into account gives nicer results
when various header file names are substrings of other header file names,
for example, a CLI application with a main header named analyze.h and a
analyze-xxx.h header for each subcommand currently will always put analyze.h
last after all the analyze-xxx.h headers, but putting analyze.h first instead
of last is arguable nicer to read.
TLDR; Instead of
"""
/#include "analyze-blame.h"
/#include "analyze.h"
"""
You'd get
"""
/#include "analyze.h"
/#include "analyze-blame.h"
"""
Let's allow sorting without taking the file extension into account unless two
headers otherwise compare equal by introducing a new boolean option
IgnoreExtension
for SortIncludesOptions.
---
clang/docs/ClangFormatStyleOptions.rst | 10 +
clang/include/clang/Format/Format.h | 12 +-
clang/lib/Format/Format.cpp | 45 +
clang/unittests/Format/ConfigParseTest.cpp | 7 ++--
clang/unittests/Format/SortIncludesTest.cpp | 20 +
5 files changed, 74 insertions(+), 20 deletions(-)
diff --git a/clang/docs/ClangFormatStyleOptions.rst
b/clang/docs/ClangFormatStyleOptions.rst
index 0e21ef0244f78..4827cdb471690 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -6015,6 +6015,16 @@ the configuration (without a prefix: ``Auto``).
#include "B/A.h" #include "B/a.h"
#include "B/a.h" #include "a/b.h"
+ * ``bool IgnoreExtension`` When sorting includes in each block, only take
file extensions into
+account if two includes compare equal otherwise.
+
+.. code-block:: c++
+
+ true: false:
+ # include "A.h" vs.# include "A-util.h"
+ # include "A.inc" # include "A.h"
+ # include "A-util.h" # include "A.inc"
+
.. _SortJavaStaticImport:
diff --git a/clang/include/clang/Format/Format.h
b/clang/include/clang/Format/Format.h
index b4f2a87fe7e83..70406d06d48c6 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -4385,8 +4385,18 @@ struct FormatStyle {
///#include "B/a.h" #include "a/b.h"
/// \endcode
bool IgnoreCase;
+/// When sorting includes in each block, only take file extensions into
+/// account if two includes compare equal otherwise.
+/// \code
+///true: false:
+///# include "A.h" vs.# include "A-util.h"
+///# include "A.inc" # include "A.h"
+///# include "A-util.h" # include "A.inc"
+/// \endcode
+bool IgnoreExtension;
bool operator==(const SortIncludesOptions &R) const {
- return Enabled == R.Enabled && IgnoreCase == R.IgnoreCase;
+ return Enabled == R.Enabled && IgnoreCase == R.IgnoreCase &&
+ IgnoreExtension == R.IgnoreExtension;
}
bool operator!=(const SortIncludesOptions &R) const {
return !(*this == R);
diff --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 78c09be458f0a..62feb3db0ed5e 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -665,21 +665,25 @@ template <> struct
MappingTraits {
IO.enumCase(Value, "Never", FormatStyle::SortIncludesOptions({}));
IO.enumCase(Value, "CaseInsensitive",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/true}));
+ /*IgnoreCase=*/true,
+ /*IgnoreExtension=*/false}));
IO.enumCase(Value, "CaseSensitive",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/false}));
+ /*IgnoreCase=*/false,
+ /*IgnoreExtension=*/false}));
// For backward compatibility.
IO.enumCase(Value, "false", FormatStyle::SortIncludesOptions({}));
IO.enumCase(Value, "true",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/false}));
+ /*IgnoreCase=*/false,
+ /*IgnoreExtension=*/false}));
}
static void mapping(IO &IO, FormatStyle::SortIncludesOptions &Value) {
IO.mapOptional("Enabled", Value.Enabled);
IO.mapOptional("IgnoreCase", Value.IgnoreCase);
+IO.mapOptiona
[clang] [NFC][-Wunsafe-buffer-usage] Refactor safe pattern check for pointer-size pairs (PR #145626)
ziqingluo-90 wrote: > https://lab.llvm.org/buildbot/#/builders/190/builds/23511 The failed test is `ExecutionEngine/OrcLazy/multiple-compile-threads-basic.ll`, which can't be affected by this change. https://github.com/llvm/llvm-project/pull/145626 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [NFC][-Wunsafe-buffer-usage] Refactor safe pattern check for pointer-size pairs (PR #145626)
llvm-ci wrote: LLVM Buildbot has detected a new failure on builder `llvm-clang-aarch64-darwin` running on `doug-worker-5` while building `clang` at step 6 "test-build-unified-tree-check-all". Full details are available at: https://lab.llvm.org/buildbot/#/builders/190/builds/23511 Here is the relevant piece of the build log for the reference ``` Step 6 (test-build-unified-tree-check-all) failure: test (failure) TEST 'LLVM :: ExecutionEngine/OrcLazy/multiple-compile-threads-basic.ll' FAILED Exit Code: 2 Command Output (stderr): -- /Users/buildbot/buildbot-root/aarch64-darwin/build/bin/lli -jit-kind=orc-lazy -compile-threads=2 -thread-entry hello /Users/buildbot/buildbot-root/aarch64-darwin/llvm-project/llvm/test/ExecutionEngine/OrcLazy/multiple-compile-threads-basic.ll | /Users/buildbot/buildbot-root/aarch64-darwin/build/bin/FileCheck /Users/buildbot/buildbot-root/aarch64-darwin/llvm-project/llvm/test/ExecutionEngine/OrcLazy/multiple-compile-threads-basic.ll # RUN: at line 1 + /Users/buildbot/buildbot-root/aarch64-darwin/build/bin/lli -jit-kind=orc-lazy -compile-threads=2 -thread-entry hello /Users/buildbot/buildbot-root/aarch64-darwin/llvm-project/llvm/test/ExecutionEngine/OrcLazy/multiple-compile-threads-basic.ll + /Users/buildbot/buildbot-root/aarch64-darwin/build/bin/FileCheck /Users/buildbot/buildbot-root/aarch64-darwin/llvm-project/llvm/test/ExecutionEngine/OrcLazy/multiple-compile-threads-basic.ll PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. #0 0x000102f0e5f0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/buildbot/buildbot-root/aarch64-darwin/build/bin/lli+0x100efe5f0) #1 0x000102f0c3a0 llvm::sys::RunSignalHandlers() (/Users/buildbot/buildbot-root/aarch64-darwin/build/bin/lli+0x100efc3a0) #2 0x000102f0f0f0 SignalHandler(int, __siginfo*, void*) (/Users/buildbot/buildbot-root/aarch64-darwin/build/bin/lli+0x100eff0f0) #3 0x000185f3b584 (/usr/lib/system/libsystem_platform.dylib+0x18047b584) #4 0x000185f0a21c (/usr/lib/system/libsystem_pthread.dylib+0x18044a21c) #5 0x000185e30ad0 (/usr/lib/libc++.1.dylib+0x180370ad0) #6 0x000102a9c4ec void llvm::detail::UniqueFunctionBase, llvm::detail::DenseMapPair>>>::CallImpl, llvm::detail::DenseMapPair> const&)::$_45>(void*, llvm::Expected, llvm::detail::DenseMapPair>>&) (/Users/buildbot/buildbot-root/aarch64-darwin/build/bin/lli+0x100a8c4ec) #7 0x000102a98120 llvm::orc::AsynchronousSymbolQuery::handleComplete(llvm::orc::ExecutionSession&)::RunQueryCompleteTask::run() (/Users/buildbot/buildbot-root/aarch64-darwin/build/bin/lli+0x100a88120) #8 0x000102b5fee0 void* std::__1::__thread_proxy[abi:un170006]>, llvm::orc::DynamicThreadPoolTaskDispatcher::dispatch(std::__1::unique_ptr>)::$_0>>(void*) (/Users/buildbot/buildbot-root/aarch64-darwin/build/bin/lli+0x100b4fee0) #9 0x000185f0af94 (/usr/lib/system/libsystem_pthread.dylib+0x18044af94) #10 0x000185f05d34 (/usr/lib/system/libsystem_pthread.dylib+0x180445d34) FileCheck error: '' is empty. FileCheck command line: /Users/buildbot/buildbot-root/aarch64-darwin/build/bin/FileCheck /Users/buildbot/buildbot-root/aarch64-darwin/llvm-project/llvm/test/ExecutionEngine/OrcLazy/multiple-compile-threads-basic.ll -- ``` https://github.com/llvm/llvm-project/pull/145626 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [clang]: Propagate `*noreturn` attributes in `CFG` (PR #146355)
https://github.com/negativ updated
https://github.com/llvm/llvm-project/pull/146355
>From fc3b77d8c4b5dd264bd746ed997bcea6cddaf389 Mon Sep 17 00:00:00 2001
From: Andrey Karlov
Date: Mon, 30 Jun 2025 17:05:41 +0300
Subject: [PATCH 1/8] Initial implementation
---
.../bugprone/unchecked-optional-access.cpp| 36 +++
clang/include/clang/AST/Decl.h| 5 ++
clang/lib/AST/Decl.cpp| 4 ++
clang/lib/Analysis/CFG.cpp| 62 ++-
.../TypeErasedDataflowAnalysis.cpp| 4 +-
5 files changed, 107 insertions(+), 4 deletions(-)
diff --git
a/clang-tools-extra/test/clang-tidy/checkers/bugprone/unchecked-optional-access.cpp
b/clang-tools-extra/test/clang-tidy/checkers/bugprone/unchecked-optional-access.cpp
index 3167b85f0e024..f4f82199a0bb5 100644
---
a/clang-tools-extra/test/clang-tidy/checkers/bugprone/unchecked-optional-access.cpp
+++
b/clang-tools-extra/test/clang-tidy/checkers/bugprone/unchecked-optional-access.cpp
@@ -141,6 +141,42 @@ void
nullable_value_after_swap(BloombergLP::bdlb::NullableValue &opt1, Bloo
}
}
+void assertion_handler_imp() __attribute__((analyzer_noreturn));
+
+void assertion_handler() {
+do {
+ assertion_handler_imp();
+} while(0);
+}
+
+void function_calling_analyzer_noreturn(const bsl::optional& opt)
+{
+ if (!opt) {
+ assertion_handler();
+ }
+
+ *opt; // no-warning
+}
+
+void abort();
+
+void do_fail() {
+abort(); // acts like 'abort()' C-function
+}
+
+void invoke_assertion_handler() {
+do_fail();
+}
+
+void function_calling_well_known_noreturn(const bsl::optional& opt)
+{
+ if (!opt) {
+ invoke_assertion_handler();
+ }
+
+ *opt; // no-warning
+}
+
template
void function_template_without_user(const absl::optional &opt) {
opt.value(); // no-warning
diff --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index c4202f1f3d07e..0b27cb7f2cb4e 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -2624,6 +2624,11 @@ class FunctionDecl : public DeclaratorDecl,
/// an attribute on its declaration or its type.
bool isNoReturn() const;
+ /// Determines whether this function is known to never return for CFG
+ /// analysis. Checks for noreturn attributes on the function declaration
+ /// or its type, including 'analyzer_noreturn' attribute.
+ bool isAnalyzerNoReturn() const;
+
/// True if the function was a definition but its body was skipped.
bool hasSkippedBody() const { return FunctionDeclBits.HasSkippedBody; }
void setHasSkippedBody(bool Skipped = true) {
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 5cdf75d71e4d7..72f63978c085b 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -3603,6 +3603,10 @@ bool FunctionDecl::isNoReturn() const {
return false;
}
+bool FunctionDecl::isAnalyzerNoReturn() const {
+ return isNoReturn() || hasAttr();
+}
+
bool FunctionDecl::isMemberLikeConstrainedFriend() const {
// C++20 [temp.friend]p9:
// A non-template friend declaration with a requires-clause [or]
diff --git a/clang/lib/Analysis/CFG.cpp b/clang/lib/Analysis/CFG.cpp
index cf7595952be27..02876e5770c2c 100644
--- a/clang/lib/Analysis/CFG.cpp
+++ b/clang/lib/Analysis/CFG.cpp
@@ -2835,8 +2835,37 @@ CFGBlock *CFGBuilder::VisitCallExpr(CallExpr *C,
AddStmtChoice asc) {
if (!FD->isVariadic())
findConstructionContextsForArguments(C);
-if (FD->isNoReturn() || C->isBuiltinAssumeFalse(*Context))
- NoReturn = true;
+if (!NoReturn)
+ NoReturn = FD->isAnalyzerNoReturn() || C->isBuiltinAssumeFalse(*Context);
+
+// Some well-known 'noreturn' functions
+if (!NoReturn)
+ NoReturn = llvm::StringSwitch(FD->getQualifiedNameAsString())
+ .Case("BloombergLP::bsls::Assert::invokeHandler", true)
+ .Case("std::terminate", true)
+ .Case("std::abort", true)
+ .Case("exit", true)
+ .Case("abort", true)
+ .Case("panic", true)
+ .Case("error", true)
+ .Case("Assert", true)
+ .Case("ziperr", true)
+ .Case("assfail", true)
+ .Case("db_error", true)
+ .Case("__assert", true)
+ .Case("__assert2", true)
+ .Case("_wassert", true)
+ .Case("__assert_rtn", true)
+ .Case("__assert_fail", true)
+ .Case("dtrace_assfail", true)
+ .Case("yy_fatal_error", true)
+ .Case("_XCAssertionFailureHandler", true)
+ .Case("_DTAssertionFailureHandler", true)
+ .Case("_TSAssertionFailureHandler", true)
+ .Case("__builtin_trap", true)
+ .Case("__builtin_unreachable", true)
+
[clang] Fix scope of typedefs present inside a template class (PR #146729)
Michael137 wrote:
Yea this even works when the typedef is not template-dependent but used outside
of the class only:
```
template
struct Y {
typedef int outside;
int o;
};
Y<> y;
Y<>::outside g;
```
Again, in this case the `TypedefDecl`s `DeclContext` is the
`ClassTemplateSpecializationDecl`. So why is it only an issue when the typedef
is not template-dependent but is used as the type of a field?
https://github.com/llvm/llvm-project/pull/146729
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Test] Add PS5 and WI cases to clang/test/Sema/dllexport.c (PR #148818)
https://github.com/bd1976bris created https://github.com/llvm/llvm-project/pull/148818 Windows Itanium and PS5 are both Itanium C++ ABI variants which have the goal of semantic compatibility with Microsoft C++ code that uses dllimport/export. This patch adds Windows Itanium and PS5 triple testing to clang/test/Sema/dllexport.c. We have this testing in our downstream toolchain - for some reason it was not added upstream when the work for supporting dllimport/export was done. >From aadd2cebb4f0a955d1f1004036b65bfa1d1c0985 Mon Sep 17 00:00:00 2001 From: Dunbobbin Date: Tue, 15 Jul 2025 10:49:28 +0100 Subject: [PATCH] [Clang][Test] Add PS5 and WI cases to clang/test/Sema/dllexport.c Windows Itanium and PS5 are both Itanium C++ ABI variants which have the goal of semantic compatibility with Microsoft C++ code that uses dllimport/export. This patch adds Windows Itanium and PS5 triple testing to clang/test/Sema/dllexport.c. We have this testing in our downstream toolchain - for some reason it was not added upstream when the work for supporting dllimport/export was done. --- clang/test/Sema/dllexport.c | 4 1 file changed, 4 insertions(+) diff --git a/clang/test/Sema/dllexport.c b/clang/test/Sema/dllexport.c index 3f911fb095c0f..5f6ff36e290e9 100644 --- a/clang/test/Sema/dllexport.c +++ b/clang/test/Sema/dllexport.c @@ -2,6 +2,10 @@ // RUN: %clang_cc1 -triple x86_64-win32 -fsyntax-only -fms-extensions -verify -std=c11 %s // RUN: %clang_cc1 -triple i686-mingw32 -fsyntax-only -fms-extensions -verify -std=c11 %s // RUN: %clang_cc1 -triple x86_64-mingw32 -fsyntax-only -fms-extensions -verify -std=c99 %s +// RUN: %clang_cc1 -triple i686-windows-itanium -fsyntax-only -fms-extensions -verify -std=c99 %s +// RUN: %clang_cc1 -triple x86_64-windows-itanium -fsyntax-only -fms-extensions -verify -std=c11 %s +// RUN: %clang_cc1 -triple x86_64-sie-ps5 -fsyntax-only -fms-extensions -verify -std=c99 %s +// RUN: %clang_cc1 -triple x86_64-sie-ps5 -fsyntax-only -fms-extensions -verify -std=c11 %s // Invalid usage. __declspec(dllexport) typedef int typedef1; ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [clang]: Propagate `*noreturn` attributes in `CFG` (PR #146355)
@@ -6298,10 +6304,43 @@ static bool isImmediateSinkBlock(const CFGBlock *Blk) {
// at least for now, but once we have better support for exceptions,
// we'd need to carefully handle the case when the throw is being
// immediately caught.
- if (llvm::any_of(*Blk, [](const CFGElement &Elm) {
+ if (llvm::any_of(*Blk, [](const CFGElement &Elm) -> bool {
+if (std::optional StmtElm = Elm.getAs())
+ return isa(StmtElm->getStmt());
+return false;
+ }))
+return true;
+
+ auto HasNoReturnCall = [](const CallExpr *CE) {
+if (!CE)
+ return false;
+
+static thread_local llvm::SmallPtrSet InProgress;
+
+auto *FD = CE->getDirectCallee();
+
+if (!FD || InProgress.count(FD))
+ return false;
+
+InProgress.insert(FD);
+auto DoCleanup = llvm::make_scope_exit([&]() { InProgress.erase(FD); });
+
+auto NoReturnFromCFG = [FD]() {
+ if (!FD->getBody())
+return false;
+
+ auto CalleeCFG =
+ CFG::buildCFG(FD, FD->getBody(), &FD->getASTContext(), {});
+
+ return CalleeCFG && CalleeCFG->getEntry().isInevitablySinking();
+};
+
+return FD->isAnalyzerNoReturn() || NoReturnFromCFG();
negativ wrote:
> What if we have redecls, does it matter which has the attribute, or do we
> always bind the attribute to the canonical decl?
Switched to using canonical decl for `analyzer_noreturn` lookup & caching. BTW:
since `AnalyzerNoReturnAttr` inherits from `InheritableAttr`, we can check any
function decl.
https://github.com/llvm/llvm-project/pull/146355
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Test] Add PS5 and WI cases to clang/test/Sema/dllexport.c (PR #148818)
llvmbot wrote: @llvm/pr-subscribers-clang Author: bd1976bris (bd1976bris) Changes Windows Itanium and PS5 are both Itanium C++ ABI variants which have the goal of semantic compatibility with Microsoft C++ code that uses dllimport/export. This patch adds Windows Itanium and PS5 triple testing to clang/test/Sema/dllexport.c. We have this testing in our downstream toolchain - for some reason it was not added upstream when the work for supporting dllimport/export was done. --- Full diff: https://github.com/llvm/llvm-project/pull/148818.diff 1 Files Affected: - (modified) clang/test/Sema/dllexport.c (+4) ``diff diff --git a/clang/test/Sema/dllexport.c b/clang/test/Sema/dllexport.c index 3f911fb095c0f..5f6ff36e290e9 100644 --- a/clang/test/Sema/dllexport.c +++ b/clang/test/Sema/dllexport.c @@ -2,6 +2,10 @@ // RUN: %clang_cc1 -triple x86_64-win32 -fsyntax-only -fms-extensions -verify -std=c11 %s // RUN: %clang_cc1 -triple i686-mingw32 -fsyntax-only -fms-extensions -verify -std=c11 %s // RUN: %clang_cc1 -triple x86_64-mingw32 -fsyntax-only -fms-extensions -verify -std=c99 %s +// RUN: %clang_cc1 -triple i686-windows-itanium -fsyntax-only -fms-extensions -verify -std=c99 %s +// RUN: %clang_cc1 -triple x86_64-windows-itanium -fsyntax-only -fms-extensions -verify -std=c11 %s +// RUN: %clang_cc1 -triple x86_64-sie-ps5 -fsyntax-only -fms-extensions -verify -std=c99 %s +// RUN: %clang_cc1 -triple x86_64-sie-ps5 -fsyntax-only -fms-extensions -verify -std=c11 %s // Invalid usage. __declspec(dllexport) typedef int typedef1; `` https://github.com/llvm/llvm-project/pull/148818 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Add IgnoreExtension to SortIncludes (PR #137840)
https://github.com/DaanDeMeyer updated
https://github.com/llvm/llvm-project/pull/137840
>From e8e1f1e47accfbda1dc9d2a68ebdf2a881b7026b Mon Sep 17 00:00:00 2001
From: Daan De Meyer
Date: Tue, 29 Apr 2025 18:26:36 +0200
Subject: [PATCH] clang-format: Add IgnoreExtension option to
SortIncludesOptions
Sorting without taking the file extension into account gives nicer results
when various header file names are substrings of other header file names,
for example, a CLI application with a main header named analyze.h and a
analyze-xxx.h header for each subcommand currently will always put analyze.h
last after all the analyze-xxx.h headers, but putting analyze.h first instead
of last is arguable nicer to read.
TLDR; Instead of
"""
/#include "analyze-blame.h"
/#include "analyze.h"
"""
You'd get
"""
/#include "analyze.h"
/#include "analyze-blame.h"
"""
Let's allow sorting without taking the file extension into account unless two
headers otherwise compare equal by introducing a new boolean option
IgnoreExtension
for SortIncludesOptions.
---
clang/docs/ClangFormatStyleOptions.rst | 10 +
clang/include/clang/Format/Format.h | 12 +-
clang/lib/Format/Format.cpp | 45 +
clang/unittests/Format/ConfigParseTest.cpp | 22 +-
clang/unittests/Format/SortIncludesTest.cpp | 20 +
5 files changed, 83 insertions(+), 26 deletions(-)
diff --git a/clang/docs/ClangFormatStyleOptions.rst
b/clang/docs/ClangFormatStyleOptions.rst
index 0e21ef0244f78..bfc8094f3f50c 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -6015,6 +6015,16 @@ the configuration (without a prefix: ``Auto``).
#include "B/A.h" #include "B/a.h"
#include "B/a.h" #include "a/b.h"
+ * ``bool IgnoreExtension`` When sorting includes in each block, only take
file extensions into
+account if two includes compare equal otherwise.
+
+.. code-block:: c++
+
+ true: false:
+ # include "A.h" vs.# include "A-util.h"
+ # include "A.inc" # include "A.h"
+ # include "A-util.h" # include "A.inc"
+
.. _SortJavaStaticImport:
diff --git a/clang/include/clang/Format/Format.h
b/clang/include/clang/Format/Format.h
index b4f2a87fe7e83..7677604484f52 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -4385,8 +4385,18 @@ struct FormatStyle {
///#include "B/a.h" #include "a/b.h"
/// \endcode
bool IgnoreCase;
+/// When sorting includes in each block, only take file extensions into
+/// account if two includes compare equal otherwise.
+/// \code
+///true: false:
+///# include "A.h" vs.# include "A-util.h"
+///# include "A.inc" # include "A.h"
+///# include "A-util.h" # include "A.inc"
+/// \endcode
+bool IgnoreExtension;
bool operator==(const SortIncludesOptions &R) const {
- return Enabled == R.Enabled && IgnoreCase == R.IgnoreCase;
+ return Enabled == R.Enabled && IgnoreCase == R.IgnoreCase &&
+ IgnoreExtension == R.IgnoreExtension;
}
bool operator!=(const SortIncludesOptions &R) const {
return !(*this == R);
diff --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 78c09be458f0a..62feb3db0ed5e 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -665,21 +665,25 @@ template <> struct
MappingTraits {
IO.enumCase(Value, "Never", FormatStyle::SortIncludesOptions({}));
IO.enumCase(Value, "CaseInsensitive",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/true}));
+ /*IgnoreCase=*/true,
+ /*IgnoreExtension=*/false}));
IO.enumCase(Value, "CaseSensitive",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/false}));
+ /*IgnoreCase=*/false,
+ /*IgnoreExtension=*/false}));
// For backward compatibility.
IO.enumCase(Value, "false", FormatStyle::SortIncludesOptions({}));
IO.enumCase(Value, "true",
FormatStyle::SortIncludesOptions({/*Enabled=*/true,
- /*IgnoreCase=*/false}));
+ /*IgnoreCase=*/false,
+ /*IgnoreExtension=*/false}));
}
static void mapping(IO &IO, FormatStyle::SortIncludesOptions &Value) {
IO.mapOptional("Enabled", Value.Enabled);
IO.mapOptional("IgnoreCase", Value.IgnoreCase);
+IO.mapO
[libclc] [libclc] Move CMake for prepare_builtins to a subdirectory (PR #148815)
@@ -164,34 +164,14 @@ endif()
list( SORT LIBCLC_TARGETS_TO_BUILD )
-# Construct LLVM version define
-set( LLVM_VERSION_DEFINE
"-DHAVE_LLVM=0x${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}" )
-
# This needs to be set before any target that needs it
# We need to use LLVM_INCLUDE_DIRS here, because if we are linking to an
# llvm build directory, this includes $src/llvm/include which is where all the
# headers are not $build/include/ which is what LLVM_INCLUDE_DIR is set to.
include_directories( ${LLVM_INCLUDE_DIRS} )
-# Setup prepare_builtins tools
-set(LLVM_LINK_COMPONENTS
- BitReader
- BitWriter
- Core
- IRReader
- Support
-)
-if( LIBCLC_STANDALONE_BUILD )
- add_llvm_executable( prepare_builtins utils/prepare-builtins.cpp )
- set( prepare_builtins_exe prepare_builtins )
- set( prepare_builtins_target prepare_builtins )
-else()
- add_llvm_utility( prepare_builtins utils/prepare-builtins.cpp )
- setup_host_tool( prepare_builtins PREPARE_BUILTINS prepare_builtins_exe
prepare_builtins_target )
-endif()
-target_compile_definitions( prepare_builtins PRIVATE ${LLVM_VERSION_DEFINE} )
-# These were not properly reported in early LLVM and we don't need them
-target_compile_options( prepare_builtins PRIVATE -fno-rtti -fno-exceptions )
+# Configure prepare_builtins
+add_subdirectory(utils)
wenju-he wrote:
same here, spaces before and after
https://github.com/llvm/llvm-project/pull/148815
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move CMake for prepare_builtins to a subdirectory (PR #148815)
@@ -0,0 +1,24 @@
+# Construct LLVM version define
+set( LLVM_VERSION_DEFINE
"-DHAVE_LLVM=0x${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}" )
+
+# Setup prepare_builtins tools
+set(LLVM_LINK_COMPONENTS
wenju-he wrote:
add a space after `(` to align with the style in libclc?
https://github.com/llvm/llvm-project/pull/148815
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Add IgnoreExtension to SortIncludes (PR #137840)
https://github.com/HazardyKnusperkeks approved this pull request. https://github.com/llvm/llvm-project/pull/137840 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
https://github.com/OCHyams edited https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,46 @@ +# Key Instructions in Clang + +Key Instructions is an LLVM feature that reduces the jumpiness of optimized code debug stepping. This document explains how Clang applies the necessary metadata. OCHyams wrote: Couldn't find better wording than yours, how does this look? I fear it's become a little bit of a word salad. https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
https://github.com/OCHyams commented: Thanks for for the comments, I think I've addressed everything. I've merged both files into the LLVM docs as I couldn't get a link to the Clang docs working properly. How does this look? https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,114 @@ +# Key Instructions debug info in LLVM + +Key Instructions reduces the jumpiness of optimized code debug stepping. This document explains the feature and how it is implemented in LLVM. For Clang support please see the [Clang docs](../../clang/docs/KeyInstructionsClang.md) + +## Status + +In development, but mostly complete. The feature is currently disabled for coroutines. + +Tell Clang [not] to produce Key Instructions metadata with `-g[no-]key-instructions`. See the Clang docs for implementation info. + +The feature improves optimized code stepping; it's intended for the feature to be used with optimisations enabled. Although the feature works at O0 it is not recommended because in some cases the effect of editing variables may not always be immediately realised. (This is a quirk of the current implementation, rather than fundemental limitation, covered in more detail later). + +This is a DWARF-based feature. There is currently no plan to support CodeView. + +Set LLVM flag `-dwarf-use-key-instructions` to `false` to ignore Key Instructions metadata when emitting DWARF. + +## Problem statement + +A lot of the noise in stepping comes from code motion and instruction scheduling. Consider a long expression on a single line. It may involve multiple operations that optimisations move, re-order, and interleave with other instructions that have different line numbers. + +DWARF provides a helpful tool the compiler can employ to mitigate this jumpiness, the `is_stmt` flag, which indicates that an instruction is a recommended breakpoint location. However, LLVM's current approach to deciding `is_stmt` placement essentially reduces down to "is the associated line number different to the previous instruction's?". + +(Note: It's up to the debugger if it wants to interpret `is_stmt` or not, and at time of writing LLDB doesn't; possibly because until now LLVM's is_stmts convey no information that can't already be deduced from the rest of the line table.) + +## Solution overview + +Taking ideas from two papers [1][2] that explore the issue, especially C. Tice's: + +From the perspective of a source-level debugger user: + +* Source code is made up of interesting constructs; the level of granularity for “interesting” while stepping is typically assignments, calls, control flow. We’ll call these interesting constructs Atoms. + +* Atoms usually have one instruction that implements the functionality that a user can observe; once they step “off” that instruction, the atom is finalised. We’ll call that a Key Instruction. + +* Communicating where the key instructions are to the debugger (using DWARF’s is_stmt) avoids jumpiness introduced by scheduling non-key instructions without losing source attribution (because non-key instructions retain an associated source location, they’re just ignored for stepping). + +## Solution implementation + +1. `DILocation` has 2 new fields, `atomGroup` and `atomRank`. `DISubprogram` has a new field `keyInstructions`. +2. Clang creates `DILocations` using the new fields to communicate which instructions are "interesting", and sets `keyInstructions` true in `DISubprogram`s to tell LLVM to interpret the new metadata in those functions. +3. There’s some bookkeeping required by optimisations that duplicate control flow. +4. During DWARF emission, the new metadata is collected (linear scan over instructions) to decide `is_stmt` placements. + +1. *The metadata* - The two new `DILocation` fields are `atomGroup` and `atomRank` and are both are unsigned integers. `atomGroup` is 61 bits and `atomRank` 3 bits. Instructions in the same function with the same `(atomGroup, inlinedAt)` pair are part of the same source atom. `atomRank` determines `is_stmt` preference within that group, where a lower number is higher precedence. Higher rank instructions act as "backup" `is_stmt` locations, providing good fallback locations if/when the primary candidate gets optimized away. The default values of 0 indicate the instruction isn’t interesting - it's not an `is_stmt` candidate. If `keyInstructions` in `DISubprogram` is false (default) then the new `DILocation` metadata is ignored for the function (including inlined instances) when emitting DWARF. + +2. *Clang annotates key instructions* with the new metadata. Variable assignments (stores, memory intrinsics), control flow (branches and their conditions, some unconditional branches), and exception handling instructions are annotated. Calls are ignored as they're unconditionally marked is_stmt. + +3. *Throughout optimisation*, the `DILocation` is propagated normally. Cloned instructions get the original’s `DILocation`, the new fields get merged in `getMergedLocation`, etc. However, pass writers need to intercede in cases where a code path is duplicated, e.g. unrolling, jump-threading. In these cases we want to emit key instructions in both the original and duplicated code, so the duplicate
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,114 @@ +# Key Instructions debug info in LLVM + +Key Instructions reduces the jumpiness of optimized code debug stepping. This document explains the feature and how it is implemented in LLVM. For Clang support please see the [Clang docs](../../clang/docs/KeyInstructionsClang.md) + +## Status + +In development, but mostly complete. The feature is currently disabled for coroutines. OCHyams wrote: I guess it essentially is "random"; it's just that at the time of writing, and the branch date, I haven't got to them yet. There's no fundamental reason why they're not supported and we intend to get to them soon. Mixing functions with different key-instructions-modes is fully supported - it just means currently coros use the non-key-instructions handling. I've added a bit to the sentence, how does this sound? https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,46 @@ +# Key Instructions in Clang + +Key Instructions is an LLVM feature that reduces the jumpiness of optimized code debug stepping. This document explains how Clang applies the necessary metadata. + +## Implementation + +See the [LLVM docs](../../llvm/docs/KeyInstructionsDebugInfo.md) for general info about the feature (and LLVM implementation details). + +Clang needs to annotate key instructions with the new metadata. Variable assignments (stores, memory intrinsics), control flow (branches and their conditions, some unconditional branches), and exception handling instructions are annotated. Calls are ignored as they're unconditionally marked `is_stmt`. This is achieved with a few simple constructs: + +Class `ApplyAtomGroup` - This is a scoped helper similar to `ApplyDebugLocation` that creates a new source atom group which instructions can be added to. It's used during CodeGen to declare that a new source atom has started, e.g. in `CodeGenFunction::EmitBinaryOperatorLValue`. + +`CodeGenFunction::addInstToCurrentSourceAtom(llvm::Instruction *KeyInstruction, llvm::Value *Backup)` adds an instruction (and a backup instruction if non-null) to the current "atom group" defined with `ApplyAtomGroup`. The Key Instruction gets rank 1, and backup instructions get higher ranks (the function looks through casts, applying increasing rank as it goes). There are a lot of sites in Clang that need to call this (mostly stores and store-like instructions). FIXME?: Currently it's called at the CGBuilderTy callsites; it could instead make sense to always call the function inside the CGBuilderTy calls, with some calls opting out. OCHyams wrote: Done https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,114 @@ +# Key Instructions debug info in LLVM + +Key Instructions reduces the jumpiness of optimized code debug stepping. This document explains the feature and how it is implemented in LLVM. For Clang support please see the [Clang docs](../../clang/docs/KeyInstructionsClang.md) + +## Status + +In development, but mostly complete. The feature is currently disabled for coroutines. + +Tell Clang [not] to produce Key Instructions metadata with `-g[no-]key-instructions`. See the Clang docs for implementation info. + +The feature improves optimized code stepping; it's intended for the feature to be used with optimisations enabled. Although the feature works at O0 it is not recommended because in some cases the effect of editing variables may not always be immediately realised. (This is a quirk of the current implementation, rather than fundemental limitation, covered in more detail later). + +This is a DWARF-based feature. There is currently no plan to support CodeView. + +Set LLVM flag `-dwarf-use-key-instructions` to `false` to ignore Key Instructions metadata when emitting DWARF. + +## Problem statement + +A lot of the noise in stepping comes from code motion and instruction scheduling. Consider a long expression on a single line. It may involve multiple operations that optimisations move, re-order, and interleave with other instructions that have different line numbers. + +DWARF provides a helpful tool the compiler can employ to mitigate this jumpiness, the `is_stmt` flag, which indicates that an instruction is a recommended breakpoint location. However, LLVM's current approach to deciding `is_stmt` placement essentially reduces down to "is the associated line number different to the previous instruction's?". + +(Note: It's up to the debugger if it wants to interpret `is_stmt` or not, and at time of writing LLDB doesn't; possibly because until now LLVM's is_stmts convey no information that can't already be deduced from the rest of the line table.) + +## Solution overview + +Taking ideas from two papers [1][2] that explore the issue, especially C. Tice's: + +From the perspective of a source-level debugger user: + +* Source code is made up of interesting constructs; the level of granularity for “interesting” while stepping is typically assignments, calls, control flow. We’ll call these interesting constructs Atoms. + +* Atoms usually have one instruction that implements the functionality that a user can observe; once they step “off” that instruction, the atom is finalised. We’ll call that a Key Instruction. + +* Communicating where the key instructions are to the debugger (using DWARF’s is_stmt) avoids jumpiness introduced by scheduling non-key instructions without losing source attribution (because non-key instructions retain an associated source location, they’re just ignored for stepping). + +## Solution implementation + +1. `DILocation` has 2 new fields, `atomGroup` and `atomRank`. `DISubprogram` has a new field `keyInstructions`. +2. Clang creates `DILocations` using the new fields to communicate which instructions are "interesting", and sets `keyInstructions` true in `DISubprogram`s to tell LLVM to interpret the new metadata in those functions. +3. There’s some bookkeeping required by optimisations that duplicate control flow. +4. During DWARF emission, the new metadata is collected (linear scan over instructions) to decide `is_stmt` placements. + +1. *The metadata* - The two new `DILocation` fields are `atomGroup` and `atomRank` and are both are unsigned integers. `atomGroup` is 61 bits and `atomRank` 3 bits. Instructions in the same function with the same `(atomGroup, inlinedAt)` pair are part of the same source atom. `atomRank` determines `is_stmt` preference within that group, where a lower number is higher precedence. Higher rank instructions act as "backup" `is_stmt` locations, providing good fallback locations if/when the primary candidate gets optimized away. The default values of 0 indicate the instruction isn’t interesting - it's not an `is_stmt` candidate. If `keyInstructions` in `DISubprogram` is false (default) then the new `DILocation` metadata is ignored for the function (including inlined instances) when emitting DWARF. + +2. *Clang annotates key instructions* with the new metadata. Variable assignments (stores, memory intrinsics), control flow (branches and their conditions, some unconditional branches), and exception handling instructions are annotated. Calls are ignored as they're unconditionally marked is_stmt. OCHyams wrote: Done https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,46 @@ +# Key Instructions in Clang + +Key Instructions is an LLVM feature that reduces the jumpiness of optimized code debug stepping. This document explains how Clang applies the necessary metadata. + +## Implementation + +See the [LLVM docs](../../llvm/docs/KeyInstructionsDebugInfo.md) for general info about the feature (and LLVM implementation details). + +Clang needs to annotate key instructions with the new metadata. Variable assignments (stores, memory intrinsics), control flow (branches and their conditions, some unconditional branches), and exception handling instructions are annotated. Calls are ignored as they're unconditionally marked `is_stmt`. This is achieved with a few simple constructs: + +Class `ApplyAtomGroup` - This is a scoped helper similar to `ApplyDebugLocation` that creates a new source atom group which instructions can be added to. It's used during CodeGen to declare that a new source atom has started, e.g. in `CodeGenFunction::EmitBinaryOperatorLValue`. + +`CodeGenFunction::addInstToCurrentSourceAtom(llvm::Instruction *KeyInstruction, llvm::Value *Backup)` adds an instruction (and a backup instruction if non-null) to the current "atom group" defined with `ApplyAtomGroup`. The Key Instruction gets rank 1, and backup instructions get higher ranks (the function looks through casts, applying increasing rank as it goes). There are a lot of sites in Clang that need to call this (mostly stores and store-like instructions). FIXME?: Currently it's called at the CGBuilderTy callsites; it could instead make sense to always call the function inside the CGBuilderTy calls, with some calls opting out. + +`CodeGenFunction::addInstToNewSourceAtom(llvm::Instruction *KeyInstruction, llvm::Value *Backup)` adds an instruction (and a backup instruction if non-null) to a new "atom group". Currently mostly used in loop handling code. + +There are a couple of other helpers, including `addInstToSpecificSourceAtom` used for `rets` which is covered in the examples below. OCHyams wrote: Deleted that part, not sure what other functions I was alluding to. How does the new para sound? https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,114 @@ +# Key Instructions debug info in LLVM + +Key Instructions reduces the jumpiness of optimized code debug stepping. This document explains the feature and how it is implemented in LLVM. For Clang support please see the [Clang docs](../../clang/docs/KeyInstructionsClang.md) + +## Status + +In development, but mostly complete. The feature is currently disabled for coroutines. + +Tell Clang [not] to produce Key Instructions metadata with `-g[no-]key-instructions`. See the Clang docs for implementation info. + +The feature improves optimized code stepping; it's intended for the feature to be used with optimisations enabled. Although the feature works at O0 it is not recommended because in some cases the effect of editing variables may not always be immediately realised. (This is a quirk of the current implementation, rather than fundemental limitation, covered in more detail later). + +This is a DWARF-based feature. There is currently no plan to support CodeView. + +Set LLVM flag `-dwarf-use-key-instructions` to `false` to ignore Key Instructions metadata when emitting DWARF. + +## Problem statement + +A lot of the noise in stepping comes from code motion and instruction scheduling. Consider a long expression on a single line. It may involve multiple operations that optimisations move, re-order, and interleave with other instructions that have different line numbers. + +DWARF provides a helpful tool the compiler can employ to mitigate this jumpiness, the `is_stmt` flag, which indicates that an instruction is a recommended breakpoint location. However, LLVM's current approach to deciding `is_stmt` placement essentially reduces down to "is the associated line number different to the previous instruction's?". + +(Note: It's up to the debugger if it wants to interpret `is_stmt` or not, and at time of writing LLDB doesn't; possibly because until now LLVM's is_stmts convey no information that can't already be deduced from the rest of the line table.) OCHyams wrote: Done https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,114 @@ +# Key Instructions debug info in LLVM + +Key Instructions reduces the jumpiness of optimized code debug stepping. This document explains the feature and how it is implemented in LLVM. For Clang support please see the [Clang docs](../../clang/docs/KeyInstructionsClang.md) + +## Status + +In development, but mostly complete. The feature is currently disabled for coroutines. + +Tell Clang [not] to produce Key Instructions metadata with `-g[no-]key-instructions`. See the Clang docs for implementation info. + +The feature improves optimized code stepping; it's intended for the feature to be used with optimisations enabled. Although the feature works at O0 it is not recommended because in some cases the effect of editing variables may not always be immediately realised. (This is a quirk of the current implementation, rather than fundemental limitation, covered in more detail later). OCHyams wrote: Done https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,114 @@ +# Key Instructions debug info in LLVM + +Key Instructions reduces the jumpiness of optimized code debug stepping. This document explains the feature and how it is implemented in LLVM. For Clang support please see the [Clang docs](../../clang/docs/KeyInstructionsClang.md) + +## Status + +In development, but mostly complete. The feature is currently disabled for coroutines. + +Tell Clang [not] to produce Key Instructions metadata with `-g[no-]key-instructions`. See the Clang docs for implementation info. + +The feature improves optimized code stepping; it's intended for the feature to be used with optimisations enabled. Although the feature works at O0 it is not recommended because in some cases the effect of editing variables may not always be immediately realised. (This is a quirk of the current implementation, rather than fundemental limitation, covered in more detail later). + +This is a DWARF-based feature. There is currently no plan to support CodeView. + +Set LLVM flag `-dwarf-use-key-instructions` to `false` to ignore Key Instructions metadata when emitting DWARF. + +## Problem statement + +A lot of the noise in stepping comes from code motion and instruction scheduling. Consider a long expression on a single line. It may involve multiple operations that optimisations move, re-order, and interleave with other instructions that have different line numbers. + +DWARF provides a helpful tool the compiler can employ to mitigate this jumpiness, the `is_stmt` flag, which indicates that an instruction is a recommended breakpoint location. However, LLVM's current approach to deciding `is_stmt` placement essentially reduces down to "is the associated line number different to the previous instruction's?". + +(Note: It's up to the debugger if it wants to interpret `is_stmt` or not, and at time of writing LLDB doesn't; possibly because until now LLVM's is_stmts convey no information that can't already be deduced from the rest of the line table.) + +## Solution overview + +Taking ideas from two papers [1][2] that explore the issue, especially C. Tice's: + +From the perspective of a source-level debugger user: + +* Source code is made up of interesting constructs; the level of granularity for “interesting” while stepping is typically assignments, calls, control flow. We’ll call these interesting constructs Atoms. + +* Atoms usually have one instruction that implements the functionality that a user can observe; once they step “off” that instruction, the atom is finalised. We’ll call that a Key Instruction. + +* Communicating where the key instructions are to the debugger (using DWARF’s is_stmt) avoids jumpiness introduced by scheduling non-key instructions without losing source attribution (because non-key instructions retain an associated source location, they’re just ignored for stepping). + +## Solution implementation + +1. `DILocation` has 2 new fields, `atomGroup` and `atomRank`. `DISubprogram` has a new field `keyInstructions`. +2. Clang creates `DILocations` using the new fields to communicate which instructions are "interesting", and sets `keyInstructions` true in `DISubprogram`s to tell LLVM to interpret the new metadata in those functions. +3. There’s some bookkeeping required by optimisations that duplicate control flow. +4. During DWARF emission, the new metadata is collected (linear scan over instructions) to decide `is_stmt` placements. + +1. *The metadata* - The two new `DILocation` fields are `atomGroup` and `atomRank` and are both are unsigned integers. `atomGroup` is 61 bits and `atomRank` 3 bits. Instructions in the same function with the same `(atomGroup, inlinedAt)` pair are part of the same source atom. `atomRank` determines `is_stmt` preference within that group, where a lower number is higher precedence. Higher rank instructions act as "backup" `is_stmt` locations, providing good fallback locations if/when the primary candidate gets optimized away. The default values of 0 indicate the instruction isn’t interesting - it's not an `is_stmt` candidate. If `keyInstructions` in `DISubprogram` is false (default) then the new `DILocation` metadata is ignored for the function (including inlined instances) when emitting DWARF. OCHyams wrote: Ah, good catch and yes you're right. I've done a local build to fix link problems etc too. https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,114 @@ +# Key Instructions debug info in LLVM + +Key Instructions reduces the jumpiness of optimized code debug stepping. This document explains the feature and how it is implemented in LLVM. For Clang support please see the [Clang docs](../../clang/docs/KeyInstructionsClang.md) OCHyams wrote: (replied to the comment on the other doc - resolving this one to keep it in one place) https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,46 @@
+# Key Instructions in Clang
+
+Key Instructions is an LLVM feature that reduces the jumpiness of optimized
code debug stepping. This document explains how Clang applies the necessary
metadata.
+
+## Implementation
+
+See the [LLVM docs](../../llvm/docs/KeyInstructionsDebugInfo.md) for general
info about the feature (and LLVM implementation details).
+
+Clang needs to annotate key instructions with the new metadata. Variable
assignments (stores, memory intrinsics), control flow (branches and their
conditions, some unconditional branches), and exception handling instructions
are annotated. Calls are ignored as they're unconditionally marked `is_stmt`.
This is achieved with a few simple constructs:
+
+Class `ApplyAtomGroup` - This is a scoped helper similar to
`ApplyDebugLocation` that creates a new source atom group which instructions
can be added to. It's used during CodeGen to declare that a new source atom has
started, e.g. in `CodeGenFunction::EmitBinaryOperatorLValue`.
+
+`CodeGenFunction::addInstToCurrentSourceAtom(llvm::Instruction
*KeyInstruction, llvm::Value *Backup)` adds an instruction (and a backup
instruction if non-null) to the current "atom group" defined with
`ApplyAtomGroup`. The Key Instruction gets rank 1, and backup instructions get
higher ranks (the function looks through casts, applying increasing rank as it
goes). There are a lot of sites in Clang that need to call this (mostly stores
and store-like instructions). FIXME?: Currently it's called at the CGBuilderTy
callsites; it could instead make sense to always call the function inside the
CGBuilderTy calls, with some calls opting out.
+
+`CodeGenFunction::addInstToNewSourceAtom(llvm::Instruction *KeyInstruction,
llvm::Value *Backup)` adds an instruction (and a backup instruction if
non-null) to a new "atom group". Currently mostly used in loop handling code.
+
+There are a couple of other helpers, including `addInstToSpecificSourceAtom`
used for `rets` which is covered in the examples below.
+
+## Examples
+
+A simple example walk through:
+```
+void fun(int a) {
+ int b = a;
+}
+```
+
+There are two key instructions here, the assignment and the implicit return.
We want to emit metadata that looks like this:
+
+```
+define hidden void @_Z3funi(i32 noundef %a) #0 !dbg !11 {
+entry:
+ %a.addr = alloca i32, align 4
+ %b = alloca i32, align 4
+ store i32 %a, ptr %a.addr, align 4
+ %0 = load i32, ptr %a.addr, align 4, !dbg !DILocation(line: 2, scope: !11,
atomGroup: 1, atomRank: 2)
+ store i32 %0, ptr %b, align 4, !dbg !DILocation(line: 2, scope: !11,
atomGroup: 1, atomRank: 1)
+ ret void,!dbg !DILocation(line: 3, scope: !11,
atomGroup: 2, atomRank: 1)
+}
+```
+
+The store is the key instruction for the assignment (`atomGroup` 1). The
instruction corresponding to the final (and in this case only) RHS value, the
load from `%a.addr`, is a good backup location for `is_stmt` if the store gets
optimized away. It's part of the same source atom, but has lower `is_stmt`
precedence, so it gets a higher `atomRank`.
+
+The implicit return is also key (`atomGroup` 2) so that it's stepped on, to
match existing non-key-instructions behaviour. This is achieved by calling
`addInstToNewSourceAtom` from within `EmitFunctionEpilog`.
+
+Explicit return statements are handled uniquely. Rather than emit a `ret` for
each `return` Clang, in all but the simplest cases (as in the first example)
emits a branch to a dedicated block with a single `ret`. That branch is the key
instruction for the return statement. If there's only one branch to that block,
because there's only one `return` (as in this example), Clang folds the block
into its only predecessor. Handily `EmitReturnBlock` returns the `DebugLoc`
associated with the single branch in that case, which is fed into
`addInstToSpecificSourceAtom` to ensure the `ret` gets the right group.
OCHyams wrote:
I did that in the para above, or are you referring to something else?
https://github.com/llvm/llvm-project/pull/137991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,114 @@ +# Key Instructions debug info in LLVM + +Key Instructions reduces the jumpiness of optimized code debug stepping. This document explains the feature and how it is implemented in LLVM. For Clang support please see the [Clang docs](../../clang/docs/KeyInstructionsClang.md) + +## Status + +In development, but mostly complete. The feature is currently disabled for coroutines. + +Tell Clang [not] to produce Key Instructions metadata with `-g[no-]key-instructions`. See the Clang docs for implementation info. + +The feature improves optimized code stepping; it's intended for the feature to be used with optimisations enabled. Although the feature works at O0 it is not recommended because in some cases the effect of editing variables may not always be immediately realised. (This is a quirk of the current implementation, rather than fundemental limitation, covered in more detail later). OCHyams wrote: How does this look? https://github.com/llvm/llvm-project/pull/137991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
@@ -0,0 +1,46 @@
+# Key Instructions in Clang
+
+Key Instructions is an LLVM feature that reduces the jumpiness of optimized
code debug stepping. This document explains how Clang applies the necessary
metadata.
+
+## Implementation
+
+See the [LLVM docs](../../llvm/docs/KeyInstructionsDebugInfo.md) for general
info about the feature (and LLVM implementation details).
+
+Clang needs to annotate key instructions with the new metadata. Variable
assignments (stores, memory intrinsics), control flow (branches and their
conditions, some unconditional branches), and exception handling instructions
are annotated. Calls are ignored as they're unconditionally marked `is_stmt`.
This is achieved with a few simple constructs:
+
+Class `ApplyAtomGroup` - This is a scoped helper similar to
`ApplyDebugLocation` that creates a new source atom group which instructions
can be added to. It's used during CodeGen to declare that a new source atom has
started, e.g. in `CodeGenFunction::EmitBinaryOperatorLValue`.
+
+`CodeGenFunction::addInstToCurrentSourceAtom(llvm::Instruction
*KeyInstruction, llvm::Value *Backup)` adds an instruction (and a backup
instruction if non-null) to the current "atom group" defined with
`ApplyAtomGroup`. The Key Instruction gets rank 1, and backup instructions get
higher ranks (the function looks through casts, applying increasing rank as it
goes). There are a lot of sites in Clang that need to call this (mostly stores
and store-like instructions). FIXME?: Currently it's called at the CGBuilderTy
callsites; it could instead make sense to always call the function inside the
CGBuilderTy calls, with some calls opting out.
+
+`CodeGenFunction::addInstToNewSourceAtom(llvm::Instruction *KeyInstruction,
llvm::Value *Backup)` adds an instruction (and a backup instruction if
non-null) to a new "atom group". Currently mostly used in loop handling code.
+
+There are a couple of other helpers, including `addInstToSpecificSourceAtom`
used for `rets` which is covered in the examples below.
+
+## Examples
+
+A simple example walk through:
+```
+void fun(int a) {
+ int b = a;
+}
+```
+
+There are two key instructions here, the assignment and the implicit return.
We want to emit metadata that looks like this:
+
+```
+define hidden void @_Z3funi(i32 noundef %a) #0 !dbg !11 {
+entry:
+ %a.addr = alloca i32, align 4
+ %b = alloca i32, align 4
+ store i32 %a, ptr %a.addr, align 4
+ %0 = load i32, ptr %a.addr, align 4, !dbg !DILocation(line: 2, scope: !11,
atomGroup: 1, atomRank: 2)
+ store i32 %0, ptr %b, align 4, !dbg !DILocation(line: 2, scope: !11,
atomGroup: 1, atomRank: 1)
+ ret void,!dbg !DILocation(line: 3, scope: !11,
atomGroup: 2, atomRank: 1)
+}
+```
+
+The store is the key instruction for the assignment (`atomGroup` 1). The
instruction corresponding to the final (and in this case only) RHS value, the
load from `%a.addr`, is a good backup location for `is_stmt` if the store gets
optimized away. It's part of the same source atom, but has lower `is_stmt`
precedence, so it gets a higher `atomRank`.
OCHyams wrote:
SGTM, Done
https://github.com/llvm/llvm-project/pull/137991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR] Upstream the basic structure of LoweringPrepare pass (PR #148545)
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lldb-arm-ubuntu` running
on `linaro-lldb-arm-ubuntu` while building `clang` at step 6 "test".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/18/builds/19024
Here is the relevant piece of the build log for the reference
```
Step 6 (test) failure: build (failure)
...
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests/4/12 (3327 of 3336)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests/5/12 (3328 of 3336)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests/6/12 (3329 of 3336)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests/7/12 (3330 of 3336)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests/8/12 (3331 of 3336)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests/9/12 (3332 of 3336)
PASS: lldb-unit :: tools/lldb-server/tests/./LLDBServerTests/1/2 ( of 3336)
PASS: lldb-unit :: tools/lldb-server/tests/./LLDBServerTests/0/2 (3334 of 3336)
PASS: lldb-unit :: Process/gdb-remote/./ProcessGdbRemoteTests/8/35 (3335 of
3336)
TIMEOUT: lldb-api :: tools/lldb-dap/module/TestDAP_module.py (3336 of 3336)
TEST 'lldb-api :: tools/lldb-dap/module/TestDAP_module.py'
FAILED
Script:
--
/usr/bin/python3.10
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/test/API/dotest.py
-u CXXFLAGS -u CFLAGS --env
LLVM_LIBS_DIR=/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./lib --env
LLVM_INCLUDE_DIR=/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/include --env
LLVM_TOOLS_DIR=/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin --arch
armv8l --build-dir
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/lldb-test-build.noindex
--lldb-module-cache-dir
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/lldb-test-build.noindex/module-cache-lldb/lldb-api
--clang-module-cache-dir
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/lldb-test-build.noindex/module-cache-clang/lldb-api
--executable /home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin/lldb
--compiler /home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin/clang
--dsymutil /home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin/dsymutil
--make /usr/bin/gmake --llvm-tools-dir
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin --lldb-obj-root
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/tools/lldb --lldb-libs-dir
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./lib --cmake-build-type
Release
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/test/API/tools/lldb-dap/module
-p TestDAP_module.py
--
Exit Code: -9
Timeout: Reached timeout of 600 seconds
Command Output (stdout):
--
lldb version 21.0.0git (https://github.com/llvm/llvm-project.git revision
af99f18d91a440504f2e375ee78a2a744e39ab65)
clang revision af99f18d91a440504f2e375ee78a2a744e39ab65
llvm revision af99f18d91a440504f2e375ee78a2a744e39ab65
--
Command Output (stderr):
--
= DEBUG ADAPTER PROTOCOL LOGS =
1752576825.175458193 (stdio) -->
{"command":"initialize","type":"request","arguments":{"adapterID":"lldb-native","clientID":"vscode","columnsStartAt1":true,"linesStartAt1":true,"locale":"en-us","pathFormat":"path","supportsRunInTerminalRequest":true,"supportsVariablePaging":true,"supportsVariableType":true,"supportsStartDebuggingRequest":true,"supportsProgressReporting":true,"$__lldb_sourceInitFile":false},"seq":1}
1752576825.181397915 (stdio) <-- {"body":{"$__lldb_version":"lldb version
21.0.0git (https://github.com/llvm/llvm-project.git revision
af99f18d91a440504f2e375ee78a2a744e39ab65)\n clang revision
af99f18d91a440504f2e375ee78a2a744e39ab65\n llvm revision
af99f18d91a440504f2e375ee78a2a744e39ab65","completionTriggerCharacters":[".","
","\t"],"exceptionBreakpointFilters":[{"description":"C++
Catch","filter":"cpp_catch","label":"C++
Catch","supportsCondition":true},{"description":"C++
Throw","filter":"cpp_throw","label":"C++
Throw","supportsCondition":true},{"description":"Objective-C
Catch","filter":"objc_catch","label":"Objective-C
Catch","supportsCondition":true},{"description":"Objective-C
Throw","filter":"objc_throw","label":"Objective-C
Throw","supportsCondition":true}],"supportTerminateDebuggee":true,"supportsBreakpointLocationsRequest":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsDisassembleRequest":true,"supportsEvaluateForHovers":true,"supportsExceptionFilterOptions":true,"supportsExceptionInfoRequest":true,"supportsFunctionBreakpoints":true,"supportsHitConditionalBreakpoints":true,"supportsInstructionBreakpoints":true,"supportsLogPoints":true,"supportsModulesRequest":true,"supportsReadMemoryRequest":true,"supportsSetVariable":true,"supportsSteppingGranularity":true,"supportsValueFormattingOptions":true,"supportsWriteMemoryRequest":true},"command":"initialize","request_seq":1,"seq":0,"s
[clang] [clang] Reduce the size of ParsedAttributesView and AttributePool (PR #148726)
https://github.com/AaronBallman approved this pull request. LGTM, thank you! https://github.com/llvm/llvm-project/pull/148726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [KeyInstr] Add docs (PR #137991)
https://github.com/OCHyams updated https://github.com/llvm/llvm-project/pull/137991 >From cb89d1f1bb60db07743f1973f9b263424fab9f6d Mon Sep 17 00:00:00 2001 From: Orlando Cazalet-Hyams Date: Wed, 30 Apr 2025 15:19:03 +0100 Subject: [PATCH 1/8] [KeyInstr] Add docs --- clang/docs/KeyInstructionsClang.md| 25 ++ llvm/docs/KeyInstructionsDebugInfo.md | 114 ++ 2 files changed, 139 insertions(+) create mode 100644 clang/docs/KeyInstructionsClang.md create mode 100644 llvm/docs/KeyInstructionsDebugInfo.md diff --git a/clang/docs/KeyInstructionsClang.md b/clang/docs/KeyInstructionsClang.md new file mode 100644 index 0..fa9dd11033d2d --- /dev/null +++ b/clang/docs/KeyInstructionsClang.md @@ -0,0 +1,25 @@ +# Key Instructions in Clang + +Key Instructions reduces the jumpiness of optimized code debug stepping. This document explains the feature and how it is implemented in LLVM. For Clang support please see the Clang docs. + +## Status + +In development - some details may change with little notice. + +Tell Clang [not] to produce Key Instructions metadata with `-g[no-]key-instructions`. This also sets the LLVM flag `-dwarf-use-key-instructions`, so it interprets Key Instructions metadata when producing the DWARF line table. + +The feature improves optimized code stepping; it's intended for the feature to be used with optimisations enabled. Although the feature works at O0 it is not recommended because in some cases the effect of editing variables may not always be immediately realised. (This is a quirk of the current implementation, rather than fundemental limitation, covered in more detail later). + +There is currently no plan to support CodeView. + +## Implementation + +See the [LLVM docs](../../llvm/docs/KeyInstructionsDebugInfo.md) for general info about the feature (and LLVM implementation details). + +Clang needs to annotate key instructions with the new metadata. Variable assignments (stores, memory intrinsics), control flow (branches and their conditions, some unconditional branches), and exception handling instructions are annotated. Calls are ignored as they're unconditionally marked `is_stmt`. This is achieved with a few simple constructs: + +Class `ApplyAtomGroup` - This is a scoped helper similar to `ApplyDebugLocation` that creates a new source atom group which instructions can be added to. It's used during CodeGen to declare that a new source atom has started, e.g. in `CodeGenFunction::EmitBinaryOperatorLValue`. + +`CodeGenFunction::addInstToCurrentSourceAtom(llvm::Instruction *KeyInstruction, llvm::Value *Backup)` adds an instruction (and a backup instruction if non-null) to the current "atom group" defined with `ApplyAtomGroup`. The Key Instruction gets rank 1, and backup instructions get higher ranks (the function looks through casts, applying increasing rank as it goes). There are a lot of sites in Clang that need to call this (mostly stores and store-like instructions). FIXME?: Currently it's called at the CGBuilderTy callsites; it could instead make sense to always call the function inside the CGBuilderTy calls, with some calls opting out. + +`CodeGenFunction::addInstToNewSourceAtom(llvm::Instruction *KeyInstruction, llvm::Value *Backup)` adds an instruction (and a backup instruction if non-null) to a new "atom group". Currently mostly used in loop handling code. diff --git a/llvm/docs/KeyInstructionsDebugInfo.md b/llvm/docs/KeyInstructionsDebugInfo.md new file mode 100644 index 0..1b2acfb2bfb29 --- /dev/null +++ b/llvm/docs/KeyInstructionsDebugInfo.md @@ -0,0 +1,114 @@ +# Key Instructions debug info in LLVM + +Key Instructions reduces the jumpiness of optimized code debug stepping. This document explains the feature and how it is implemented in LLVM. For Clang support please see the Clang docs. + +## Status + +In development - some details may change with little notice. + +Tell Clang [not] to produce Key Instructions metadata with `-g[no-]key-instructions`. See the Clang docs for implementation info. + +Use LLVM flag `-dwarf-use-key-instructions` to interpret Key Instructions metadata when producing the DWARF line table (Clang passes the flag to LLVM). The behaviour of this flag may change. + +The feature improves optimized code stepping; it's intended for the feature to be used with optimisations enabled. Although the feature works at O0 it is not recommended because in some cases the effect of editing variables may not always be immediately realised. (This is a quirk of the current implementation, rather than fundemental limitation, covered in more detail later). + +There is currently no plan to support CodeView. + +## Problem statement + +A lot of the noise in stepping comes from code motion and instruction scheduling. Consider a long expression on a single line. It may involve multiple operations that optimisations move, re-order, and interleave with other instructions that have different
[clang-tools-extra] [clang-tidy] added `RespectOpaqueTypes` option to `readability-qualified-auto check` (PR #147060)
https://github.com/JuanBesa updated
https://github.com/llvm/llvm-project/pull/147060
>From d176aa31c18a4293be9b49da671270d349a323b7 Mon Sep 17 00:00:00 2001
From: juanbesa
Date: Thu, 26 Jun 2025 07:42:55 -0700
Subject: [PATCH 1/5] Copied over everything
---
.../readability/QualifiedAutoCheck.cpp| 19 +-
.../readability/QualifiedAutoCheck.h | 1 +
.../readability/qualified-auto-opaque.cpp | 239 ++
3 files changed, 258 insertions(+), 1 deletion(-)
create mode 100644
clang-tools-extra/test/clang-tidy/checkers/readability/qualified-auto-opaque.cpp
diff --git a/clang-tools-extra/clang-tidy/readability/QualifiedAutoCheck.cpp
b/clang-tools-extra/clang-tidy/readability/QualifiedAutoCheck.cpp
index 91a08b9d8de69..d5d2163f83679 100644
--- a/clang-tools-extra/clang-tidy/readability/QualifiedAutoCheck.cpp
+++ b/clang-tools-extra/clang-tidy/readability/QualifiedAutoCheck.cpp
@@ -106,12 +106,14 @@ QualifiedAutoCheck::QualifiedAutoCheck(StringRef Name,
: ClangTidyCheck(Name, Context),
AddConstToQualified(Options.get("AddConstToQualified", true)),
AllowedTypes(
- utils::options::parseStringList(Options.get("AllowedTypes", ""))) {}
+ utils::options::parseStringList(Options.get("AllowedTypes", ""))),
+ RespectOpaqueTypes(Options.get("RespectOpaqueTypes", false)) {}
void QualifiedAutoCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) {
Options.store(Opts, "AddConstToQualified", AddConstToQualified);
Options.store(Opts, "AllowedTypes",
utils::options::serializeStringList(AllowedTypes));
+ Options.store(Opts, "RespectOpaqueTypes", RespectOpaqueTypes);
}
void QualifiedAutoCheck::registerMatchers(MatchFinder *Finder) {
@@ -174,6 +176,21 @@ void QualifiedAutoCheck::registerMatchers(MatchFinder
*Finder) {
void QualifiedAutoCheck::check(const MatchFinder::MatchResult &Result) {
if (const auto *Var = Result.Nodes.getNodeAs("auto")) {
+if (RespectOpaqueTypes) {
+ auto DeducedType =
+ Var->getType()->getContainedAutoType()->getDeducedType();
+
+ // Remove one sugar if the type if part of a template
+ if (llvm::isa(DeducedType)) {
+DeducedType =
+DeducedType->getLocallyUnqualifiedSingleStepDesugaredType();
+ }
+
+ if (!isa(DeducedType)) {
+return;
+ }
+}
+
SourceRange TypeSpecifier;
if (std::optional TypeSpec =
getTypeSpecifierLocation(Var, Result)) {
diff --git a/clang-tools-extra/clang-tidy/readability/QualifiedAutoCheck.h
b/clang-tools-extra/clang-tidy/readability/QualifiedAutoCheck.h
index 187a4cd6ee614..f88f7e6489538 100644
--- a/clang-tools-extra/clang-tidy/readability/QualifiedAutoCheck.h
+++ b/clang-tools-extra/clang-tidy/readability/QualifiedAutoCheck.h
@@ -32,6 +32,7 @@ class QualifiedAutoCheck : public ClangTidyCheck {
private:
const bool AddConstToQualified;
const std::vector AllowedTypes;
+ const bool RespectOpaqueTypes;
};
} // namespace clang::tidy::readability
diff --git
a/clang-tools-extra/test/clang-tidy/checkers/readability/qualified-auto-opaque.cpp
b/clang-tools-extra/test/clang-tidy/checkers/readability/qualified-auto-opaque.cpp
new file mode 100644
index 0..a9a63663919f7
--- /dev/null
+++
b/clang-tools-extra/test/clang-tidy/checkers/readability/qualified-auto-opaque.cpp
@@ -0,0 +1,239 @@
+// RUN: %check_clang_tidy %s readability-qualified-auto %t --
-config="{CheckOptions: [\
+// RUN: {key: readability-qualified-auto.RespectOpaqueTypes, value: true}]}" --
+
+namespace typedefs {
+typedef int *MyPtr;
+typedef int &MyRef;
+typedef const int *CMyPtr;
+typedef const int &CMyRef;
+
+MyPtr getPtr();
+MyPtr* getPtrPtr();
+MyRef getRef();
+CMyPtr getCPtr();
+CMyPtr* getCPtrPtr();
+CMyRef getCRef();
+int* getIntPtr();
+
+void foo() {
+ auto TdNakedPtr = getPtr();
+ auto TdNakedPtrPtr = getPtrPtr();
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'auto TdNakedPtrPtr' can be
declared as 'auto *TdNakedPtrPtr'
+ // CHECK-FIXES: {{^}} auto *TdNakedPtrPtr = getPtrPtr();
+ auto intPtr = getIntPtr();
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'auto intPtr' can be declared as
'auto *intPtr'
+ // CHECK-FIXES: {{^}} auto *intPtr = getIntPtr();
+ auto TdNakedRefDeref = getRef();
+ auto TdNakedCPtr = getCPtr();
+ auto TdNakedCPtrPtr = getCPtrPtr();
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'auto TdNakedCPtrPtr' can be
declared as 'auto *TdNakedCPtrPtr'
+ // CHECK-FIXES: {{^}} auto *TdNakedCPtrPtr = getCPtrPtr();
+ auto &TdNakedCRef = getCRef();
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'auto &TdNakedCRef' can be
declared as 'const auto &TdNakedCRef'
+ // CHECK-FIXES: {{^}} const auto &TdNakedCRef = getCRef();
+ auto TdNakedCRefDeref = getCRef();
+}
+
+}; // namespace typedefs
+
+namespace usings {
+using MyPtr = int *;
+using MyRef = int &;
+using CMyPtr = const int *;
+using CMyRef = const int &;
+
+MyPtr getPtr();
+MyPtr* getPtrPtr();
+MyRef g
[clang] [lld] [llvm] Integrated Distributed ThinLTO (DTLTO): Design Overview (PR #126654)
https://github.com/bd1976bris edited https://github.com/llvm/llvm-project/pull/126654 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR] Upstream the basic structure of LoweringPrepare pass (PR #148545)
llvm-ci wrote: LLVM Buildbot has detected a new failure on builder `lldb-remote-linux-win` running on `as-builder-10` while building `clang` at step 8 "build-default". Full details are available at: https://lab.llvm.org/buildbot/#/builders/197/builds/7022 Here is the relevant piece of the build log for the reference ``` Step 8 (build-default) failure: cmake (failure) ... 3.347 [504/130/1884]Building CXX object compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.aarch64.dir/sanitizer_stoptheworld_fuchsia.cpp.o 3.353 [503/130/1885]Building CXX object compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.aarch64.dir/sanitizer_procmaps_solaris.cpp.o 3.361 [502/130/1886]Building CXX object compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.aarch64.dir/sanitizer_procmaps_mac.cpp.o 3.372 [501/130/1887]Building CXX object compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.aarch64.dir/sanitizer_thread_arg_retval.cpp.o 3.377 [500/130/1888]Building CXX object compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.aarch64.dir/sanitizer_solaris.cpp.o 3.391 [499/130/1889]Building CXX object compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.aarch64.dir/sanitizer_stoptheworld_mac.cpp.o 3.406 [498/130/1890]Building CXX object compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.aarch64.dir/sanitizer_libignore.cpp.o 3.411 [497/130/1891]Building CXX object compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.aarch64.dir/sanitizer_stoptheworld_win.cpp.o 3.432 [496/130/1892]Building CXX object compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.aarch64.dir/sanitizer_deadlock_detector1.cpp.o 3.438 [495/130/1893]Building CXX object libcxx/src/CMakeFiles/cxx_static.dir/expected.cpp.o FAILED: libcxx/src/CMakeFiles/cxx_static.dir/expected.cpp.o C:\buildbot\as-builder-10\lldb-x-aarch64\build\.\bin\clang++.exe --target=aarch64-unknown-linux-gnu -DLIBCXX_BUILDING_LIBCXXABI -DLIBC_NAMESPACE=__llvm_libc_common_utils -D_DEBUG -D_GLIBCXX_ASSERTIONS -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_LINK_PTHREAD_LIB -D_LIBCPP_LINK_RT_LIB -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -IC:/buildbot/as-builder-10/lldb-x-aarch64/llvm-project/libcxx/src -IC:/buildbot/as-builder-10/lldb-x-aarch64/build/include/aarch64-unknown-linux-gnu/c++/v1 -IC:/buildbot/as-builder-10/lldb-x-aarch64/build/include/c++/v1 -IC:/buildbot/as-builder-10/lldb-x-aarch64/llvm-project/libcxxabi/include -IC:/buildbot/as-builder-10/lldb-x-aarch64/llvm-project/cmake/Modules/../../libc -mcpu=cortex-a78 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG -UNDEBUG -faligned-allocation -nostdinc++ -fvisibility-inlines-hidden -fvisibility=hidden -fsized-deallocation -Wall -Wextra -Wnewline-eof -Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef -Wunused-template -Wformat-nonliteral -Wzero-length-array -Wdeprecated-redundant-constexpr-static-def -Wno-nullability-completeness -Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override -Wno-error -fdebug-prefix-map=C:/buildbot/as-builder-10/lldb-x-aarch64/build/include/c++/v1=C:/buildbot/as-builder-10/lldb-x-aarch64/llvm-project/libcxx/include -std=c++2b -MD -MT libcxx/src/CMakeFiles/cxx_static.dir/expected.cpp.o -MF libcxx\src\CMakeFiles\cxx_static.dir\expected.cpp.o.d -o libcxx/src/CMakeFiles/cxx_static.dir/expected.cpp.o -c C:/buildbot/as-builder-10/lldb-x-aarch64/llvm-project/libcxx/src/expected.cpp In file included from C:/buildbot/as-builder-10/lldb-x-aarch64/llvm-project/libcxx/src/expected.cpp:9: In file included from C:/buildbot/as-builder-10/lldb-x-aarch64/build/include/c++/v1\expected:48: In file included from C:/buildbot/as-builder-10/lldb-x-aarch64/build/include/c++/v1\__expected/expected.h:12: In file included from C:/buildbot/as-builder-10/lldb-x-aarch64/build/include/c++/v1\__assert:13: C:/buildbot/as-builder-10/lldb-x-aarch64/build/include/c++/v1\__assertion_handler:19:12: fatal error: '__log_hardening_failure' file not found 19 | # include <__log_hardening_failure> |^ 1 error generated. 3.438 [495/129/1894]Building CXX object compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.aarch64.dir/sanitizer_type_traits.cpp.o 3.439 [495/128/1
[clang] [clang] Reduce the small vector size for DeclTypeInfo. (PR #148788)
https://github.com/AaronBallman approved this pull request. LGTM! 8 declarator chunks is actually quite a bit, I suspect 4 is a more sensible default for the average TU. 2 might be a bit too few for what I'd suspect is the average use case. https://github.com/llvm/llvm-project/pull/148788 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR][NFC] Fix LoweringPrepare pass multi lines summary (PR #148826)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Amr Hesham (AmrDeveloper)
Changes
Fix the Lowering Prepare a multi-line summary
---
Full diff: https://github.com/llvm/llvm-project/pull/148826.diff
1 Files Affected:
- (modified) clang/include/clang/CIR/Dialect/Passes.td (+2-2)
``diff
diff --git a/clang/include/clang/CIR/Dialect/Passes.td
b/clang/include/clang/CIR/Dialect/Passes.td
index 65eb857035224..7d5ec2ffed39d 100644
--- a/clang/include/clang/CIR/Dialect/Passes.td
+++ b/clang/include/clang/CIR/Dialect/Passes.td
@@ -73,8 +73,8 @@ def CIRFlattenCFG : Pass<"cir-flatten-cfg"> {
}
def LoweringPrepare : Pass<"cir-lowering-prepare"> {
- let summary = "Lower to more fine-grained CIR operations before lowering to
-other dialects";
+ let summary = "Lower to more fine-grained CIR operations before lowering to "
+"other dialects";
let description = [{
This pass does preparation work for lowering to other dialects. For
example,
it may expand the global variable initialziation in a more ABI-friendly
form.
``
https://github.com/llvm/llvm-project/pull/148826
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR][NFC] Fix LoweringPrepare pass multi lines summary (PR #148826)
llvmbot wrote:
@llvm/pr-subscribers-clangir
Author: Amr Hesham (AmrDeveloper)
Changes
Fix the Lowering Prepare a multi-line summary
---
Full diff: https://github.com/llvm/llvm-project/pull/148826.diff
1 Files Affected:
- (modified) clang/include/clang/CIR/Dialect/Passes.td (+2-2)
``diff
diff --git a/clang/include/clang/CIR/Dialect/Passes.td
b/clang/include/clang/CIR/Dialect/Passes.td
index 65eb857035224..7d5ec2ffed39d 100644
--- a/clang/include/clang/CIR/Dialect/Passes.td
+++ b/clang/include/clang/CIR/Dialect/Passes.td
@@ -73,8 +73,8 @@ def CIRFlattenCFG : Pass<"cir-flatten-cfg"> {
}
def LoweringPrepare : Pass<"cir-lowering-prepare"> {
- let summary = "Lower to more fine-grained CIR operations before lowering to
-other dialects";
+ let summary = "Lower to more fine-grained CIR operations before lowering to "
+"other dialects";
let description = [{
This pass does preparation work for lowering to other dialects. For
example,
it may expand the global variable initialziation in a more ABI-friendly
form.
``
https://github.com/llvm/llvm-project/pull/148826
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR][NFC] Fix LoweringPrepare pass multi lines summary (PR #148826)
https://github.com/AmrDeveloper created
https://github.com/llvm/llvm-project/pull/148826
Fix the Lowering Prepare a multi-line summary
>From 10a58ba4f1872a7ea6ba302178dfe48625584a5f Mon Sep 17 00:00:00 2001
From: AmrDeveloper
Date: Tue, 15 Jul 2025 13:12:10 +0200
Subject: [PATCH] [CIR][NFC] Fix LoweringPrepare pass multi lines summary
---
clang/include/clang/CIR/Dialect/Passes.td | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/clang/include/clang/CIR/Dialect/Passes.td
b/clang/include/clang/CIR/Dialect/Passes.td
index 65eb857035224..7d5ec2ffed39d 100644
--- a/clang/include/clang/CIR/Dialect/Passes.td
+++ b/clang/include/clang/CIR/Dialect/Passes.td
@@ -73,8 +73,8 @@ def CIRFlattenCFG : Pass<"cir-flatten-cfg"> {
}
def LoweringPrepare : Pass<"cir-lowering-prepare"> {
- let summary = "Lower to more fine-grained CIR operations before lowering to
-other dialects";
+ let summary = "Lower to more fine-grained CIR operations before lowering to "
+"other dialects";
let description = [{
This pass does preparation work for lowering to other dialects. For
example,
it may expand the global variable initialziation in a more ABI-friendly
form.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Lay the basic infrastructure for pretty printing of types (PR #148701)
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
const char* c_str = "Hello, world!"; c_str
+// CHECK-NEXT: (const char *) "Hello, world!"
+
+c_str = "Goodbye, world!"; c_str
+// CHECK-NEXT: (const char *) "Goodbye, world!"
+
+const char* c_null_str = 0; c_null_str
+// CHECK-NEXT: (const char *) 0
+
+"Hello, world"
+// CHECK-NEXT: ({{(const )?}}char[13]) "Hello, world"
+
+int x = 42; x
+// CHECK-NEXT: (int) 42
+
+&x
+// CHECK-NEXT: (int *) @0x{{[0-9a-f]+}}
+
+x - 2
+// CHECK-NEXT: (int) 40
+
+float f = 4.2f; f
+// CHECK-NEXT: (float) 4.2f
+
+double d = 4.21; d
+// CHECK-NEXT: (double) 4.210
+
+long double tau = 6.2831853; tau
+// CHECK-NEXT: (long double) 6.2831853L
AaronBallman wrote:
Will these values be sensitive to the target architecture the test is run on?
(I'm thinking about things like PPC double double or x87 long double.)
https://github.com/llvm/llvm-project/pull/148701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Lay the basic infrastructure for pretty printing of types (PR #148701)
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
const char* c_str = "Hello, world!"; c_str
+// CHECK-NEXT: (const char *) "Hello, world!"
+
+c_str = "Goodbye, world!"; c_str
+// CHECK-NEXT: (const char *) "Goodbye, world!"
+
+const char* c_null_str = 0; c_null_str
+// CHECK-NEXT: (const char *) 0
+
+"Hello, world"
+// CHECK-NEXT: ({{(const )?}}char[13]) "Hello, world"
+
+int x = 42; x
+// CHECK-NEXT: (int) 42
+
+&x
+// CHECK-NEXT: (int *) @0x{{[0-9a-f]+}}
+
+x - 2
+// CHECK-NEXT: (int) 40
+
+float f = 4.2f; f
+// CHECK-NEXT: (float) 4.2f
+
+double d = 4.21; d
+// CHECK-NEXT: (double) 4.210
+
+long double tau = 6.2831853; tau
+// CHECK-NEXT: (long double) 6.2831853L
+
+int foo() { return 42; } foo()
AaronBallman wrote:
What gets printed for: `foo` (not a call but a DeclRefExpr to the function)?
https://github.com/llvm/llvm-project/pull/148701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Lay the basic infrastructure for pretty printing of types (PR #148701)
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
const char* c_str = "Hello, world!"; c_str
+// CHECK-NEXT: (const char *) "Hello, world!"
+
+c_str = "Goodbye, world!"; c_str
+// CHECK-NEXT: (const char *) "Goodbye, world!"
+
+const char* c_null_str = 0; c_null_str
+// CHECK-NEXT: (const char *) 0
+
+"Hello, world"
+// CHECK-NEXT: ({{(const )?}}char[13]) "Hello, world"
+
+int x = 42; x
+// CHECK-NEXT: (int) 42
+
+&x
+// CHECK-NEXT: (int *) @0x{{[0-9a-f]+}}
+
+x - 2
+// CHECK-NEXT: (int) 40
+
+float f = 4.2f; f
+// CHECK-NEXT: (float) 4.2f
+
+double d = 4.21; d
+// CHECK-NEXT: (double) 4.210
+
+long double tau = 6.2831853; tau
+// CHECK-NEXT: (long double) 6.2831853L
+
+int foo() { return 42; } foo()
+// CHECK-NEXT: (int) 42
+
+void bar(int a, float b) {} bar
+// CHECK-NEXT: (void (int, float)) Function @0x{{[0-9a-f]+}}
+// CHECK-NEXT: void bar(int a, float b) {
+
+bar
+// CHECK: (void (int, float)) Function @0x{{[0-9a-f]+}}
+// CHECK-NEXT: void bar(int a, float b) {
+
+// Arrays.
+
+int arr[3] = {1,2,3}; arr
+// CHECK: (int[3]) { 1, 2, 3 }
+
+double darr[3][4] = { {1,2,3,4}, {5,6,7,8}, {9,10,11,12} }; darr
+// CHECK-NEXT: (double[3][4]) { { 1.0, 2.0, 3.0, 4.0 }, { 5.0, 6.0, 7.0, 8.0
}, { 9.0, 10.0, 11.0, 12.0 } }
+
+float farr[2][1] = { {0}, {3.14}}; farr
+// CHECK-NEXT: (float[2][1]) { { 0.0f }, { 3.14000f } }
+
+0./0.
+// CHECK-NEXT: (double) nan
+
+1.0f / 0.0f
+// CHECK-NEXT: (float) inf
+
+0.1f
+// CHECK-NEXT: (float) 1.0e-05f
+
+
+// struct S1{} s1; s1
+// TODO-CHECK-NEXT: (S1 &) @0x{{[0-9a-f]+}}
+
+// struct S2 {int d;} E = {22}; E
+// TODO-CHECK-NEXT: (struct S2 &) @0x{{[0-9a-f]+}}
+// E.d
+// TODO-CHECK-NEXT: (int) 22
AaronBallman wrote:
Other things to test would be printing for `_Bool`, `_Complex`, `_Atomic`, and
`_BitInt` as well as unions
https://github.com/llvm/llvm-project/pull/148701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Lay the basic infrastructure for pretty printing of types (PR #148701)
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
const char* c_str = "Hello, world!"; c_str
+// CHECK-NEXT: (const char *) "Hello, world!"
+
+c_str = "Goodbye, world!"; c_str
+// CHECK-NEXT: (const char *) "Goodbye, world!"
+
+const char* c_null_str = 0; c_null_str
+// CHECK-NEXT: (const char *) 0
+
+"Hello, world"
+// CHECK-NEXT: ({{(const )?}}char[13]) "Hello, world"
+
+int x = 42; x
+// CHECK-NEXT: (int) 42
+
+&x
+// CHECK-NEXT: (int *) @0x{{[0-9a-f]+}}
+
+x - 2
+// CHECK-NEXT: (int) 40
+
+float f = 4.2f; f
+// CHECK-NEXT: (float) 4.2f
+
+double d = 4.21; d
+// CHECK-NEXT: (double) 4.210
+
+long double tau = 6.2831853; tau
+// CHECK-NEXT: (long double) 6.2831853L
+
+int foo() { return 42; } foo()
+// CHECK-NEXT: (int) 42
+
+void bar(int a, float b) {} bar
+// CHECK-NEXT: (void (int, float)) Function @0x{{[0-9a-f]+}}
+// CHECK-NEXT: void bar(int a, float b) {
+
+bar
+// CHECK: (void (int, float)) Function @0x{{[0-9a-f]+}}
+// CHECK-NEXT: void bar(int a, float b) {
+
+// Arrays.
+
+int arr[3] = {1,2,3}; arr
AaronBallman wrote:
Can you add a test for VLAs?
https://github.com/llvm/llvm-project/pull/148701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Lay the basic infrastructure for pretty printing of types (PR #148701)
@@ -250,17 +254,35 @@ const ASTContext &Value::getASTContext() const {
return getInterpreter().getASTContext();
}
-void Value::dump() const { print(llvm::outs()); }
+void Value::dump() { print(llvm::outs()); }
void Value::printType(llvm::raw_ostream &Out) const {
- Out << "Not implement yet.\n";
+ Out << Interp->ValueTypeToString(*this);
}
-void Value::printData(llvm::raw_ostream &Out) const {
- Out << "Not implement yet.\n";
+
+void Value::printData(llvm::raw_ostream &Out) {
+ Out << Interp->ValueDataToString(*this);
}
-void Value::print(llvm::raw_ostream &Out) const {
+// FIXME: We do not support the multiple inheritance case where one of the base
+// classes has a pretty-printer and the other does not.
+void Value::print(llvm::raw_ostream &Out) {
assert(OpaqueType != nullptr && "Can't print default Value");
- Out << "Not implement yet.\n";
+
+ // Don't even try to print a void or an invalid type, it doesn't make sense.
+ if (getType()->isVoidType() || !isValid())
AaronBallman wrote:
Yeah, I think it's reasonable to do that in a follow-up
https://github.com/llvm/llvm-project/pull/148701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR][NFC] Fix LoweringPrepare pass multi lines summary (PR #148826)
https://github.com/AmrDeveloper closed https://github.com/llvm/llvm-project/pull/148826 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Lay the basic infrastructure for pretty printing of types (PR #148701)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/148701 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Lay the basic infrastructure for pretty printing of types (PR #148701)
https://github.com/AaronBallman commented: Precommit CI found some crashing issues that will need to be addressed, and I had some more testing requests to make sure we handle basics properly. https://github.com/llvm/llvm-project/pull/148701 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Lay the basic infrastructure for pretty printing of types (PR #148701)
@@ -0,0 +1,59 @@
+// RUN: clang-repl "int i = 10;" 'extern "C" int printf(const char*,...);' \
+// RUN:'auto r1 = printf("i = %d\n", i);' | FileCheck
--check-prefix=CHECK-DRIVER %s
+// UNSUPPORTED: system-aix
+// CHECK-DRIVER: i = 10
+// RUN: cat %s | clang-repl -Xcc -std=c++11 -Xcc -fno-delayed-template-parsing
| FileCheck %s
+extern "C" int printf(const char*,...);
+
+"ab"
+// CHECK: (const char[3]) "ab"
+
+char ch[2] = {'1','a'}; ch
+// CHECK-NEXT: (char[2]) { '1', 'a' }
+
+char chnull[3] = {'1','a', '\0'}; chnull
+// CHECK-NEXT: (char[3]) "1a"
+
+char ch_arr[2][3][1] = {{{'a'}, {'b'}, {'c'}}, {{'d'}, {'e'}, {'f'}}}; ch_arr
+// CHECK: (char[2][3][1]) { { { 'a' }, { 'b' }, { 'c' } }, { { 'd' }, { 'e' },
{ 'f' } } }
+struct S3 { int* p; S3() { p = new int(42); } ~S3() { delete p; } };
+S3{}
+// CHECK-NEXT: (S3) @0x{{[0-9a-f]+}}
+S3 s3;
+s3
+// CHECK-NEXT: (S3 &) @0x{{[0-9a-f]+}}
+
+struct S4 { ~S4() { printf("~S4()\n"); }};
+S4{}
+// CHECK-NEXT: (S4) @0x{{[0-9a-f]+}}
+
+enum Enum{ e1 = -12, e2, e3=33, e4, e5 = 33};
+e2
+// CHECK-NEXT: (Enum) (e2) : int -11
+::e1
+// CHECK-NEXT: (Enum) (e1) : int -12
+
+enum class Color { R = 0, G, B };
+Color::R
+// CHECK-NEXT: (Color) (Color::R) : int 0
+
+
+// Lambdas.
+
+auto Lambda1 = []{};
+Lambda1
+// CHECK-NEXT: ((lambda) &) @0x{{[0-9a-f]+}}
+[]{}
+// CHECK-NEXT: ((lambda at input_line_{{[0-9]+}}:1:1)) @0x{{[0-9a-f]+}}
+
+template struct F{ enum {RET=F::RET*n} ; };
+template<> struct F<0> { enum {RET = 1}; };
+F<7>::RET
+// CHECK-NEXT: (F<7>::(unnamed enum at input_line_{{[0-9]+}}:1:27))
(F<7>::RET) : unsigned int 5040
+
+struct S5 { int foo() { return 42; }};
+&S5::foo
+// CHECK-NEXT: (int (S5::*)()) Function @0x{{[0-9a-f]+}}
+
AaronBallman wrote:
It'd be good to get a test for references as well.
https://github.com/llvm/llvm-project/pull/148701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] b3240b4 - [CIR][NFC] Fix LoweringPrepare pass multi lines summary (#148826)
Author: Amr Hesham
Date: 2025-07-15T13:15:25+02:00
New Revision: b3240b4889bb4b700e655d21e908ae07cfda5a55
URL:
https://github.com/llvm/llvm-project/commit/b3240b4889bb4b700e655d21e908ae07cfda5a55
DIFF:
https://github.com/llvm/llvm-project/commit/b3240b4889bb4b700e655d21e908ae07cfda5a55.diff
LOG: [CIR][NFC] Fix LoweringPrepare pass multi lines summary (#148826)
Fix the Lowering Prepare a multi-line summary
Added:
Modified:
clang/include/clang/CIR/Dialect/Passes.td
Removed:
diff --git a/clang/include/clang/CIR/Dialect/Passes.td
b/clang/include/clang/CIR/Dialect/Passes.td
index 65eb857035224..7d5ec2ffed39d 100644
--- a/clang/include/clang/CIR/Dialect/Passes.td
+++ b/clang/include/clang/CIR/Dialect/Passes.td
@@ -73,8 +73,8 @@ def CIRFlattenCFG : Pass<"cir-flatten-cfg"> {
}
def LoweringPrepare : Pass<"cir-lowering-prepare"> {
- let summary = "Lower to more fine-grained CIR operations before lowering to
-other dialects";
+ let summary = "Lower to more fine-grained CIR operations before lowering to "
+"other dialects";
let description = [{
This pass does preparation work for lowering to other dialects. For
example,
it may expand the global variable initialziation in a more ABI-friendly
form.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR][NFC] Fix LoweringPrepare pass multi lines summary (PR #148826)
AmrDeveloper wrote: I will quickly merge to make it buildable again https://github.com/llvm/llvm-project/pull/148826 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move CMake for prepare_builtins to a subdirectory (PR #148815)
https://github.com/frasercrmck updated
https://github.com/llvm/llvm-project/pull/148815
>From a426ba39c895ac8eed7ee0bc69310d7ccb681560 Mon Sep 17 00:00:00 2001
From: Fraser Cormack
Date: Tue, 15 Jul 2025 10:44:48 +0100
Subject: [PATCH 1/2] [libclc] Move CMake for prepare_builtins to a
subdirectory
---
libclc/CMakeLists.txt | 24 ++--
libclc/utils/CMakeLists.txt | 24
2 files changed, 26 insertions(+), 22 deletions(-)
create mode 100644 libclc/utils/CMakeLists.txt
diff --git a/libclc/CMakeLists.txt b/libclc/CMakeLists.txt
index e2871d1b01a16..250cc42d04c34 100644
--- a/libclc/CMakeLists.txt
+++ b/libclc/CMakeLists.txt
@@ -164,34 +164,14 @@ endif()
list( SORT LIBCLC_TARGETS_TO_BUILD )
-# Construct LLVM version define
-set( LLVM_VERSION_DEFINE
"-DHAVE_LLVM=0x${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}" )
-
# This needs to be set before any target that needs it
# We need to use LLVM_INCLUDE_DIRS here, because if we are linking to an
# llvm build directory, this includes $src/llvm/include which is where all the
# headers are not $build/include/ which is what LLVM_INCLUDE_DIR is set to.
include_directories( ${LLVM_INCLUDE_DIRS} )
-# Setup prepare_builtins tools
-set(LLVM_LINK_COMPONENTS
- BitReader
- BitWriter
- Core
- IRReader
- Support
-)
-if( LIBCLC_STANDALONE_BUILD )
- add_llvm_executable( prepare_builtins utils/prepare-builtins.cpp )
- set( prepare_builtins_exe prepare_builtins )
- set( prepare_builtins_target prepare_builtins )
-else()
- add_llvm_utility( prepare_builtins utils/prepare-builtins.cpp )
- setup_host_tool( prepare_builtins PREPARE_BUILTINS prepare_builtins_exe
prepare_builtins_target )
-endif()
-target_compile_definitions( prepare_builtins PRIVATE ${LLVM_VERSION_DEFINE} )
-# These were not properly reported in early LLVM and we don't need them
-target_compile_options( prepare_builtins PRIVATE -fno-rtti -fno-exceptions )
+# Configure prepare_builtins
+add_subdirectory(utils)
# Setup arch devices
set( r600--_devices cedar cypress barts cayman )
diff --git a/libclc/utils/CMakeLists.txt b/libclc/utils/CMakeLists.txt
new file mode 100644
index 0..1d89b3a48e09a
--- /dev/null
+++ b/libclc/utils/CMakeLists.txt
@@ -0,0 +1,24 @@
+# Construct LLVM version define
+set( LLVM_VERSION_DEFINE
"-DHAVE_LLVM=0x${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}" )
+
+# Setup prepare_builtins tools
+set(LLVM_LINK_COMPONENTS
+ BitReader
+ BitWriter
+ Core
+ IRReader
+ Support
+)
+
+if( LIBCLC_STANDALONE_BUILD )
+ add_llvm_executable( prepare_builtins prepare-builtins.cpp )
+ set( prepare_builtins_exe prepare_builtins )
+ set( prepare_builtins_target prepare_builtins )
+else()
+ add_llvm_utility( prepare_builtins prepare-builtins.cpp )
+ setup_host_tool( prepare_builtins PREPARE_BUILTINS prepare_builtins_exe
prepare_builtins_target )
+endif()
+
+target_compile_definitions( prepare_builtins PRIVATE ${LLVM_VERSION_DEFINE} )
+# These were not properly reported in early LLVM and we don't need them
+target_compile_options( prepare_builtins PRIVATE -fno-rtti -fno-exceptions )
>From 6ab2992d97005746917403e576a688d5ca6aec86 Mon Sep 17 00:00:00 2001
From: Fraser Cormack
Date: Tue, 15 Jul 2025 12:18:47 +0100
Subject: [PATCH 2/2] introduce spaces
---
libclc/CMakeLists.txt | 2 +-
libclc/utils/CMakeLists.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libclc/CMakeLists.txt b/libclc/CMakeLists.txt
index 250cc42d04c34..2570d1a106d21 100644
--- a/libclc/CMakeLists.txt
+++ b/libclc/CMakeLists.txt
@@ -171,7 +171,7 @@ list( SORT LIBCLC_TARGETS_TO_BUILD )
include_directories( ${LLVM_INCLUDE_DIRS} )
# Configure prepare_builtins
-add_subdirectory(utils)
+add_subdirectory( utils )
# Setup arch devices
set( r600--_devices cedar cypress barts cayman )
diff --git a/libclc/utils/CMakeLists.txt b/libclc/utils/CMakeLists.txt
index 1d89b3a48e09a..ea1d9e9c8ef5f 100644
--- a/libclc/utils/CMakeLists.txt
+++ b/libclc/utils/CMakeLists.txt
@@ -2,7 +2,7 @@
set( LLVM_VERSION_DEFINE
"-DHAVE_LLVM=0x${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}" )
# Setup prepare_builtins tools
-set(LLVM_LINK_COMPONENTS
+set( LLVM_LINK_COMPONENTS
BitReader
BitWriter
Core
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CodeGen][ObjC] Include all referenced protocols in protocol list (PR #148827)
https://github.com/hmelder created
https://github.com/llvm/llvm-project/pull/148827
When constructing the protocol list in the class metadata generation
(`GenerateClass`), only the protocols from the base class are added but not
protocols declared in class extensions.
This is fixed by using `all_referenced_protocol_{begin, end}` instead of
`protocol_{begin, end}`, matching the behaviour on Apple platforms.
A unit test is included to check if all protocol metadata was emitted and that
no duplication occurs in the protocol list.
Fixes https://github.com/gnustep/libobjc2/issues/339
CC: @davidchisnall
>From 6f626d2bab1934331bca0475632f8bcef604e160 Mon Sep 17 00:00:00 2001
From: hmelder
Date: Tue, 15 Jul 2025 13:09:28 +0200
Subject: [PATCH] [CodeGen][ObjC] Include all referenced protocols in protocol
list
When constructing the protocol list in the class metadata generation
(`GenerateClass`), only the protocols from the base class are added but
not from class extensions.
This is fixed by using `all_referenced_protocol_{begin, end}` instead of
`protocol_{begin, end}`, matching the behaviour on Apple platforms.
---
clang/lib/CodeGen/CGObjCGNU.cpp | 4 ++--
clang/test/CodeGenObjC/gnustep2-class-exts.m | 25
2 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644 clang/test/CodeGenObjC/gnustep2-class-exts.m
diff --git a/clang/lib/CodeGen/CGObjCGNU.cpp b/clang/lib/CodeGen/CGObjCGNU.cpp
index d828702cbb87f..126b46e08df48 100644
--- a/clang/lib/CodeGen/CGObjCGNU.cpp
+++ b/clang/lib/CodeGen/CGObjCGNU.cpp
@@ -1942,8 +1942,8 @@ class CGObjCGNUstep2 : public CGObjCGNUstep {
// struct objc_class *sibling_class
classFields.addNullPointer(PtrTy);
// struct objc_protocol_list *protocols;
-auto RuntimeProtocols = GetRuntimeProtocolList(classDecl->protocol_begin(),
- classDecl->protocol_end());
+auto RuntimeProtocols =
GetRuntimeProtocolList(classDecl->all_referenced_protocol_begin(),
+
classDecl->all_referenced_protocol_end());
SmallVector Protocols;
for (const auto *I : RuntimeProtocols)
Protocols.push_back(GenerateProtocolRef(I));
diff --git a/clang/test/CodeGenObjC/gnustep2-class-exts.m
b/clang/test/CodeGenObjC/gnustep2-class-exts.m
new file mode 100644
index 0..b065490a7d8d8
--- /dev/null
+++ b/clang/test/CodeGenObjC/gnustep2-class-exts.m
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple aarch64-unknown-linux-gnu
-fobjc-runtime=gnustep-2.2 -emit-llvm -o - %s | FileCheck %s
+
+@protocol BaseProtocol
+@end
+
+@protocol ExtendedProtocol
+@end
+
+@interface TestClass
+
+-(void) Meth;
+@end
+
+@interface TestClass ()
+@end
+
+@implementation TestClass
+@end
+
+// Check that we emit metadata for both protocols
+// CHECK: @._OBJC_PROTOCOL_ExtendedProtocol = global
+// CHECK: @._OBJC_PROTOCOL_BaseProtocol = global
+
+// Check that we deduplicate the protocol list
+// CHECK: @.objc_protocol_list{{\.[0-9]*}} = internal global { ptr, i64, [2 x
ptr] }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move CMake for prepare_builtins to a subdirectory (PR #148815)
@@ -164,34 +164,14 @@ endif()
list( SORT LIBCLC_TARGETS_TO_BUILD )
-# Construct LLVM version define
-set( LLVM_VERSION_DEFINE
"-DHAVE_LLVM=0x${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}" )
-
# This needs to be set before any target that needs it
# We need to use LLVM_INCLUDE_DIRS here, because if we are linking to an
# llvm build directory, this includes $src/llvm/include which is where all the
# headers are not $build/include/ which is what LLVM_INCLUDE_DIR is set to.
include_directories( ${LLVM_INCLUDE_DIRS} )
-# Setup prepare_builtins tools
-set(LLVM_LINK_COMPONENTS
- BitReader
- BitWriter
- Core
- IRReader
- Support
-)
-if( LIBCLC_STANDALONE_BUILD )
- add_llvm_executable( prepare_builtins utils/prepare-builtins.cpp )
- set( prepare_builtins_exe prepare_builtins )
- set( prepare_builtins_target prepare_builtins )
-else()
- add_llvm_utility( prepare_builtins utils/prepare-builtins.cpp )
- setup_host_tool( prepare_builtins PREPARE_BUILTINS prepare_builtins_exe
prepare_builtins_target )
-endif()
-target_compile_definitions( prepare_builtins PRIVATE ${LLVM_VERSION_DEFINE} )
-# These were not properly reported in early LLVM and we don't need them
-target_compile_options( prepare_builtins PRIVATE -fno-rtti -fno-exceptions )
+# Configure prepare_builtins
+add_subdirectory(utils)
frasercrmck wrote:
done
https://github.com/llvm/llvm-project/pull/148815
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move CMake for prepare_builtins to a subdirectory (PR #148815)
@@ -0,0 +1,24 @@
+# Construct LLVM version define
+set( LLVM_VERSION_DEFINE
"-DHAVE_LLVM=0x${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}" )
+
+# Setup prepare_builtins tools
+set(LLVM_LINK_COMPONENTS
frasercrmck wrote:
Good idea, thanks. Done
https://github.com/llvm/llvm-project/pull/148815
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move CMake for prepare_builtins to a subdirectory (PR #148815)
https://github.com/wenju-he approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/148815 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CodeGen][ObjC] Include all referenced protocols in protocol list (PR #148827)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Hugo Melder (hmelder)
Changes
When constructing the protocol list in the class metadata generation
(`GenerateClass`), only the protocols from the base class are added but not
protocols declared in class extensions.
This is fixed by using `all_referenced_protocol_{begin, end}` instead of
`protocol_{begin, end}`, matching the behaviour on Apple platforms.
A unit test is included to check if all protocol metadata was emitted and that
no duplication occurs in the protocol list.
Fixes https://github.com/gnustep/libobjc2/issues/339
CC: @davidchisnall
---
Full diff: https://github.com/llvm/llvm-project/pull/148827.diff
2 Files Affected:
- (modified) clang/lib/CodeGen/CGObjCGNU.cpp (+2-2)
- (added) clang/test/CodeGenObjC/gnustep2-class-exts.m (+25)
``diff
diff --git a/clang/lib/CodeGen/CGObjCGNU.cpp b/clang/lib/CodeGen/CGObjCGNU.cpp
index d828702cbb87f..126b46e08df48 100644
--- a/clang/lib/CodeGen/CGObjCGNU.cpp
+++ b/clang/lib/CodeGen/CGObjCGNU.cpp
@@ -1942,8 +1942,8 @@ class CGObjCGNUstep2 : public CGObjCGNUstep {
// struct objc_class *sibling_class
classFields.addNullPointer(PtrTy);
// struct objc_protocol_list *protocols;
-auto RuntimeProtocols = GetRuntimeProtocolList(classDecl->protocol_begin(),
- classDecl->protocol_end());
+auto RuntimeProtocols =
GetRuntimeProtocolList(classDecl->all_referenced_protocol_begin(),
+
classDecl->all_referenced_protocol_end());
SmallVector Protocols;
for (const auto *I : RuntimeProtocols)
Protocols.push_back(GenerateProtocolRef(I));
diff --git a/clang/test/CodeGenObjC/gnustep2-class-exts.m
b/clang/test/CodeGenObjC/gnustep2-class-exts.m
new file mode 100644
index 0..b065490a7d8d8
--- /dev/null
+++ b/clang/test/CodeGenObjC/gnustep2-class-exts.m
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple aarch64-unknown-linux-gnu
-fobjc-runtime=gnustep-2.2 -emit-llvm -o - %s | FileCheck %s
+
+@protocol BaseProtocol
+@end
+
+@protocol ExtendedProtocol
+@end
+
+@interface TestClass
+
+-(void) Meth;
+@end
+
+@interface TestClass ()
+@end
+
+@implementation TestClass
+@end
+
+// Check that we emit metadata for both protocols
+// CHECK: @._OBJC_PROTOCOL_ExtendedProtocol = global
+// CHECK: @._OBJC_PROTOCOL_BaseProtocol = global
+
+// Check that we deduplicate the protocol list
+// CHECK: @.objc_protocol_list{{\.[0-9]*}} = internal global { ptr, i64, [2 x
ptr] }
``
https://github.com/llvm/llvm-project/pull/148827
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CodeGen][ObjC] Include all referenced protocols in protocol list (PR #148827)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff HEAD~1 HEAD --extensions cpp --
clang/lib/CodeGen/CGObjCGNU.cpp
``
View the diff from clang-format here.
``diff
diff --git a/clang/lib/CodeGen/CGObjCGNU.cpp b/clang/lib/CodeGen/CGObjCGNU.cpp
index 126b46e08..8acf8d2dd 100644
--- a/clang/lib/CodeGen/CGObjCGNU.cpp
+++ b/clang/lib/CodeGen/CGObjCGNU.cpp
@@ -1942,8 +1942,9 @@ class CGObjCGNUstep2 : public CGObjCGNUstep {
// struct objc_class *sibling_class
classFields.addNullPointer(PtrTy);
// struct objc_protocol_list *protocols;
-auto RuntimeProtocols =
GetRuntimeProtocolList(classDecl->all_referenced_protocol_begin(),
-
classDecl->all_referenced_protocol_end());
+auto RuntimeProtocols =
+GetRuntimeProtocolList(classDecl->all_referenced_protocol_begin(),
+ classDecl->all_referenced_protocol_end());
SmallVector Protocols;
for (const auto *I : RuntimeProtocols)
Protocols.push_back(GenerateProtocolRef(I));
``
https://github.com/llvm/llvm-project/pull/148827
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] clang-format: Add IncludeSortKey option (PR #137840)
@@ -4385,8 +4385,18 @@ struct FormatStyle {
///#include "B/a.h" #include "a/b.h"
/// \endcode
bool IgnoreCase;
+/// When sorting includes in each block, only take file extensions into
+/// account if two includes compare equal otherwise.
+/// \code
+///true: false:
+///# include "A.h" vs.# include "A-util.h"
owenca wrote:
```suggestion
///# include "A.h" vs.# include "A-util.h"
```
as suggested before.
https://github.com/llvm/llvm-project/pull/137840
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] clang-format: Add IncludeSortKey option (PR #137840)
https://github.com/owenca approved this pull request. https://github.com/llvm/llvm-project/pull/137840 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [llvm-objcopy][libObject] Add RISC-V big-endian support (PR #146913)
https://github.com/djtodoro updated
https://github.com/llvm/llvm-project/pull/146913
>From a3b50d1a95f4ae76af98e25502a7bdb950592d38 Mon Sep 17 00:00:00 2001
From: Djordje Todorovic
Date: Thu, 3 Jul 2025 14:03:14 +0200
Subject: [PATCH 1/7] [llvm-objcopy][libObject] Add RISC-V big-endian support
Add support for big-endian RISC-V ELF files:
- Add riscv32be/riscv64be target architectures to Triple
- Support elf32-bigriscv and elf64-bigriscv output targets in llvm-objcopy
- Update ELFObjectFile to handle BE RISC-V format strings and architecture
detection
- Add BE RISC-V support to RelocationResolver
- Add tests for new functionality
This is a subset of a bigger RISC-V big-endian support patch, containing only
the llvm-objcopy and libObject changes. Other changes will be added
later.
---
clang/test/Driver/frame-pointer-elim.c| 2 +-
llvm/include/llvm/Object/ELFObjectFile.h | 8 ++--
llvm/include/llvm/TargetParser/Triple.h | 14 +--
llvm/lib/Object/RelocationResolver.cpp| 6 ++-
llvm/lib/TargetParser/Triple.cpp | 41 +--
.../ELF/binary-output-target.test | 6 +++
llvm/tools/llvm-objcopy/ObjcopyOptions.cpp| 2 +
llvm/unittests/Object/ELFObjectFileTest.cpp | 8 ++--
8 files changed, 70 insertions(+), 17 deletions(-)
diff --git a/clang/test/Driver/frame-pointer-elim.c
b/clang/test/Driver/frame-pointer-elim.c
index f64ff6efc7261..416afce81050a 100644
--- a/clang/test/Driver/frame-pointer-elim.c
+++ b/clang/test/Driver/frame-pointer-elim.c
@@ -160,7 +160,7 @@
// RUN: FileCheck --check-prefix=KEEP-ALL %s
// RUN: %clang -### --target=riscv64-linux-android -O1 -S %s 2>&1 | \
// RUN: FileCheck --check-prefix=KEEP-NON-LEAF %s
-// RUN: not %clang -### --target=riscv64-linux-android -mbig-endian -O1 -S %s
2>&1 | \
+// RUN: %clang -### --target=riscv64-linux-android -mbig-endian -O1 -S %s 2>&1
| \
// RUN: FileCheck --check-prefix=KEEP-NON-LEAF %s
// On ARM backend bare metal targets, frame pointer is omitted
diff --git a/llvm/include/llvm/Object/ELFObjectFile.h
b/llvm/include/llvm/Object/ELFObjectFile.h
index 103686884e705..a3aa0d9c137a2 100644
--- a/llvm/include/llvm/Object/ELFObjectFile.h
+++ b/llvm/include/llvm/Object/ELFObjectFile.h
@@ -1312,7 +1312,7 @@ StringRef ELFObjectFile::getFileFormatName() const {
case ELF::EM_PPC:
return (IsLittleEndian ? "elf32-powerpcle" : "elf32-powerpc");
case ELF::EM_RISCV:
- return "elf32-littleriscv";
+ return (IsLittleEndian ? "elf32-littleriscv" : "elf32-bigriscv");
case ELF::EM_CSKY:
return "elf32-csky";
case ELF::EM_SPARC:
@@ -1338,7 +1338,7 @@ StringRef ELFObjectFile::getFileFormatName() const {
case ELF::EM_PPC64:
return (IsLittleEndian ? "elf64-powerpcle" : "elf64-powerpc");
case ELF::EM_RISCV:
- return "elf64-littleriscv";
+ return (IsLittleEndian ? "elf64-littleriscv" : "elf64-bigriscv");
case ELF::EM_S390:
return "elf64-s390";
case ELF::EM_SPARCV9:
@@ -1400,9 +1400,9 @@ template Triple::ArchType
ELFObjectFile::getArch() const {
case ELF::EM_RISCV:
switch (EF.getHeader().e_ident[ELF::EI_CLASS]) {
case ELF::ELFCLASS32:
- return Triple::riscv32;
+ return IsLittleEndian ? Triple::riscv32 : Triple::riscv32be;
case ELF::ELFCLASS64:
- return Triple::riscv64;
+ return IsLittleEndian ? Triple::riscv64 : Triple::riscv64be;
default:
report_fatal_error("Invalid ELFCLASS!");
}
diff --git a/llvm/include/llvm/TargetParser/Triple.h
b/llvm/include/llvm/TargetParser/Triple.h
index cbf85b2ff74f5..0b983e9f7a3bc 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -74,8 +74,10 @@ class Triple {
ppc64le,// PPC64LE: powerpc64le
r600, // R600: AMD GPUs HD2XXX - HD6XXX
amdgcn, // AMDGCN: AMD GCN GPUs
-riscv32,// RISC-V (32-bit): riscv32
-riscv64,// RISC-V (64-bit): riscv64
+riscv32,// RISC-V (32-bit, little endian): riscv32
+riscv64,// RISC-V (64-bit, little endian): riscv64
+riscv32be, // RISC-V (32-bit, big endian): riscv32be
+riscv64be, // RISC-V (64-bit, big endian): riscv64be
sparc, // Sparc: sparc
sparcv9,// Sparcv9: Sparcv9
sparcel,// Sparc: (endianness = little). NB: 'Sparcle' is a CPU
variant
@@ -1069,10 +1071,14 @@ class Triple {
}
/// Tests whether the target is 32-bit RISC-V.
- bool isRISCV32() const { return getArch() == Triple::riscv32; }
+ bool isRISCV32() const {
+return getArch() == Triple::riscv32 || getArch() == Triple::riscv32be;
+ }
/// Tests whether the target is 64-bit RISC-V.
- bool isRISCV64() const { return getArch() == Triple::riscv64; }
+ bool isRISCV64() const {
+return getArch() == Triple::riscv64 || getArch() == Triple::riscv64be;
+ }
/// Tests whether the target is RISC-V (32- and 6
[clang] [llvm] [llvm-objcopy][libObject] Add RISC-V big-endian support (PR #146913)
@@ -48,62 +48,64 @@ class Triple {
enum ArchType {
UnknownArch,
-arm,// ARM (little endian): arm, armv.*, xscale
-armeb, // ARM (big endian): armeb
-aarch64,// AArch64 (little endian): aarch64
-aarch64_be, // AArch64 (big endian): aarch64_be
-aarch64_32, // AArch64 (little endian) ILP32: aarch64_32
-arc,// ARC: Synopsys ARC
-avr,// AVR: Atmel AVR microcontroller
-bpfel, // eBPF or extended BPF or 64-bit BPF (little endian)
-bpfeb, // eBPF or extended BPF or 64-bit BPF (big endian)
-csky, // CSKY: csky
-dxil, // DXIL 32-bit DirectX bytecode
-hexagon,// Hexagon: hexagon
-loongarch32,// LoongArch (32-bit): loongarch32
-loongarch64,// LoongArch (64-bit): loongarch64
-m68k, // M68k: Motorola 680x0 family
-mips, // MIPS: mips, mipsallegrex, mipsr6
-mipsel, // MIPSEL: mipsel, mipsallegrexe, mipsr6el
-mips64, // MIPS64: mips64, mips64r6, mipsn32, mipsn32r6
-mips64el, // MIPS64EL: mips64el, mips64r6el, mipsn32el, mipsn32r6el
-msp430, // MSP430: msp430
-ppc,// PPC: powerpc
-ppcle, // PPCLE: powerpc (little endian)
-ppc64, // PPC64: powerpc64, ppu
-ppc64le,// PPC64LE: powerpc64le
-r600, // R600: AMD GPUs HD2XXX - HD6XXX
-amdgcn, // AMDGCN: AMD GCN GPUs
-riscv32,// RISC-V (32-bit): riscv32
-riscv64,// RISC-V (64-bit): riscv64
-sparc, // Sparc: sparc
-sparcv9,// Sparcv9: Sparcv9
-sparcel,// Sparc: (endianness = little). NB: 'Sparcle' is a CPU
variant
-systemz,// SystemZ: s390x
-tce,// TCE (http://tce.cs.tut.fi/): tce
-tcele, // TCE little endian (http://tce.cs.tut.fi/): tcele
-thumb, // Thumb (little endian): thumb, thumbv.*
-thumbeb,// Thumb (big endian): thumbeb
-x86,// X86: i[3-9]86
-x86_64, // X86-64: amd64, x86_64
-xcore, // XCore: xcore
-xtensa, // Tensilica: Xtensa
-nvptx, // NVPTX: 32-bit
-nvptx64,// NVPTX: 64-bit
-amdil, // AMDIL
-amdil64,// AMDIL with 64-bit pointers
-hsail, // AMD HSAIL
-hsail64,// AMD HSAIL with 64-bit pointers
-spir, // SPIR: standard portable IR for OpenCL 32-bit version
-spir64, // SPIR: standard portable IR for OpenCL 64-bit version
-spirv, // SPIR-V with logical memory layout.
-spirv32,// SPIR-V with 32-bit pointers
-spirv64,// SPIR-V with 64-bit pointers
-kalimba,// Kalimba: generic kalimba
-shave, // SHAVE: Movidius vector VLIW processors
-lanai, // Lanai: Lanai 32-bit
-wasm32, // WebAssembly with 32-bit pointers
-wasm64, // WebAssembly with 64-bit pointers
+arm, // ARM (little endian): arm, armv.*, xscale
+armeb, // ARM (big endian): armeb
+aarch64, // AArch64 (little endian): aarch64
+aarch64_be, // AArch64 (big endian): aarch64_be
+aarch64_32, // AArch64 (little endian) ILP32: aarch64_32
+arc, // ARC: Synopsys ARC
+avr, // AVR: Atmel AVR microcontroller
+bpfel, // eBPF or extended BPF or 64-bit BPF (little endian)
+bpfeb, // eBPF or extended BPF or 64-bit BPF (big endian)
+csky,// CSKY: csky
+dxil,// DXIL 32-bit DirectX bytecode
+hexagon, // Hexagon: hexagon
+loongarch32, // LoongArch (32-bit): loongarch32
+loongarch64, // LoongArch (64-bit): loongarch64
+m68k,// M68k: Motorola 680x0 family
+mips,// MIPS: mips, mipsallegrex, mipsr6
+mipsel, // MIPSEL: mipsel, mipsallegrexe, mipsr6el
+mips64, // MIPS64: mips64, mips64r6, mipsn32, mipsn32r6
+mips64el,// MIPS64EL: mips64el, mips64r6el, mipsn32el, mipsn32r6el
+msp430, // MSP430: msp430
+ppc, // PPC: powerpc
+ppcle, // PPCLE: powerpc (little endian)
+ppc64, // PPC64: powerpc64, ppu
+ppc64le, // PPC64LE: powerpc64le
+r600,// R600: AMD GPUs HD2XXX - HD6XXX
+amdgcn, // AMDGCN: AMD GCN GPUs
+riscv32, // RISC-V (32-bit, little endian): riscv32
+riscv64, // RISC-V (64-bit, little endian): riscv64
+riscv32be, // RISC-V (32-bit, big endian): riscv32be
+riscv64be, // RISC-V (64-bit, big endian): riscv64be
+sparc, // Sparc: sparc
+sparcv9, // Sparcv9: Sparcv9
+sparcel, // Sparc: (endianness = little). NB: 'Sparcle' is a CPU
variant
+systemz, // SystemZ: s390x
+tce, // TCE (http://tce.cs.tut.fi/): tce
+tcele, // TCE little endian (http://tce.cs.tut.fi/): tcele
+thumb, // Thumb (little endian):
[clang] Fix scope of typedefs present inside a template class (PR #146729)
OCHyams wrote: I don't really feel comfortable reviewing Clang patches, living mostly on the LLVM side of things. @dwblaikie do you know who could take a look? https://github.com/llvm/llvm-project/pull/146729 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Implement Builtins for XAndesBFHCvt extension. (PR #148804)
llvmbot wrote:
@llvm/pr-subscribers-backend-x86
Author: Jim Lin (tclin914)
Changes
XAndesBFHCvt provides two builtins functions for converting between float and
bf16. Users can use them to convert bf16 values loaded from memory to float,
perform arithmetic operations, then convert them back to bf16 and store them to
memory.
The load/store and move operations for bf16 will be handled in a later patch.
---
Full diff: https://github.com/llvm/llvm-project/pull/148804.diff
11 Files Affected:
- (modified) clang/include/clang/Basic/BuiltinsRISCV.td (+5)
- (added) clang/include/clang/Basic/BuiltinsRISCVXAndes.td (+27)
- (modified) clang/lib/CodeGen/TargetBuiltins/RISCV.cpp (+8)
- (modified) clang/lib/Headers/CMakeLists.txt (+1)
- (added) clang/lib/Headers/riscv_nds.h (+35)
- (added) clang/test/CodeGen/RISCV/riscv-xandesbfhcvt-c-api.c (+25)
- (added) clang/test/CodeGen/RISCV/riscv-xandesbfhcvt.c (+23)
- (modified) llvm/include/llvm/IR/IntrinsicsRISCVXAndes.td (+9)
- (modified) llvm/lib/Target/RISCV/RISCVISelLowering.cpp (+1-1)
- (modified) llvm/lib/Target/RISCV/RISCVInstrInfoXAndes.td (+7)
- (added) llvm/test/CodeGen/RISCV/xandesbfhcvt.ll (+27)
``diff
diff --git a/clang/include/clang/Basic/BuiltinsRISCV.td
b/clang/include/clang/Basic/BuiltinsRISCV.td
index b2cd5648e008f..5927eaf80d57a 100644
--- a/clang/include/clang/Basic/BuiltinsRISCV.td
+++ b/clang/include/clang/Basic/BuiltinsRISCV.td
@@ -157,3 +157,8 @@ def pause : RISCVBuiltin<"void()">;
// XCV extensions.
//===--===//
include "clang/Basic/BuiltinsRISCVXCV.td"
+
+//===--===//
+// XAndes extensions.
+//===--===//
+include "clang/Basic/BuiltinsRISCVXAndes.td"
diff --git a/clang/include/clang/Basic/BuiltinsRISCVXAndes.td
b/clang/include/clang/Basic/BuiltinsRISCVXAndes.td
new file mode 100644
index 0..ea9a7166bc6e8
--- /dev/null
+++ b/clang/include/clang/Basic/BuiltinsRISCVXAndes.td
@@ -0,0 +1,27 @@
+//==- BuiltinsRISCVXAndes.td - RISC-V Andes Builtin database -*- C++
-*-==//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the Andes-specific builtin function database. Users of
+// this file must define the BUILTIN macro to make use of this information.
+//
+//===--===//
+
+class RISCVXAndesBuiltin :
TargetBuiltin {
+ let Spellings = ["__builtin_riscv_nds_" # NAME];
+ let Prototype = prototype;
+ let Features = features;
+}
+
+let Attributes = [NoThrow, Const] in {
+//===--===//
+// XAndesBFHCvt extension.
+//===--===//
+
+def fcvt_s_bf16 : RISCVXAndesBuiltin<"float(__bf16)", "xandesbfhcvt">;
+def fcvt_bf16_s : RISCVXAndesBuiltin<"__bf16(float)", "xandesbfhcvt">;
+} // Attributes = [NoThrow, Const]
diff --git a/clang/lib/CodeGen/TargetBuiltins/RISCV.cpp
b/clang/lib/CodeGen/TargetBuiltins/RISCV.cpp
index 89e3f6f203df3..63092139af4fa 100644
--- a/clang/lib/CodeGen/TargetBuiltins/RISCV.cpp
+++ b/clang/lib/CodeGen/TargetBuiltins/RISCV.cpp
@@ -413,6 +413,14 @@ Value *CodeGenFunction::EmitRISCVBuiltinExpr(unsigned
BuiltinID,
ID = Intrinsic::riscv_cv_alu_subuRN;
break;
+ // XAndesBFHCvt
+ case RISCV::BI__builtin_riscv_nds_fcvt_s_bf16:
+ID = Intrinsic::riscv_nds_fcvt_s_bf16;
+break;
+ case RISCV::BI__builtin_riscv_nds_fcvt_bf16_s:
+ID = Intrinsic::riscv_nds_fcvt_bf16_s;
+break;
+
// Vector builtins are handled from here.
#include "clang/Basic/riscv_vector_builtin_cg.inc"
diff --git a/clang/lib/Headers/CMakeLists.txt b/clang/lib/Headers/CMakeLists.txt
index c96d209c1fc0c..76ac8409e568f 100644
--- a/clang/lib/Headers/CMakeLists.txt
+++ b/clang/lib/Headers/CMakeLists.txt
@@ -127,6 +127,7 @@ set(riscv_files
riscv_bitmanip.h
riscv_corev_alu.h
riscv_crypto.h
+ riscv_nds.h
riscv_ntlh.h
sifive_vector.h
andes_vector.h
diff --git a/clang/lib/Headers/riscv_nds.h b/clang/lib/Headers/riscv_nds.h
new file mode 100644
index 0..5ccef00e332ed
--- /dev/null
+++ b/clang/lib/Headers/riscv_nds.h
@@ -0,0 +1,35 @@
+/*=== riscv_nds.h - Andes intrinsics ---===
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+ *===---===
+ */
+
+#i
[clang] [libclc] [clang] Add the ability to link libclc OpenCL libraries (PR #146503)
frasercrmck wrote: ping, thanks. https://github.com/llvm/llvm-project/pull/146503 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LifetimeSafety] Make the dataflow analysis generic (PR #148222)
https://github.com/usx95 updated
https://github.com/llvm/llvm-project/pull/148222
>From 2bff132be9082f85835f22e73550447f7b880e13 Mon Sep 17 00:00:00 2001
From: Utkarsh Saxena
Date: Fri, 11 Jul 2025 11:11:47 +
Subject: [PATCH] [LifetimeSafety] Add expired loans analysis
---
clang/lib/Analysis/LifetimeSafety.cpp | 395 ++
.../Sema/warn-lifetime-safety-dataflow.cpp| 30 +-
2 files changed, 234 insertions(+), 191 deletions(-)
diff --git a/clang/lib/Analysis/LifetimeSafety.cpp
b/clang/lib/Analysis/LifetimeSafety.cpp
index bf67bea6c9933..0b4241cdf404c 100644
--- a/clang/lib/Analysis/LifetimeSafety.cpp
+++ b/clang/lib/Analysis/LifetimeSafety.cpp
@@ -496,7 +496,162 @@ class FactGenerator : public
ConstStmtVisitor {
};
// = //
-// The Dataflow Lattice
+// Generic Dataflow Analysis
+// = //
+/// A generic, policy-based driver for forward dataflow analyses. It combines
+/// the dataflow runner and the transferer logic into a single class hierarchy.
+///
+/// The derived class is expected to provide:
+/// - A `Lattice` type.
+/// - `const char *getAnalysisName() const`
+/// - `Lattice getInitialState();` The initial state at the function entry.
+/// - `Lattice join(Lattice, Lattice);` Merges states from multiple CFG paths.
+/// - `Lattice transfer(Lattice, const FactType&);` Defines how a single
+/// lifetime-relevant `Fact` transforms the lattice state. Only overloads
+/// for facts relevant to the analysis need to be implemented.
+///
+/// \tparam Derived The CRTP derived class that implements the specific
+/// analysis.
+/// \tparam LatticeType The dataflow lattice used by the analysis.
+/// TODO: Maybe use the dataflow framework! The framework might need changes
+/// to support the current comparison done at block-entry.
+template class DataflowAnalysis {
+public:
+ using Lattice = LatticeType;
+
+private:
+ const CFG &Cfg;
+ AnalysisDeclContext &AC;
+
+ llvm::DenseMap BlockEntryStates;
+ llvm::DenseMap BlockExitStates;
+
+protected:
+ FactManager &AllFacts;
+
+ explicit DataflowAnalysis(const CFG &C, AnalysisDeclContext &AC,
+FactManager &F)
+ : Cfg(C), AC(AC), AllFacts(F) {}
+
+public:
+ void run() {
+Derived &D = static_cast(*this);
+llvm::TimeTraceScope Time(D.getAnalysisName());
+
+ForwardDataflowWorklist Worklist(Cfg, AC);
+const CFGBlock *Entry = &Cfg.getEntry();
+BlockEntryStates[Entry] = D.getInitialState();
+Worklist.enqueueBlock(Entry);
+
+while (const CFGBlock *B = Worklist.dequeue()) {
+ Lattice EntryState = getEntryState(B);
+ Lattice ExitState = transferBlock(B, EntryState);
+ BlockExitStates[B] = ExitState;
+
+ for (const CFGBlock *Successor : B->succs()) {
+Lattice OldSuccEntryState = getEntryState(Successor);
+Lattice NewSuccEntryState = D.join(OldSuccEntryState, ExitState);
+
+// Enqueue the successor if its entry state has changed.
+if (OldSuccEntryState == D.getInitialState() ||
+NewSuccEntryState != OldSuccEntryState) {
+ BlockEntryStates[Successor] = NewSuccEntryState;
+ Worklist.enqueueBlock(Successor);
+}
+ }
+}
+ }
+
+ Lattice getEntryState(const CFGBlock *B) const {
+return BlockEntryStates.lookup(B);
+ }
+
+ Lattice getExitState(const CFGBlock *B) const {
+return BlockExitStates.lookup(B);
+ }
+
+ void dump() const {
+const Derived *D = static_cast(this);
+llvm::dbgs() << "==\n";
+llvm::dbgs() << " " << D->getAnalysisName() << " results:\n";
+llvm::dbgs() << "==\n";
+const CFGBlock &B = Cfg.getExit();
+getExitState(&B).dump(llvm::dbgs());
+ }
+
+private:
+ /// Computes the exit state of a block by applying all its facts sequentially
+ /// to a given entry state.
+ /// TODO: We might need to store intermediate states per-fact in the block
for
+ /// later analysis.
+ Lattice transferBlock(const CFGBlock *Block, Lattice EntryState) {
+Lattice BlockState = EntryState;
+for (const Fact *F : AllFacts.getFacts(Block)) {
+ BlockState = transferFact(BlockState, F);
+}
+return BlockState;
+ }
+
+ Lattice transferFact(Lattice In, const Fact *F) {
+Derived *d = static_cast(this);
+switch (F->getKind()) {
+case Fact::Kind::Issue:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::Expire:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::AssignOrigin:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::ReturnOfOrigin:
+ return d->transfer(In, *F->getAs());
+}
+llvm_unreachable("Unknown fact kind");
+ }
+
+public:
+ Lattice transfer(Lattice In, const IssueFact &) { return In;
[clang] [Clang] Remove explicit object from non member function. (PR #148807)
https://github.com/cor3ntin updated
https://github.com/llvm/llvm-project/pull/148807
>From 25d5589b47b39779958c94011814cb68fd7ea374 Mon Sep 17 00:00:00 2001
From: Corentin Jabot
Date: Tue, 15 Jul 2025 11:06:03 +0200
Subject: [PATCH] [Clang] Remove explicit object from non member function.
To avoid crashing later (as we assume only member functions
can have explicit parameters)
Fixes #113185
---
clang/docs/ReleaseNotes.rst| 1 +
clang/lib/Sema/SemaType.cpp| 4 +++-
clang/test/SemaCXX/cxx2b-deducing-this.cpp | 10 ++
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index e8c85483e9864..40213cd103c43 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -953,6 +953,7 @@ Bug Fixes to C++ Support
- Fix a bug where private access specifier of overloaded function not
respected. (#GH107629)
- Correctly handles calling an explicit object member function template
overload set
through its address (``(&Foo::bar)()``).
+- Fix a crash when using an explicit object parameter in a non-member
function. (#GH113185)
- Fix a crash when forming an invalid call to an operator with an explicit
object member. (#GH147121)
- Correctly handle allocations in the condition of a ``if
constexpr``.(#GH120197) (#GH134820)
- Fixed a crash when handling invalid member using-declaration in C++20+ mode.
(#GH63254)
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 661746731fdcc..bb114aff2366b 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -4860,7 +4860,9 @@ static TypeSourceInfo
*GetFullTypeForDeclarator(TypeProcessingState &state,
S.Diag(First->getBeginLoc(),
diag::err_explicit_object_parameter_invalid)
<< First->getSourceRange();
-
+ // Do let non-member function have explicit parameters
+ // to not break assumptions elsewhere in the code.
+ First->setExplicitObjectParameterLoc(SourceLocation());
D.setInvalidType();
AreDeclaratorChunksValid = false;
}
diff --git a/clang/test/SemaCXX/cxx2b-deducing-this.cpp
b/clang/test/SemaCXX/cxx2b-deducing-this.cpp
index 6987d0c020457..2253cbb26285e 100644
--- a/clang/test/SemaCXX/cxx2b-deducing-this.cpp
+++ b/clang/test/SemaCXX/cxx2b-deducing-this.cpp
@@ -1347,3 +1347,13 @@ int main() {
// expected-note@#S3-f-cand2 {{candidate function not viable: no known
conversion from 'S3' to 'int' for object argument}}
}
}
+
+namespace GH113185 {
+
+void Bar(this int) { // expected-note {{candidate function}}
+// expected-error@-1 {{an explicit object parameter cannot appear in a
non-member function}}
+Bar(0);
+Bar(); // expected-error {{no matching function for call to 'Bar'}}
+}
+
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LifetimeSafety] Make the dataflow analysis generic (PR #148222)
https://github.com/usx95 updated
https://github.com/llvm/llvm-project/pull/148222
>From 5d10f007a81861e513c1483163947182b109c92d Mon Sep 17 00:00:00 2001
From: Utkarsh Saxena
Date: Fri, 11 Jul 2025 11:11:47 +
Subject: [PATCH 1/3] [LifetimeSafety] Add expired loans analysis
---
clang/lib/Analysis/LifetimeSafety.cpp | 394 ++
.../Sema/warn-lifetime-safety-dataflow.cpp| 30 +-
2 files changed, 233 insertions(+), 191 deletions(-)
diff --git a/clang/lib/Analysis/LifetimeSafety.cpp
b/clang/lib/Analysis/LifetimeSafety.cpp
index bf67bea6c9933..bb641d204e963 100644
--- a/clang/lib/Analysis/LifetimeSafety.cpp
+++ b/clang/lib/Analysis/LifetimeSafety.cpp
@@ -496,7 +496,162 @@ class FactGenerator : public
ConstStmtVisitor {
};
// = //
-// The Dataflow Lattice
+// Generic Dataflow Analysis
+// = //
+/// A generic, policy-based driver for forward dataflow analyses. It combines
+/// the dataflow runner and the transferer logic into a single class hierarchy.
+///
+/// The derived class is expected to provide:
+/// - A `Lattice` type.
+/// - `StringRef getAnalysisName() const`
+/// - `Lattice getInitialState();` The initial state at the function entry.
+/// - `Lattice join(Lattice, Lattice);` Merges states from multiple CFG paths.
+/// - `Lattice transfer(Lattice, const FactType&);` Defines how a single
+/// lifetime-relevant `Fact` transforms the lattice state. Only overloads
+/// for facts relevant to the analysis need to be implemented.
+///
+/// \tparam Derived The CRTP derived class that implements the specific
+/// analysis.
+/// \tparam LatticeType The dataflow lattice used by the analysis.
+/// TODO: Maybe use the dataflow framework! The framework might need changes
+/// to support the current comparison done at block-entry.
+template class DataflowAnalysis {
+public:
+ using Lattice = LatticeType;
+
+private:
+ const CFG &Cfg;
+ AnalysisDeclContext &AC;
+
+ llvm::DenseMap BlockEntryStates;
+ llvm::DenseMap BlockExitStates;
+
+protected:
+ FactManager &AllFacts;
+
+ explicit DataflowAnalysis(const CFG &C, AnalysisDeclContext &AC,
+FactManager &F)
+ : Cfg(C), AC(AC), AllFacts(F) {}
+
+public:
+ void run() {
+Derived &D = static_cast(*this);
+llvm::TimeTraceScope Time(D.getAnalysisName());
+
+ForwardDataflowWorklist Worklist(Cfg, AC);
+const CFGBlock *Entry = &Cfg.getEntry();
+BlockEntryStates[Entry] = D.getInitialState();
+Worklist.enqueueBlock(Entry);
+
+while (const CFGBlock *B = Worklist.dequeue()) {
+ Lattice EntryState = getEntryState(B);
+ Lattice ExitState = transferBlock(B, EntryState);
+ BlockExitStates[B] = ExitState;
+
+ for (const CFGBlock *Successor : B->succs()) {
+Lattice OldSuccEntryState = getEntryState(Successor);
+Lattice NewSuccEntryState = D.join(OldSuccEntryState, ExitState);
+
+// Enqueue the successor if its entry state has changed.
+if (OldSuccEntryState == D.getInitialState() ||
+NewSuccEntryState != OldSuccEntryState) {
+ BlockEntryStates[Successor] = NewSuccEntryState;
+ Worklist.enqueueBlock(Successor);
+}
+ }
+}
+ }
+
+ Lattice getEntryState(const CFGBlock *B) const {
+return BlockEntryStates.lookup(B);
+ }
+
+ Lattice getExitState(const CFGBlock *B) const {
+return BlockExitStates.lookup(B);
+ }
+
+ void dump() const {
+const Derived *D = static_cast(this);
+llvm::dbgs() << "==\n";
+llvm::dbgs() << " " << D->getAnalysisName() << " results:\n";
+llvm::dbgs() << "==\n";
+const CFGBlock &B = Cfg.getExit();
+getExitState(&B).dump(llvm::dbgs());
+ }
+
+private:
+ /// Computes the exit state of a block by applying all its facts sequentially
+ /// to a given entry state.
+ /// TODO: We might need to store intermediate states per-fact in the block
for
+ /// later analysis.
+ Lattice transferBlock(const CFGBlock *Block, Lattice EntryState) {
+Lattice BlockState = EntryState;
+for (const Fact *F : AllFacts.getFacts(Block)) {
+ BlockState = transferFact(BlockState, F);
+}
+return BlockState;
+ }
+
+ Lattice transferFact(Lattice In, const Fact *F) {
+Derived *d = static_cast(this);
+switch (F->getKind()) {
+case Fact::Kind::Issue:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::Expire:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::AssignOrigin:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::ReturnOfOrigin:
+ return d->transfer(In, *F->getAs());
+}
+llvm_unreachable("Unknown fact kind");
+ }
+
+public:
+ Lattice transfer(Lattice In, const IssueFact &) { return I
[clang] [clang-tools-extra] [clang-query] Allow for trailing comma in matchers (PR #148018)
@@ -0,0 +1,10 @@ +// RUN: clang-query -c "match \ +// RUN: functionDecl( \ +// RUN: hasName( \ +// RUN: \"foo\", \ +// RUN: ), \ +// RUN: ) \ +// RUN: " %s -- | FileCheck %s + +// CHECK: trailing-comma.c:10:1: note: "root" binds here one-d-wide wrote: Done. Also noticed that line escaping eats up new line characters in the initial test. https://github.com/llvm/llvm-project/pull/148018 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][python][test] Move python binding tests to lit framework (PR #148802)
https://github.com/DeinAlptraum closed https://github.com/llvm/llvm-project/pull/148802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CodeGen][ObjC] Include all referenced protocols in protocol list (PR #148827)
https://github.com/davidchisnall approved this pull request. Looks good to me, thank you. There's a clang-format error, but once that's fixed we should be good to merge it. https://github.com/llvm/llvm-project/pull/148827 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Add option for -nolibc in Driver/ToolChains/Baremetal.cpp (PR #145700)
https://github.com/vhscampos approved this pull request. Approved from my side. https://github.com/llvm/llvm-project/pull/145700 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [lldb] [clang] Extend SourceLocation to 64 bits. (PR #147292)
AaronBallman wrote: Hello all! There was a request to hold a Clang Area Team discussion about this topic, which is scheduled for [Thur Jul 17 at 4pm Eastern Time](https://www.timeanddate.com/worldclock/converter.html?iso=20250717T20&p1=1440&p2=1241&p3=4747&p4=195). Link to the meeting teleconference is: https://meet.google.com/ktv-ifef-bym https://github.com/llvm/llvm-project/pull/147292 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Fix a crash when parsing an invalid `decltype` (PR #148798)
https://github.com/cor3ntin updated
https://github.com/llvm/llvm-project/pull/148798
>From c80347a825264474a51ee6e638434d3454a0a7e3 Mon Sep 17 00:00:00 2001
From: Corentin Jabot
Date: Tue, 15 Jul 2025 09:38:59 +0200
Subject: [PATCH 1/2] [Clang] Fix a crash when parsing an invalid `decltype`
We would try to exact an annotated token before checking
if it was valid, leading to a crash when `decltype` was the only
token that was parsed (which can happen in the absense of opening
paren)
Fixes #114815
---
clang/lib/Parse/ParseDeclCXX.cpp | 6 +++---
clang/test/Parser/gh114815.cpp | 6 ++
2 files changed, 9 insertions(+), 3 deletions(-)
create mode 100644 clang/test/Parser/gh114815.cpp
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index 59e6e0af4b5b0..5bdc13d75a9e1 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -1132,14 +1132,14 @@ void Parser::AnnotateExistingDecltypeSpecifier(const
DeclSpec &DS,
SourceLocation EndLoc) {
// make sure we have a token we can turn into an annotation token
if (PP.isBacktrackEnabled()) {
-PP.RevertCachedTokens(1);
-if (DS.getTypeSpecType() == TST_error) {
+if (DS.getTypeSpecType() == TST_error)
// We encountered an error in parsing 'decltype(...)' so lets annotate
all
// the tokens in the backtracking cache - that we likely had to skip over
// to get to a token that allows us to resume parsing, such as a
// semi-colon.
EndLoc = PP.getLastCachedTokenLocation();
-}
+else
+ PP.RevertCachedTokens(1);
} else
PP.EnterToken(Tok, /*IsReinject*/ true);
diff --git a/clang/test/Parser/gh114815.cpp b/clang/test/Parser/gh114815.cpp
new file mode 100644
index 0..6a89384e9e66d
--- /dev/null
+++ b/clang/test/Parser/gh114815.cpp
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -verify %s -std=c++11 -fsyntax-only
+
+#define ID(X) X
+extern int ID(decltype);
+// expected-error@-1 {{expected '(' after 'decltype'}} \
+// expected-error@-1 {{expected unqualified-id}}
>From b8b2f2598d560f5777398eed2ddd451f0b279019 Mon Sep 17 00:00:00 2001
From: Corentin Jabot
Date: Tue, 15 Jul 2025 13:57:52 +0200
Subject: [PATCH 2/2] turns out, we don't need this code at all
---
clang/lib/Parse/ParseDeclCXX.cpp | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index 5bdc13d75a9e1..adcdba6f8b3aa 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -1132,14 +1132,7 @@ void Parser::AnnotateExistingDecltypeSpecifier(const
DeclSpec &DS,
SourceLocation EndLoc) {
// make sure we have a token we can turn into an annotation token
if (PP.isBacktrackEnabled()) {
-if (DS.getTypeSpecType() == TST_error)
- // We encountered an error in parsing 'decltype(...)' so lets annotate
all
- // the tokens in the backtracking cache - that we likely had to skip over
- // to get to a token that allows us to resume parsing, such as a
- // semi-colon.
- EndLoc = PP.getLastCachedTokenLocation();
-else
- PP.RevertCachedTokens(1);
+PP.RevertCachedTokens(1);
} else
PP.EnterToken(Tok, /*IsReinject*/ true);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR] Add VTableAddrPointOp (PR #148730)
@@ -1669,6 +1669,51 @@ def GetGlobalOp : CIR_Op<"get_global",
}];
}
+//===--===//
+// VTableAddrPointOp
+//===--===//
+
+def VTableAddrPointOp : CIR_Op<"vtable.address_point",
+[Pure, DeclareOpInterfaceMethods]> {
+ let summary = "Get the vtable (global variable) address point";
+ let description = [{
+The `vtable.address_point` operation retrieves the effective address
+(address point) of a C++ virtual table. An object internal `__vptr`
+gets initializated on top of the value returned by this operation.
+
+`address_point.index` (vtable index) provides the appropriate vtable within
+the vtable group (as specified by Itanium ABI), and `address_point.offset`
+(address point index) the actual address point within that vtable.
+
+The return type is always a `!cir.ptr i32>>`.
+
+Example:
+```mlir
+cir.global linkonce_odr @_ZTV1B = ...
+...
+%3 = cir.vtable.address_point(@_ZTV1B, address_point = ) : !cir.ptr i32>>
+```
+ }];
+
+ let arguments = (ins OptionalAttr:$name,
+ Optional:$sym_addr,
xlauko wrote:
I believe this should not be CIR_AnyType; should it be
CIR_PtrTo instead? However, neither the description nor the
example clarifies what is expected for sym_addr. It would be helpful to include
that in the documentation as well.
https://github.com/llvm/llvm-project/pull/148730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR] Add VTableAddrPointOp (PR #148730)
@@ -1669,6 +1669,51 @@ def GetGlobalOp : CIR_Op<"get_global",
}];
}
+//===--===//
+// VTableAddrPointOp
+//===--===//
+
+def VTableAddrPointOp : CIR_Op<"vtable.address_point",
+[Pure, DeclareOpInterfaceMethods]> {
+ let summary = "Get the vtable (global variable) address point";
+ let description = [{
+The `vtable.address_point` operation retrieves the effective address
+(address point) of a C++ virtual table. An object internal `__vptr`
+gets initializated on top of the value returned by this operation.
+
+`address_point.index` (vtable index) provides the appropriate vtable within
+the vtable group (as specified by Itanium ABI), and `address_point.offset`
+(address point index) the actual address point within that vtable.
+
+The return type is always a `!cir.ptr i32>>`.
+
+Example:
+```mlir
+cir.global linkonce_odr @_ZTV1B = ...
+...
+%3 = cir.vtable.address_point(@_ZTV1B, address_point = ) : !cir.ptr i32>>
+```
+ }];
+
+ let arguments = (ins OptionalAttr:$name,
+ Optional:$sym_addr,
+ AddressPointAttr:$address_point);
xlauko wrote:
```suggestion
let arguments = (ins
OptionalAttr:$name,
Optional:$sym_addr,
AddressPointAttr:$address_point
);
```
https://github.com/llvm/llvm-project/pull/148730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR] Add VTableAddrPointOp (PR #148730)
@@ -515,5 +515,35 @@ def BitfieldInfoAttr : CIR_Attr<"BitfieldInfo",
"bitfield_info"> {
];
}
+//===--===//
+// AddressPointAttr
+//===--===//
+
+def AddressPointAttr : CIR_Attr<"AddressPoint", "address_point"> {
xlauko wrote:
```suggestion
def CIR_AddressPointAttr : CIR_Attr<"AddressPoint", "address_point"> {
```
https://github.com/llvm/llvm-project/pull/148730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR] Add VTableAddrPointOp (PR #148730)
@@ -515,5 +515,35 @@ def BitfieldInfoAttr : CIR_Attr<"BitfieldInfo",
"bitfield_info"> {
];
}
+//===--===//
+// AddressPointAttr
+//===--===//
+
+def AddressPointAttr : CIR_Attr<"AddressPoint", "address_point"> {
+ let summary = "Address point attribute";
+
+ let description = [{
+ Attribute specifying the address point within a C++ virtual table (vtable).
+
+ The `index` (vtable index) parameter identifies which vtable to use within a
+ vtable group, while the `offset` (address point index) specifies the offset
+ within that vtable where the address begins.
+
+ Example:
+ ```mlir
+ cir.global linkonce_odr @_ZTV1B = ...
+ ...
+ %3 = cir.vtable.address_point(@_ZTV1B, address_point = )
+ : !cir.ptr i32>>
+ ```
xlauko wrote:
```suggestion
Attribute specifying the address point within a C++ virtual table (vtable).
The `index` (vtable index) parameter identifies which vtable to use within a
vtable group, while the `offset` (address point index) specifies the offset
within that vtable where the address begins.
Example:
```mlir
cir.global linkonce_odr @_ZTV1B = ...
...
%3 = cir.vtable.address_point(@_ZTV1B, address_point = )
: !cir.ptr i32>>
```
```
https://github.com/llvm/llvm-project/pull/148730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR] Add VTableAddrPointOp (PR #148730)
@@ -515,5 +515,35 @@ def BitfieldInfoAttr : CIR_Attr<"BitfieldInfo",
"bitfield_info"> {
];
}
+//===--===//
+// AddressPointAttr
+//===--===//
+
+def AddressPointAttr : CIR_Attr<"AddressPoint", "address_point"> {
xlauko wrote:
Is there any reason to have this as a special attribute and not just two
`I32Attr` in `VTableAddrPointOp`?
I scanned through incubator codebase and all uses I found it is always accessed
directly to index or offset, e.g. `op.getAddressPointAttr().getIndex()`,
`op.getAddressPointAttr().getOffset()`.
Therefore I believe we can remove the attribute entirely and just have
`op.getAddressPointIndex()` and `op.gettAddressPointOffset()`?
This can clean up address point op assembly as weel to something like:
```
cir.vtable_address_point @_ZTV1B [index = 0, offset = 2] : !cir.ptr i32>>
```
^ This just my suggestion removing also some parenthesis and adding `_` after
`vtable` in op name.
https://github.com/llvm/llvm-project/pull/148730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CodeGen][ObjC] Include all referenced protocols in protocol list (PR #148827)
https://github.com/hmelder updated
https://github.com/llvm/llvm-project/pull/148827
>From 07f00da14d0716da4ad3637e9296e68fee95f64e Mon Sep 17 00:00:00 2001
From: hmelder
Date: Tue, 15 Jul 2025 13:09:28 +0200
Subject: [PATCH] [CodeGen][ObjC] Include all referenced protocols in protocol
list
When constructing the protocol list in the class metadata generation
(`GenerateClass`), only the protocols from the base class are added but
not from class extensions.
This is fixed by using `all_referenced_protocol_{begin, end}` instead of
`protocol_{begin, end}`, matching the behaviour on Apple platforms.
---
clang/lib/CodeGen/CGObjCGNU.cpp | 4 ++--
clang/test/CodeGenObjC/gnustep2-class-exts.m | 25
2 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644 clang/test/CodeGenObjC/gnustep2-class-exts.m
diff --git a/clang/lib/CodeGen/CGObjCGNU.cpp b/clang/lib/CodeGen/CGObjCGNU.cpp
index d828702cbb87f..126b46e08df48 100644
--- a/clang/lib/CodeGen/CGObjCGNU.cpp
+++ b/clang/lib/CodeGen/CGObjCGNU.cpp
@@ -1942,8 +1942,8 @@ class CGObjCGNUstep2 : public CGObjCGNUstep {
// struct objc_class *sibling_class
classFields.addNullPointer(PtrTy);
// struct objc_protocol_list *protocols;
-auto RuntimeProtocols = GetRuntimeProtocolList(classDecl->protocol_begin(),
- classDecl->protocol_end());
+auto RuntimeProtocols =
GetRuntimeProtocolList(classDecl->all_referenced_protocol_begin(),
+
classDecl->all_referenced_protocol_end());
SmallVector Protocols;
for (const auto *I : RuntimeProtocols)
Protocols.push_back(GenerateProtocolRef(I));
diff --git a/clang/test/CodeGenObjC/gnustep2-class-exts.m
b/clang/test/CodeGenObjC/gnustep2-class-exts.m
new file mode 100644
index 0..b065490a7d8d8
--- /dev/null
+++ b/clang/test/CodeGenObjC/gnustep2-class-exts.m
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple aarch64-unknown-linux-gnu
-fobjc-runtime=gnustep-2.2 -emit-llvm -o - %s | FileCheck %s
+
+@protocol BaseProtocol
+@end
+
+@protocol ExtendedProtocol
+@end
+
+@interface TestClass
+
+-(void) Meth;
+@end
+
+@interface TestClass ()
+@end
+
+@implementation TestClass
+@end
+
+// Check that we emit metadata for both protocols
+// CHECK: @._OBJC_PROTOCOL_ExtendedProtocol = global
+// CHECK: @._OBJC_PROTOCOL_BaseProtocol = global
+
+// Check that we deduplicate the protocol list
+// CHECK: @.objc_protocol_list{{\.[0-9]*}} = internal global { ptr, i64, [2 x
ptr] }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CodeGen][ObjC] Include all referenced protocols in protocol list (PR #148827)
https://github.com/hmelder updated
https://github.com/llvm/llvm-project/pull/148827
>From 3a4e7a8a31b90f933ef01385759bee8699efe94b Mon Sep 17 00:00:00 2001
From: hmelder
Date: Tue, 15 Jul 2025 13:09:28 +0200
Subject: [PATCH] [CodeGen][ObjC] Include all referenced protocols in protocol
list
When constructing the protocol list in the class metadata generation
(`GenerateClass`), only the protocols from the base class are added but
not from class extensions.
This is fixed by using `all_referenced_protocol_{begin, end}` instead of
`protocol_{begin, end}`, matching the behaviour on Apple platforms.
---
clang/lib/CodeGen/CGObjCGNU.cpp | 5 ++--
clang/test/CodeGenObjC/gnustep2-class-exts.m | 25
2 files changed, 28 insertions(+), 2 deletions(-)
create mode 100644 clang/test/CodeGenObjC/gnustep2-class-exts.m
diff --git a/clang/lib/CodeGen/CGObjCGNU.cpp b/clang/lib/CodeGen/CGObjCGNU.cpp
index d828702cbb87f..8acf8d2ddec02 100644
--- a/clang/lib/CodeGen/CGObjCGNU.cpp
+++ b/clang/lib/CodeGen/CGObjCGNU.cpp
@@ -1942,8 +1942,9 @@ class CGObjCGNUstep2 : public CGObjCGNUstep {
// struct objc_class *sibling_class
classFields.addNullPointer(PtrTy);
// struct objc_protocol_list *protocols;
-auto RuntimeProtocols = GetRuntimeProtocolList(classDecl->protocol_begin(),
- classDecl->protocol_end());
+auto RuntimeProtocols =
+GetRuntimeProtocolList(classDecl->all_referenced_protocol_begin(),
+ classDecl->all_referenced_protocol_end());
SmallVector Protocols;
for (const auto *I : RuntimeProtocols)
Protocols.push_back(GenerateProtocolRef(I));
diff --git a/clang/test/CodeGenObjC/gnustep2-class-exts.m
b/clang/test/CodeGenObjC/gnustep2-class-exts.m
new file mode 100644
index 0..b065490a7d8d8
--- /dev/null
+++ b/clang/test/CodeGenObjC/gnustep2-class-exts.m
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple aarch64-unknown-linux-gnu
-fobjc-runtime=gnustep-2.2 -emit-llvm -o - %s | FileCheck %s
+
+@protocol BaseProtocol
+@end
+
+@protocol ExtendedProtocol
+@end
+
+@interface TestClass
+
+-(void) Meth;
+@end
+
+@interface TestClass ()
+@end
+
+@implementation TestClass
+@end
+
+// Check that we emit metadata for both protocols
+// CHECK: @._OBJC_PROTOCOL_ExtendedProtocol = global
+// CHECK: @._OBJC_PROTOCOL_BaseProtocol = global
+
+// Check that we deduplicate the protocol list
+// CHECK: @.objc_protocol_list{{\.[0-9]*}} = internal global { ptr, i64, [2 x
ptr] }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Add IgnoreExtension to SortIncludes (PR #137840)
https://github.com/mydeveloperday approved this pull request. https://github.com/llvm/llvm-project/pull/137840 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Add option for -nolibc in Driver/ToolChains/Baremetal.cpp (PR #145700)
saturn691 wrote: @petrhosek ping https://github.com/llvm/llvm-project/pull/145700 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Remove code related to trigraphs (PR #148640)
https://github.com/mydeveloperday approved this pull request. https://github.com/llvm/llvm-project/pull/148640 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [clang-query] Allow for trailing comma in matchers (PR #148018)
AaronBallman wrote: It looks like precommit CI found a relevant failure: ``` TEST 'Clang Tools :: clang-query/trailing-comma.c' FAILED Exit Code: 1 Command Output (stdout): -- # shell parser error on RUN: at line 14: clang-query -c "$(echo "match functionDecl( hasName( \"foo\" , ) , )" | sed "s/ /\n/g")" C:\_work\llvm-project\llvm-project\clang-tools-extra\test\clang-query\trailing-comma.c | FileCheck --check-prefix=CHECK-OK C:\_work\llvm-project\llvm-project\clang-tools-extra\test\clang-query\trailing-comma.c -- ``` I think the use of `sed` is fine, Maybe it's tripping up on `$()` ? https://github.com/llvm/llvm-project/pull/148018 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR] Add VTableAddrPointOp (PR #148730)
https://github.com/xlauko edited https://github.com/llvm/llvm-project/pull/148730 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CIR] Add VTableAddrPointOp (PR #148730)
https://github.com/xlauko edited https://github.com/llvm/llvm-project/pull/148730 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [WIP] [clang][CodeGen] Fix metadata when vectorization is disabled by pragma (PR #135163)
https://github.com/kasuga-fj edited https://github.com/llvm/llvm-project/pull/135163 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LifetimeSafety] Make the dataflow analysis generic (PR #148222)
https://github.com/usx95 updated
https://github.com/llvm/llvm-project/pull/148222
>From 2bff132be9082f85835f22e73550447f7b880e13 Mon Sep 17 00:00:00 2001
From: Utkarsh Saxena
Date: Fri, 11 Jul 2025 11:11:47 +
Subject: [PATCH 1/3] [LifetimeSafety] Add expired loans analysis
---
clang/lib/Analysis/LifetimeSafety.cpp | 395 ++
.../Sema/warn-lifetime-safety-dataflow.cpp| 30 +-
2 files changed, 234 insertions(+), 191 deletions(-)
diff --git a/clang/lib/Analysis/LifetimeSafety.cpp
b/clang/lib/Analysis/LifetimeSafety.cpp
index bf67bea6c9933..0b4241cdf404c 100644
--- a/clang/lib/Analysis/LifetimeSafety.cpp
+++ b/clang/lib/Analysis/LifetimeSafety.cpp
@@ -496,7 +496,162 @@ class FactGenerator : public
ConstStmtVisitor {
};
// = //
-// The Dataflow Lattice
+// Generic Dataflow Analysis
+// = //
+/// A generic, policy-based driver for forward dataflow analyses. It combines
+/// the dataflow runner and the transferer logic into a single class hierarchy.
+///
+/// The derived class is expected to provide:
+/// - A `Lattice` type.
+/// - `const char *getAnalysisName() const`
+/// - `Lattice getInitialState();` The initial state at the function entry.
+/// - `Lattice join(Lattice, Lattice);` Merges states from multiple CFG paths.
+/// - `Lattice transfer(Lattice, const FactType&);` Defines how a single
+/// lifetime-relevant `Fact` transforms the lattice state. Only overloads
+/// for facts relevant to the analysis need to be implemented.
+///
+/// \tparam Derived The CRTP derived class that implements the specific
+/// analysis.
+/// \tparam LatticeType The dataflow lattice used by the analysis.
+/// TODO: Maybe use the dataflow framework! The framework might need changes
+/// to support the current comparison done at block-entry.
+template class DataflowAnalysis {
+public:
+ using Lattice = LatticeType;
+
+private:
+ const CFG &Cfg;
+ AnalysisDeclContext &AC;
+
+ llvm::DenseMap BlockEntryStates;
+ llvm::DenseMap BlockExitStates;
+
+protected:
+ FactManager &AllFacts;
+
+ explicit DataflowAnalysis(const CFG &C, AnalysisDeclContext &AC,
+FactManager &F)
+ : Cfg(C), AC(AC), AllFacts(F) {}
+
+public:
+ void run() {
+Derived &D = static_cast(*this);
+llvm::TimeTraceScope Time(D.getAnalysisName());
+
+ForwardDataflowWorklist Worklist(Cfg, AC);
+const CFGBlock *Entry = &Cfg.getEntry();
+BlockEntryStates[Entry] = D.getInitialState();
+Worklist.enqueueBlock(Entry);
+
+while (const CFGBlock *B = Worklist.dequeue()) {
+ Lattice EntryState = getEntryState(B);
+ Lattice ExitState = transferBlock(B, EntryState);
+ BlockExitStates[B] = ExitState;
+
+ for (const CFGBlock *Successor : B->succs()) {
+Lattice OldSuccEntryState = getEntryState(Successor);
+Lattice NewSuccEntryState = D.join(OldSuccEntryState, ExitState);
+
+// Enqueue the successor if its entry state has changed.
+if (OldSuccEntryState == D.getInitialState() ||
+NewSuccEntryState != OldSuccEntryState) {
+ BlockEntryStates[Successor] = NewSuccEntryState;
+ Worklist.enqueueBlock(Successor);
+}
+ }
+}
+ }
+
+ Lattice getEntryState(const CFGBlock *B) const {
+return BlockEntryStates.lookup(B);
+ }
+
+ Lattice getExitState(const CFGBlock *B) const {
+return BlockExitStates.lookup(B);
+ }
+
+ void dump() const {
+const Derived *D = static_cast(this);
+llvm::dbgs() << "==\n";
+llvm::dbgs() << " " << D->getAnalysisName() << " results:\n";
+llvm::dbgs() << "==\n";
+const CFGBlock &B = Cfg.getExit();
+getExitState(&B).dump(llvm::dbgs());
+ }
+
+private:
+ /// Computes the exit state of a block by applying all its facts sequentially
+ /// to a given entry state.
+ /// TODO: We might need to store intermediate states per-fact in the block
for
+ /// later analysis.
+ Lattice transferBlock(const CFGBlock *Block, Lattice EntryState) {
+Lattice BlockState = EntryState;
+for (const Fact *F : AllFacts.getFacts(Block)) {
+ BlockState = transferFact(BlockState, F);
+}
+return BlockState;
+ }
+
+ Lattice transferFact(Lattice In, const Fact *F) {
+Derived *d = static_cast(this);
+switch (F->getKind()) {
+case Fact::Kind::Issue:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::Expire:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::AssignOrigin:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::ReturnOfOrigin:
+ return d->transfer(In, *F->getAs());
+}
+llvm_unreachable("Unknown fact kind");
+ }
+
+public:
+ Lattice transfer(Lattice In, const IssueFact &) { return
[clang] [llvm] [RISCV] Implement Builtins for XAndesBFHCvt extension. (PR #148804)
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-backend-risc-v
@llvm/pr-subscribers-clang-codegen
Author: Jim Lin (tclin914)
Changes
XAndesBFHCvt provides two builtins functions for converting between float and
bf16. Users can use them to convert bf16 values loaded from memory to float,
perform arithmetic operations, then convert them back to bf16 and store them to
memory.
The load/store and move operations for bf16 will be handled in a later patch.
---
Full diff: https://github.com/llvm/llvm-project/pull/148804.diff
11 Files Affected:
- (modified) clang/include/clang/Basic/BuiltinsRISCV.td (+5)
- (added) clang/include/clang/Basic/BuiltinsRISCVXAndes.td (+27)
- (modified) clang/lib/CodeGen/TargetBuiltins/RISCV.cpp (+8)
- (modified) clang/lib/Headers/CMakeLists.txt (+1)
- (added) clang/lib/Headers/riscv_nds.h (+35)
- (added) clang/test/CodeGen/RISCV/riscv-xandesbfhcvt-c-api.c (+25)
- (added) clang/test/CodeGen/RISCV/riscv-xandesbfhcvt.c (+23)
- (modified) llvm/include/llvm/IR/IntrinsicsRISCVXAndes.td (+9)
- (modified) llvm/lib/Target/RISCV/RISCVISelLowering.cpp (+1-1)
- (modified) llvm/lib/Target/RISCV/RISCVInstrInfoXAndes.td (+7)
- (added) llvm/test/CodeGen/RISCV/xandesbfhcvt.ll (+27)
``diff
diff --git a/clang/include/clang/Basic/BuiltinsRISCV.td
b/clang/include/clang/Basic/BuiltinsRISCV.td
index b2cd5648e008f..5927eaf80d57a 100644
--- a/clang/include/clang/Basic/BuiltinsRISCV.td
+++ b/clang/include/clang/Basic/BuiltinsRISCV.td
@@ -157,3 +157,8 @@ def pause : RISCVBuiltin<"void()">;
// XCV extensions.
//===--===//
include "clang/Basic/BuiltinsRISCVXCV.td"
+
+//===--===//
+// XAndes extensions.
+//===--===//
+include "clang/Basic/BuiltinsRISCVXAndes.td"
diff --git a/clang/include/clang/Basic/BuiltinsRISCVXAndes.td
b/clang/include/clang/Basic/BuiltinsRISCVXAndes.td
new file mode 100644
index 0..ea9a7166bc6e8
--- /dev/null
+++ b/clang/include/clang/Basic/BuiltinsRISCVXAndes.td
@@ -0,0 +1,27 @@
+//==- BuiltinsRISCVXAndes.td - RISC-V Andes Builtin database -*- C++
-*-==//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the Andes-specific builtin function database. Users of
+// this file must define the BUILTIN macro to make use of this information.
+//
+//===--===//
+
+class RISCVXAndesBuiltin :
TargetBuiltin {
+ let Spellings = ["__builtin_riscv_nds_" # NAME];
+ let Prototype = prototype;
+ let Features = features;
+}
+
+let Attributes = [NoThrow, Const] in {
+//===--===//
+// XAndesBFHCvt extension.
+//===--===//
+
+def fcvt_s_bf16 : RISCVXAndesBuiltin<"float(__bf16)", "xandesbfhcvt">;
+def fcvt_bf16_s : RISCVXAndesBuiltin<"__bf16(float)", "xandesbfhcvt">;
+} // Attributes = [NoThrow, Const]
diff --git a/clang/lib/CodeGen/TargetBuiltins/RISCV.cpp
b/clang/lib/CodeGen/TargetBuiltins/RISCV.cpp
index 89e3f6f203df3..63092139af4fa 100644
--- a/clang/lib/CodeGen/TargetBuiltins/RISCV.cpp
+++ b/clang/lib/CodeGen/TargetBuiltins/RISCV.cpp
@@ -413,6 +413,14 @@ Value *CodeGenFunction::EmitRISCVBuiltinExpr(unsigned
BuiltinID,
ID = Intrinsic::riscv_cv_alu_subuRN;
break;
+ // XAndesBFHCvt
+ case RISCV::BI__builtin_riscv_nds_fcvt_s_bf16:
+ID = Intrinsic::riscv_nds_fcvt_s_bf16;
+break;
+ case RISCV::BI__builtin_riscv_nds_fcvt_bf16_s:
+ID = Intrinsic::riscv_nds_fcvt_bf16_s;
+break;
+
// Vector builtins are handled from here.
#include "clang/Basic/riscv_vector_builtin_cg.inc"
diff --git a/clang/lib/Headers/CMakeLists.txt b/clang/lib/Headers/CMakeLists.txt
index c96d209c1fc0c..76ac8409e568f 100644
--- a/clang/lib/Headers/CMakeLists.txt
+++ b/clang/lib/Headers/CMakeLists.txt
@@ -127,6 +127,7 @@ set(riscv_files
riscv_bitmanip.h
riscv_corev_alu.h
riscv_crypto.h
+ riscv_nds.h
riscv_ntlh.h
sifive_vector.h
andes_vector.h
diff --git a/clang/lib/Headers/riscv_nds.h b/clang/lib/Headers/riscv_nds.h
new file mode 100644
index 0..5ccef00e332ed
--- /dev/null
+++ b/clang/lib/Headers/riscv_nds.h
@@ -0,0 +1,35 @@
+/*=== riscv_nds.h - Andes intrinsics ---===
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+ *===
[clang] [LifetimeSafety] Make the dataflow analysis generic (PR #148222)
https://github.com/usx95 updated
https://github.com/llvm/llvm-project/pull/148222
>From 2bff132be9082f85835f22e73550447f7b880e13 Mon Sep 17 00:00:00 2001
From: Utkarsh Saxena
Date: Fri, 11 Jul 2025 11:11:47 +
Subject: [PATCH 1/2] [LifetimeSafety] Add expired loans analysis
---
clang/lib/Analysis/LifetimeSafety.cpp | 395 ++
.../Sema/warn-lifetime-safety-dataflow.cpp| 30 +-
2 files changed, 234 insertions(+), 191 deletions(-)
diff --git a/clang/lib/Analysis/LifetimeSafety.cpp
b/clang/lib/Analysis/LifetimeSafety.cpp
index bf67bea6c9933..0b4241cdf404c 100644
--- a/clang/lib/Analysis/LifetimeSafety.cpp
+++ b/clang/lib/Analysis/LifetimeSafety.cpp
@@ -496,7 +496,162 @@ class FactGenerator : public
ConstStmtVisitor {
};
// = //
-// The Dataflow Lattice
+// Generic Dataflow Analysis
+// = //
+/// A generic, policy-based driver for forward dataflow analyses. It combines
+/// the dataflow runner and the transferer logic into a single class hierarchy.
+///
+/// The derived class is expected to provide:
+/// - A `Lattice` type.
+/// - `const char *getAnalysisName() const`
+/// - `Lattice getInitialState();` The initial state at the function entry.
+/// - `Lattice join(Lattice, Lattice);` Merges states from multiple CFG paths.
+/// - `Lattice transfer(Lattice, const FactType&);` Defines how a single
+/// lifetime-relevant `Fact` transforms the lattice state. Only overloads
+/// for facts relevant to the analysis need to be implemented.
+///
+/// \tparam Derived The CRTP derived class that implements the specific
+/// analysis.
+/// \tparam LatticeType The dataflow lattice used by the analysis.
+/// TODO: Maybe use the dataflow framework! The framework might need changes
+/// to support the current comparison done at block-entry.
+template class DataflowAnalysis {
+public:
+ using Lattice = LatticeType;
+
+private:
+ const CFG &Cfg;
+ AnalysisDeclContext &AC;
+
+ llvm::DenseMap BlockEntryStates;
+ llvm::DenseMap BlockExitStates;
+
+protected:
+ FactManager &AllFacts;
+
+ explicit DataflowAnalysis(const CFG &C, AnalysisDeclContext &AC,
+FactManager &F)
+ : Cfg(C), AC(AC), AllFacts(F) {}
+
+public:
+ void run() {
+Derived &D = static_cast(*this);
+llvm::TimeTraceScope Time(D.getAnalysisName());
+
+ForwardDataflowWorklist Worklist(Cfg, AC);
+const CFGBlock *Entry = &Cfg.getEntry();
+BlockEntryStates[Entry] = D.getInitialState();
+Worklist.enqueueBlock(Entry);
+
+while (const CFGBlock *B = Worklist.dequeue()) {
+ Lattice EntryState = getEntryState(B);
+ Lattice ExitState = transferBlock(B, EntryState);
+ BlockExitStates[B] = ExitState;
+
+ for (const CFGBlock *Successor : B->succs()) {
+Lattice OldSuccEntryState = getEntryState(Successor);
+Lattice NewSuccEntryState = D.join(OldSuccEntryState, ExitState);
+
+// Enqueue the successor if its entry state has changed.
+if (OldSuccEntryState == D.getInitialState() ||
+NewSuccEntryState != OldSuccEntryState) {
+ BlockEntryStates[Successor] = NewSuccEntryState;
+ Worklist.enqueueBlock(Successor);
+}
+ }
+}
+ }
+
+ Lattice getEntryState(const CFGBlock *B) const {
+return BlockEntryStates.lookup(B);
+ }
+
+ Lattice getExitState(const CFGBlock *B) const {
+return BlockExitStates.lookup(B);
+ }
+
+ void dump() const {
+const Derived *D = static_cast(this);
+llvm::dbgs() << "==\n";
+llvm::dbgs() << " " << D->getAnalysisName() << " results:\n";
+llvm::dbgs() << "==\n";
+const CFGBlock &B = Cfg.getExit();
+getExitState(&B).dump(llvm::dbgs());
+ }
+
+private:
+ /// Computes the exit state of a block by applying all its facts sequentially
+ /// to a given entry state.
+ /// TODO: We might need to store intermediate states per-fact in the block
for
+ /// later analysis.
+ Lattice transferBlock(const CFGBlock *Block, Lattice EntryState) {
+Lattice BlockState = EntryState;
+for (const Fact *F : AllFacts.getFacts(Block)) {
+ BlockState = transferFact(BlockState, F);
+}
+return BlockState;
+ }
+
+ Lattice transferFact(Lattice In, const Fact *F) {
+Derived *d = static_cast(this);
+switch (F->getKind()) {
+case Fact::Kind::Issue:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::Expire:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::AssignOrigin:
+ return d->transfer(In, *F->getAs());
+case Fact::Kind::ReturnOfOrigin:
+ return d->transfer(In, *F->getAs());
+}
+llvm_unreachable("Unknown fact kind");
+ }
+
+public:
+ Lattice transfer(Lattice In, const IssueFact &) { return
[clang] [CIR] Add rotate operation (PR #148426)
@@ -2847,6 +2847,45 @@ def ByteSwapOp : CIR_BitOpBase<"byte_swap",
CIR_UIntOfWidths<[16, 32, 64]>> {
}];
}
+//===--===//
+// RotateOp
+//===--===//
+
+def RotateOp : CIR_Op<"rotate", [Pure, SameOperandsAndResultType]> {
xlauko wrote:
I believe the goal was to unify the assembly format and traits for all pure
unary operations of the form `T -> T` in a single place. However, the name
`BitOpBase` might misleadingly suggest that it specifically involves some
bit-level semantics.
Formally, such operations are endomorphisms. That said, it's unclear to me
whether names like `EndomorphismOpBase` or `EndoOpBase` are desirable or
intuitive enough for this purpose.
https://github.com/llvm/llvm-project/pull/148426
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 57d81c2 - [Clang] Remove explicit object from non member function. (#148807)
Author: Corentin Jabot
Date: 2025-07-15T13:34:32+02:00
New Revision: 57d81c23f4c8d3ad88210aab29f0809974e7d1ce
URL:
https://github.com/llvm/llvm-project/commit/57d81c23f4c8d3ad88210aab29f0809974e7d1ce
DIFF:
https://github.com/llvm/llvm-project/commit/57d81c23f4c8d3ad88210aab29f0809974e7d1ce.diff
LOG: [Clang] Remove explicit object from non member function. (#148807)
To avoid crashing later (as we assume only member functions can have
explicit object parameters)
Fixes #113185
Added:
Modified:
clang/docs/ReleaseNotes.rst
clang/lib/Sema/SemaType.cpp
clang/test/SemaCXX/cxx2b-deducing-this.cpp
Removed:
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index e8c85483e9864..40213cd103c43 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -953,6 +953,7 @@ Bug Fixes to C++ Support
- Fix a bug where private access specifier of overloaded function not
respected. (#GH107629)
- Correctly handles calling an explicit object member function template
overload set
through its address (``(&Foo::bar)()``).
+- Fix a crash when using an explicit object parameter in a non-member
function. (#GH113185)
- Fix a crash when forming an invalid call to an operator with an explicit
object member. (#GH147121)
- Correctly handle allocations in the condition of a ``if
constexpr``.(#GH120197) (#GH134820)
- Fixed a crash when handling invalid member using-declaration in C++20+ mode.
(#GH63254)
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 661746731fdcc..bb114aff2366b 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -4860,7 +4860,9 @@ static TypeSourceInfo
*GetFullTypeForDeclarator(TypeProcessingState &state,
S.Diag(First->getBeginLoc(),
diag::err_explicit_object_parameter_invalid)
<< First->getSourceRange();
-
+ // Do let non-member function have explicit parameters
+ // to not break assumptions elsewhere in the code.
+ First->setExplicitObjectParameterLoc(SourceLocation());
D.setInvalidType();
AreDeclaratorChunksValid = false;
}
diff --git a/clang/test/SemaCXX/cxx2b-deducing-this.cpp
b/clang/test/SemaCXX/cxx2b-deducing-this.cpp
index 6987d0c020457..2253cbb26285e 100644
--- a/clang/test/SemaCXX/cxx2b-deducing-this.cpp
+++ b/clang/test/SemaCXX/cxx2b-deducing-this.cpp
@@ -1347,3 +1347,13 @@ int main() {
// expected-note@#S3-f-cand2 {{candidate function not viable: no known
conversion from 'S3' to 'int' for object argument}}
}
}
+
+namespace GH113185 {
+
+void Bar(this int) { // expected-note {{candidate function}}
+// expected-error@-1 {{an explicit object parameter cannot appear in a
non-member function}}
+Bar(0);
+Bar(); // expected-error {{no matching function for call to 'Bar'}}
+}
+
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Remove explicit object from non member function. (PR #148807)
https://github.com/cor3ntin closed https://github.com/llvm/llvm-project/pull/148807 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] 8a7a648 - [libclc] Move CMake for prepare_builtins to a subdirectory (#148815)
Author: Fraser Cormack
Date: 2025-07-15T12:26:11+01:00
New Revision: 8a7a64873b13e6fd931b748fbf50b3da26fe7fca
URL:
https://github.com/llvm/llvm-project/commit/8a7a64873b13e6fd931b748fbf50b3da26fe7fca
DIFF:
https://github.com/llvm/llvm-project/commit/8a7a64873b13e6fd931b748fbf50b3da26fe7fca.diff
LOG: [libclc] Move CMake for prepare_builtins to a subdirectory (#148815)
This simply makes things better self-contained.
Added:
libclc/utils/CMakeLists.txt
Modified:
libclc/CMakeLists.txt
Removed:
diff --git a/libclc/CMakeLists.txt b/libclc/CMakeLists.txt
index e2871d1b01a16..2570d1a106d21 100644
--- a/libclc/CMakeLists.txt
+++ b/libclc/CMakeLists.txt
@@ -164,34 +164,14 @@ endif()
list( SORT LIBCLC_TARGETS_TO_BUILD )
-# Construct LLVM version define
-set( LLVM_VERSION_DEFINE
"-DHAVE_LLVM=0x${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}" )
-
# This needs to be set before any target that needs it
# We need to use LLVM_INCLUDE_DIRS here, because if we are linking to an
# llvm build directory, this includes $src/llvm/include which is where all the
# headers are not $build/include/ which is what LLVM_INCLUDE_DIR is set to.
include_directories( ${LLVM_INCLUDE_DIRS} )
-# Setup prepare_builtins tools
-set(LLVM_LINK_COMPONENTS
- BitReader
- BitWriter
- Core
- IRReader
- Support
-)
-if( LIBCLC_STANDALONE_BUILD )
- add_llvm_executable( prepare_builtins utils/prepare-builtins.cpp )
- set( prepare_builtins_exe prepare_builtins )
- set( prepare_builtins_target prepare_builtins )
-else()
- add_llvm_utility( prepare_builtins utils/prepare-builtins.cpp )
- setup_host_tool( prepare_builtins PREPARE_BUILTINS prepare_builtins_exe
prepare_builtins_target )
-endif()
-target_compile_definitions( prepare_builtins PRIVATE ${LLVM_VERSION_DEFINE} )
-# These were not properly reported in early LLVM and we don't need them
-target_compile_options( prepare_builtins PRIVATE -fno-rtti -fno-exceptions )
+# Configure prepare_builtins
+add_subdirectory( utils )
# Setup arch devices
set( r600--_devices cedar cypress barts cayman )
diff --git a/libclc/utils/CMakeLists.txt b/libclc/utils/CMakeLists.txt
new file mode 100644
index 0..ea1d9e9c8ef5f
--- /dev/null
+++ b/libclc/utils/CMakeLists.txt
@@ -0,0 +1,24 @@
+# Construct LLVM version define
+set( LLVM_VERSION_DEFINE
"-DHAVE_LLVM=0x${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}" )
+
+# Setup prepare_builtins tools
+set( LLVM_LINK_COMPONENTS
+ BitReader
+ BitWriter
+ Core
+ IRReader
+ Support
+)
+
+if( LIBCLC_STANDALONE_BUILD )
+ add_llvm_executable( prepare_builtins prepare-builtins.cpp )
+ set( prepare_builtins_exe prepare_builtins )
+ set( prepare_builtins_target prepare_builtins )
+else()
+ add_llvm_utility( prepare_builtins prepare-builtins.cpp )
+ setup_host_tool( prepare_builtins PREPARE_BUILTINS prepare_builtins_exe
prepare_builtins_target )
+endif()
+
+target_compile_definitions( prepare_builtins PRIVATE ${LLVM_VERSION_DEFINE} )
+# These were not properly reported in early LLVM and we don't need them
+target_compile_options( prepare_builtins PRIVATE -fno-rtti -fno-exceptions )
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move CMake for prepare_builtins to a subdirectory (PR #148815)
https://github.com/frasercrmck closed https://github.com/llvm/llvm-project/pull/148815 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Remove explicit object from non member function. (PR #148807)
https://github.com/cor3ntin created
https://github.com/llvm/llvm-project/pull/148807
To avoid crashing later (as we assume only member functions can have explicit
parameters)
Fixes #113185
>From bf204f023a4f84732c5876ff86e7de603fd95aac Mon Sep 17 00:00:00 2001
From: Corentin Jabot
Date: Tue, 15 Jul 2025 11:06:03 +0200
Subject: [PATCH] [Clang] Remove explicit object from non member function.
To avoid crashing later (as we assume only member functions
can have explicit parameters)
Fixes #113185
---
clang/lib/Sema/SemaType.cpp| 4 +++-
clang/test/SemaCXX/cxx2b-deducing-this.cpp | 10 ++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 661746731fdcc..bb114aff2366b 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -4860,7 +4860,9 @@ static TypeSourceInfo
*GetFullTypeForDeclarator(TypeProcessingState &state,
S.Diag(First->getBeginLoc(),
diag::err_explicit_object_parameter_invalid)
<< First->getSourceRange();
-
+ // Do let non-member function have explicit parameters
+ // to not break assumptions elsewhere in the code.
+ First->setExplicitObjectParameterLoc(SourceLocation());
D.setInvalidType();
AreDeclaratorChunksValid = false;
}
diff --git a/clang/test/SemaCXX/cxx2b-deducing-this.cpp
b/clang/test/SemaCXX/cxx2b-deducing-this.cpp
index 6987d0c020457..2253cbb26285e 100644
--- a/clang/test/SemaCXX/cxx2b-deducing-this.cpp
+++ b/clang/test/SemaCXX/cxx2b-deducing-this.cpp
@@ -1347,3 +1347,13 @@ int main() {
// expected-note@#S3-f-cand2 {{candidate function not viable: no known
conversion from 'S3' to 'int' for object argument}}
}
}
+
+namespace GH113185 {
+
+void Bar(this int) { // expected-note {{candidate function}}
+// expected-error@-1 {{an explicit object parameter cannot appear in a
non-member function}}
+Bar(0);
+Bar(); // expected-error {{no matching function for call to 'Bar'}}
+}
+
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Remove explicit object from non member function. (PR #148807)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Corentin Jabot (cor3ntin)
Changes
To avoid crashing later (as we assume only member functions can have explicit
parameters)
Fixes #113185
---
Full diff: https://github.com/llvm/llvm-project/pull/148807.diff
2 Files Affected:
- (modified) clang/lib/Sema/SemaType.cpp (+3-1)
- (modified) clang/test/SemaCXX/cxx2b-deducing-this.cpp (+10)
``diff
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 661746731fdcc..bb114aff2366b 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -4860,7 +4860,9 @@ static TypeSourceInfo
*GetFullTypeForDeclarator(TypeProcessingState &state,
S.Diag(First->getBeginLoc(),
diag::err_explicit_object_parameter_invalid)
<< First->getSourceRange();
-
+ // Do let non-member function have explicit parameters
+ // to not break assumptions elsewhere in the code.
+ First->setExplicitObjectParameterLoc(SourceLocation());
D.setInvalidType();
AreDeclaratorChunksValid = false;
}
diff --git a/clang/test/SemaCXX/cxx2b-deducing-this.cpp
b/clang/test/SemaCXX/cxx2b-deducing-this.cpp
index 6987d0c020457..2253cbb26285e 100644
--- a/clang/test/SemaCXX/cxx2b-deducing-this.cpp
+++ b/clang/test/SemaCXX/cxx2b-deducing-this.cpp
@@ -1347,3 +1347,13 @@ int main() {
// expected-note@#S3-f-cand2 {{candidate function not viable: no known
conversion from 'S3' to 'int' for object argument}}
}
}
+
+namespace GH113185 {
+
+void Bar(this int) { // expected-note {{candidate function}}
+// expected-error@-1 {{an explicit object parameter cannot appear in a
non-member function}}
+Bar(0);
+Bar(); // expected-error {{no matching function for call to 'Bar'}}
+}
+
+}
``
https://github.com/llvm/llvm-project/pull/148807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 8aeab8f - [Driver][MinGW] Allow using clang driver to link ARM64X PEs. (#148064)
Author: WhatAmISupposedToPutHere
Date: 2025-07-15T12:01:36+03:00
New Revision: 8aeab8faeebfa737a388041e5b37717ab15d387e
URL:
https://github.com/llvm/llvm-project/commit/8aeab8faeebfa737a388041e5b37717ab15d387e
DIFF:
https://github.com/llvm/llvm-project/commit/8aeab8faeebfa737a388041e5b37717ab15d387e.diff
LOG: [Driver][MinGW] Allow using clang driver to link ARM64X PEs. (#148064)
Similar to how clang-cl driver does it, make it possible to build arm64x
binaries with a mingw-style invocation.
Signed-off-by: Sasha Finkelstein
Added:
Modified:
clang/lib/Driver/ToolChains/MinGW.cpp
clang/test/Driver/mingw.cpp
Removed:
diff --git a/clang/lib/Driver/ToolChains/MinGW.cpp
b/clang/lib/Driver/ToolChains/MinGW.cpp
index 7d093d20b3dd9..b2e36ae6f97c3 100644
--- a/clang/lib/Driver/ToolChains/MinGW.cpp
+++ b/clang/lib/Driver/ToolChains/MinGW.cpp
@@ -132,7 +132,9 @@ void tools::MinGW::Linker::ConstructJob(Compilation &C,
const JobAction &JA,
CmdArgs.push_back("thumb2pe");
break;
case llvm::Triple::aarch64:
-if (TC.getEffectiveTriple().isWindowsArm64EC())
+if (Args.hasArg(options::OPT_marm64x))
+ CmdArgs.push_back("arm64xpe");
+else if (TC.getEffectiveTriple().isWindowsArm64EC())
CmdArgs.push_back("arm64ecpe");
else
CmdArgs.push_back("arm64pe");
diff --git a/clang/test/Driver/mingw.cpp b/clang/test/Driver/mingw.cpp
index 66da0c97f4166..f43fa177e2905 100644
--- a/clang/test/Driver/mingw.cpp
+++ b/clang/test/Driver/mingw.cpp
@@ -85,6 +85,10 @@
// RUN: | FileCheck %s --check-prefix CHECK_MINGW_EC_LINK
// CHECK_MINGW_EC_LINK: "-m" "arm64ecpe"
+// RUN: %clang --target=aarch64-windows-gnu -marm64x -### -o /dev/null %s 2>&1
\
+// RUN: | FileCheck %s --check-prefix CHECK_MINGW_A64X_LINK
+// CHECK_MINGW_A64X_LINK: "-m" "arm64xpe"
+
// RUN: %clang --target=mipsel-windows-gnu -### -o /dev/null %s 2>&1 \
// RUN: | FileCheck %s --check-prefix CHECK_MINGW_MIPSPE
// CHECK_MINGW_MIPSPE: "-m" "mipspe"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
