https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
--- Comment #13 from Richard Biener ---
Note the pool was made dynamic (and effectively larger) exactly for a QOI
issue...
[the dynamic nature is to make its size controllable by the environment, sth
that didn't materialize yet]
The difficulty w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
--- Comment #12 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #10)
> This behaviour is by design and is not a bug. Valgrind no longer shows the
> allocation as reachable. Other tools might still show the memory as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
--- Comment #11 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #9)
> Following your narrow definition of "leak", it implies that any system using
> GC could never leak. That's absurd.
Wikipedia: "a memory leak is a type of resour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
--- Comment #10 from Jonathan Wakely ---
This behaviour is by design and is not a bug. Valgrind no longer shows the
allocation as reachable. Other tools might still show the memory as unfreed,
but it's still not a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
--- Comment #9 from frankhb1989 at gmail dot com ---
(In reply to Andrew Pinski from comment #8)
> (In reply to frankhb1989 from comment #7)
> > This is definitely a leak from the view of libc. Why is the status INVALID
> > instead of WONTFIX?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
--- Comment #8 from Andrew Pinski ---
(In reply to frankhb1989 from comment #7)
> This is definitely a leak from the view of libc. Why is the status INVALID
> instead of WONTFIX?
It is still reachable. Since it is reachable, a pointer at decons
