The reason I put that patch out is that sometimes, when we stream an actual chain, lto_input_chain is going to rebuild the new chain it's meant to be, but then pph_read_tree (which is called after by the name_hook to finish reading special parts of the tree) overwrites the DECL_CHAIN that was introduced by lto_input_chain.
The only time we need to actually stream in/out the DECL_CHAIN is when streaming unions/structs because from what I looked at in lto it looks like we are not doing lto_output_chain, but lto_output_tree on the first member of the fields' chain (not sure how that even works in lto... but in pph we used to only get the first member of structs streamed and streaming DECL_CHAIN was the fix for it...) I introduced this fix because it broke my patch trying to stream out the chains backwards (as it would overwrite the chain I was trying to create backwards on input, I think this didn't show up before because the chain being built on input was the same as the one existing on output (thus overwriting with the same value...) ) Even if this doesn't break tests anymore, we probably still want this, no point adding stuff to the pph image that is not needed... Any idea why lto doesn't call lto_output_chain, but simply lto_output_tree to output the chains for struct/union? Gab On Tue, Jul 12, 2011 at 12:21 PM, Diego Novillo <dnovi...@google.com> wrote: > On Fri, Jul 8, 2011 at 21:20, Gabriel Charette <gch...@google.com> wrote: > >> 2011-07-08 Gabriel Charette <gch...@google.com> >> >> * pph-streamer-in.c (pph_in_function_decl): Stream in >> DECL_CHAIN of FUNCTION_DECL only if it's part of a >> RECORD_OR_UNION_TYPE >> (pph_read_tree): Stream in DECL_CHAIN of VAR_DECL only if it's part >> of a RECORD_OR_UNION_TYPE. >> * pph-streamer-out.c (pph_out_function_decl): Stream out >> DECL_CHAIN of FUNCTION_DECL only if it's part of a >> RECORD_OR_UNION_TYPE >> (pph_write_tree): Stream out DECL_CHAIN of VAR_DECL only if it's part >> of a RECORD_OR_UNION_TYPE. > > Gab, do you still need this patch? In principle, it doesn't make a > lot of sense to restrict when we save the DECL_CHAIN in this way. > It's not obvious what this would fix or help with. > > > Diego. >
