On Thu, Nov 13, 2014 at 05:52:51PM -0700, Jeff Law wrote: > On 11/12/14 22:55, tsaund...@mozilla.com wrote: > >From: Trevor Saunders <tsaund...@mozilla.com> > > > >Hi, > > > >gengtype fails to create valid user marking functions for this type, which is > >fixed by using vec here (which seems cleaner anyway). > > > >bootstrapped + regtested powerpc64-linux (gcc 110 since gcc20 died) ok? > > > >Trev > > > > > >gcc/ChangeLog: > > > >2014-11-13 Trevor Saunders <tsaund...@mozilla.com> > > > > * lto-section-in.c (lto_delete_in_decl_state): Adjust. > > (lto_free_function_in_decl_state): Likewise. > > * lto-streamer-out.c (copy_function_or_variable): Likewise. > > * lto-streamer.h (lto_file_decl_data_get_ ## name): Likewise. > > (lto_file_decl_data_num_ ## name ## s): Likewise. > > (struct lto_tree_ref_table): Remove. > > (struct lto_in_decl_state): Replace lto_tree_ref_table with vec<tree>. > > > >gcc/lto/ChangeLog: > > > >2014-11-13 Trevor Saunders <tsaund...@mozilla.com> > > > > * lto.c (lto_read_in_decl_state): Adjust. > > (lto_fixup_state): Likewise. > What is it about the data structure that's causing GGC grief? Are there
A couple things come together here 1 user pch routines don't have separate this_obj and x_p arguments, they expect they only need to mark one object. 2 gengtype does the marking for the lto_tree_ref_table within the routine for lto_in_decl_state. This means it needs to check if this_obj is the same as x_p. the combination results in a user pch marking routine trying to check if this_obj == x_p when there is no this_obj argument. > other data structures with similar enough characteristics that we need to > fix them? Is there any way to warn/error for this case? I think its roughly when an object or a subobject there of has a pointer to an array of pointers. I'm not sure how to find all the effected types other than by adding for_user everywhere and seeing what breaks, but that could expose other problems and I think will happen soon enough anyway. we could make gengtype handle this better urrently it just emits invalid C++. I 'd like to make gengtype always use user style marking routines and remove the custom mangling, which I suspect will require either fixing all the types with problems like this or making gengtype emit correct code for them. > I'm OK with the change, but it feels like there needs to be some research > into other potential lossage and some preventative work to prevent similar > problems in the future. yeah, this is kind of a cheap way of dealing with the problem, on the other hand I tend to think its a decent clean up on its own. Trev > > Thanks, > Jeff
