This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/66339] g++ 5.1.0 Generates memory leak
- From: "trippels at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 11 Jan 2016 14:57:59 +0000
- Subject: [Bug c++/66339] g++ 5.1.0 Generates memory leak
- Auto-submitted: auto-generated
- References: <bug-66339-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |trippels at gcc dot gnu.org
--- Comment #5 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to lh_mouse from comment #4)
> (In reply to Jonathan Wakely from comment #3)
> > OK, whatever weird definition of leak you are using is irrelevant. The
> > memory is still in use until the program exits, and there is still a pointer
> > to it. It is not lost, or forgotten about, it is in use by the run-time.
>
> That is an ostrich strategy.
>
> The runtime is amenable for deallocation of the pool because it is the
> runtime that has allocated the pool. The runtime shall free it, by
> definition, when it is no longer 'in use by the run-time', but not never.
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
for further motivation.