[clang] [clang][bytecode][NFC] Add a FIXME comment for heap allocations (PR #151700)

Timm Baeder via cfe-commits cfe-commits at lists.llvm.org
Fri Aug 1 06:56:46 PDT 2025


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

None

>From 3437a6fe88bb88ac1c46d8454fbc44a5df5b4c3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Timm=20B=C3=A4der?= <tbaeder at redhat.com>
Date: Fri, 1 Aug 2025 15:54:58 +0200
Subject: [PATCH] [clang][bytecode][NFC] Add a FIXME comment for heap
 allocations

---
 clang/lib/AST/ByteCode/DynamicAllocator.cpp | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/clang/lib/AST/ByteCode/DynamicAllocator.cpp b/clang/lib/AST/ByteCode/DynamicAllocator.cpp
index 169250ce05fa7..9b8b664df6afd 100644
--- a/clang/lib/AST/ByteCode/DynamicAllocator.cpp
+++ b/clang/lib/AST/ByteCode/DynamicAllocator.cpp
@@ -13,6 +13,25 @@
 using namespace clang;
 using namespace clang::interp;
 
+// FIXME: There is a peculiar problem with the way we track pointers
+// to blocks and the way we allocate dynamic memory.
+//
+// When we have code like this:
+// while (true) {
+//   char *buffer = new char[1024];
+//   delete[] buffer;
+// }
+//
+// We have a local variable 'buffer' pointing to the heap allocated memory.
+// When deallocating the memory via delete[], that local variable still
+// points to the memory, which means we will create a DeadBlock for it and move
+// it over to that block, essentially duplicating the allocation. Moving
+// the data is also slow.
+//
+// However, when we actually try to access the allocation after it has been
+// freed, we need the block to still exist (alive or dead) so we can tell
+// that it's a dynamic allocation.
+
 DynamicAllocator::~DynamicAllocator() { cleanup(); }
 
 void DynamicAllocator::cleanup() {



More information about the cfe-commits mailing list