[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