PING: Re: [PATCH 18/21] PR jit/63854: Add "long-term" allocator to gcc::context

David Malcolm dmalcolm@redhat.com
Fri Jan 16 16:46:00 GMT 2015


On Wed, 2014-11-19 at 17:36 +0000, Joseph Myers wrote:
> On Wed, 19 Nov 2014, David Malcolm wrote:
> 
> > There's no clean way to release them: retrofitting logic to decide if
> > we're dealing with a string literal vs a dynamically-allocated buffer
> > (and if something else is pointing to said buffer) is messy and
> > error-prone; they are also unconnected to the GC.
> 
> This is not an objection to your patch, but the obvious approach would 
> seem to me to be to ensure that anything that might be allocated or might 
> be a string constant (or maybe a string from argv in some cases?) is 
> always allocated - use xstrdup rather than putting a string constant there 
> directly.  Once such pointers are always allocated, they can safely be 
> freed.

Maybe, though this approach avoids having to retrofit xstrdup calls into
all these places in favor of allowing you to freely mingle string
constants with allocated memory, and it's only relevant for the jit - so
I was assuming that my approach would be preferable.  Though I guess
it's an extra cognitive load on maintainers: a new kind of allocation

Is the patch acceptable in stage3 (assuming it still
applies/bootstraps/etc)?
  https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02420.html

It fixes some leaks in jit (that don't affect cc1 etc al) and makes
valgrind of "make check-jit" closer to being clean.




More information about the Gcc-patches mailing list