On Fri, Dec 08, 2023 at 12:18:50PM +, Costas Argyris wrote:
> Does the simple XDELETEVEC patch need any more work?
Well, it needs to be actually tested and posted and committed.
I can take care of it in my next bootstraps.
Jakub
Does the simple XDELETEVEC patch need any more work?
I think it just fixes a leak for the JIT case where driver::finalize is
called.
On Thu, 7 Dec 2023 at 16:04, Jakub Jelinek wrote:
> On Thu, Dec 07, 2023 at 04:01:11PM +, Costas Argyris wrote:
> > Thanks for all the explanations.
> >
> > I
On Thu, Dec 07, 2023 at 04:01:11PM +, Costas Argyris wrote:
> Thanks for all the explanations.
>
> In that case I restrict this patch to just freeing the buffer from
> within driver::finalize only (I think it should be XDELETEVEC
> instead of XDELETE, no?).
Both macros are exactly the same, b
Thanks for all the explanations.
In that case I restrict this patch to just freeing the buffer from
within driver::finalize only (I think it should be XDELETEVEC
instead of XDELETE, no?).
On Thu, 7 Dec 2023 at 15:42, Jakub Jelinek wrote:
> On Thu, Dec 07, 2023 at 03:16:29PM +, Costas Argyri
On Thu, Dec 07, 2023 at 03:16:29PM +, 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
> 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 valg
On Thu, Dec 07, 2023 at 02:28:18PM +, 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 ()
Would that be something like this?
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 beca
On Wed, Dec 06, 2023 at 02:29:25PM +, Costas Argyris wrote:
> Attached a new patch with these changes.
>
> On Mon, 4 Dec 2023 at 12:15, Jonathan Wakely wrote:
>
> > On Sat, 2 Dec 2023 at 21:24, Costas Argyris wrote:
> > >
> > > Use std::vector instead of malloc'd pointer
> > > to get automat
Attached a new patch with these changes.
On Mon, 4 Dec 2023 at 12:15, Jonathan Wakely wrote:
> On Sat, 2 Dec 2023 at 21:24, Costas Argyris wrote:
> >
> > Use std::vector instead of malloc'd pointer
> > to get automatic freeing of memory.
>
> You can't include there. Instead you need to define
>
On Sat, 2 Dec 2023 at 21:24, Costas Argyris wrote:
>
> Use std::vector instead of malloc'd pointer
> to get automatic freeing of memory.
You can't include there. Instead you need to define
INCLUDE_VECTOR before "system.h"
Shouldn't you be using resize, not reserve? Otherwise mdswitches[i] is
und
Use std::vector instead of malloc'd pointer
to get automatic freeing of memory.
Result was verified by valgrind, which showed
one less loss record.
I think Jonathan is/was working on this transition
but on a larger scale.
0001-driver-Fix-memory-leak.patch
Description: Binary data
12 matches
Mail list logo
