>  Still reachable memory at exit e.g. from valgrind is not a bug.

Indeed, this is coming from a valgrind report here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019

where it was noted that the driver memory leaks could be
problematic for JIT.

So, since using std::vector did reduce the valgrind records
by one (I only targeted a single variable to begin with) I took
that as a good sign.

Regarding adding a call to XDELETE (mdswitches), yes,
that would help in the case where driver::finalize () is actually
called, which I think is for JIT.    I was trying to take care of the
case where it doesn't get called as well, but from what you say
I take it that this case is not of interest.

On Thu, 7 Dec 2023 at 14:42, Jakub Jelinek <jakub@redhat.com> wrote:

> 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
>
>