On 05.03.2011 15:37, Richard Sandiford wrote: > Jakub Jelinek <ja...@redhat.com> writes: >> On Fri, Mar 04, 2011 at 01:56:55PM +0000, Richard Sandiford wrote: >>> * dwarf2out.c (dw_loc_list_node): Add resolved_addr and replaced. >>> (cached_dw_loc_list_def): New structure. >>> (cached_dw_loc_list): New typedef. >>> (cached_dw_loc_list_table): New variable. >>> (cached_dw_loc_list_table_hash): New function. >>> (cached_dw_loc_list_table_eq): Likewise. >>> (add_location_or_const_value_attribute): Take a bool cache_p. >>> Cache the list when the parameter is true. >>> (gen_formal_parameter_die): Update caller. >>> (gen_variable_die): Likewise. >>> (dwarf2out_finish): Likewise. >>> (dwarf2out_function_decl): Clear cached_dw_loc_list_table. >>> (dwarf2out_init): Initialize cached_dw_loc_list_table. >>> (resolve_addr): Cache the result of resolving a chain of >>> location lists. >> >> I think you should handle the cached_dw_loc_list_table in >> dwarf2out_abstract_function similarly to say decl_loc_table, i.e. >> save/clear for the duration of the of recursive dwarf2out_decl >> call, restore afterwards and in the places where you actually use >> it guard it also with cached_dw_loc_list_table != NULL. > > OK, thanks for the pointer. How does this look? Bootstrapped > & regression-tested on x86_64-linux-gnu.
tested with 4.6.0 on x86, x86_64 and arm-linux-genueabi without seeing regressions. Matthias
