On Thu, Dec 07, 2023 at 02:28:18PM +0000, Costas Argyris wrote:
> Would that be something like this?
Yes. Or perhaps even easier just change
--- gcc/gcc.cc.jj 2023-12-07 08:31:59.970849379 +0100
+++ gcc/gcc.cc 2023-12-07 15:33:46.616886894 +0100
@@ -11368,6 +11368,7 @@ driver::finalize ()
input_from_pipe = 0;
suffix_subst = NULL;
+ XDELETE (mdswitches);
mdswitches = NULL;
n_mdswitches = 0;
> Although it didn't fix the leak, which was the entire point of this
> exercise.
>
> Maybe because driver::finalize () is not getting called so the call to
> mdswitches.release () doesn't really happen, which was the reason
> I went with std::vector in the first place because it takes care of itself.
In that case you are fixing a non-issue.
exit frees all allocated memory, no need to do it explicitly and waste
compile time cycles on it.
Leak is when some memory is allocated and pointer to it lost, that is not
the case here.
Still reachable memory at exit e.g. from valgrind is not a bug.
E.g. glibc in order to make fewer still reachable memory reports exports
a __libc_freeres function which valgrind and other memory allocation
debuggers can call on exit to free extra memory, something that isn't really
needed to waste time on normally. But I'm not sure if there is some way
for an application to provide such functions as well.
Jakub
