On Tue, Apr 17, 2018, 10:25 AM Alexandre Oliva <aol...@redhat.com> wrote:
> On Apr 17, 2018, Jason Merrill <ja...@redhat.com> wrote: > > > I was thinking maybe_get_node > > 'k > > > I suppose better would be for > > > + if (obj->list_p () && obj->get_decl_maybe ()) > > + tree_list_freelist ().free (obj->get_node ()); > > > to be e.g. > > > obj-> maybe_free_list(); > > Any objections to making dec_refcount_use a friend of tinst_level's? > Otherwise, I'd rather add a free() member function (or maybe static > member function) to free both the TREE_LIST and the tinst_level objects. > Either of those sounds fine. Otherwise, maybe_free_list would leave the object in an inconsistent > state, pointing to a freed TREE_LIST, or it could undo to_list, though > it's not supposed to be reversible in the lifetime of the object. > free()ing the entire object along with the TREE_LIST addresses that > concern. But then, dec_refcount_use does that and then some... > > > Or put the list handling in a destructor for tinst_level, and have > > freelist use placement new and explicit destruction. > > A destructor would enable finalization in GGC, I don't think we want to > do that. > > -- > Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ > You must be the change you wish to see in the world. -- Gandhi > Be Free! -- http://FSFLA.org/ FSF Latin America board member > Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer >
