On Thu, Dec 07, 2023 at 03:16:29PM +0000, Costas Argyris wrote:
> > 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.
In the invoke_embedded_driver JIT case yes, that calls driver::finalize (),
which is why it should be freed before clearing the pointer in there (as
then it is a real leak).
> 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.
That is wasted compile time on a non-issue.
If you see a JIT issue with definitely lost records, that is something
that obviously should be fixed (but even in that area I think we've been a
little bit lazy in the option handling).
The most important is that the actual compiler binaries (cc1, cc1plus, ...)
don't leak memory (in the definitely lost kind) like crazy, we have
--enable-checking=valgrind
for that purpose, where the driver runs cc1/cc1plus etc. under valgrind,
but this is very expensive and slow, so usually it is run once during a
cycle (if at all), on a fast machine could take even in non-bootstrap mode
a weekend to go through the whole testsuite, then one can look at the leaks.
Jakub
