On 23 October 2012 18:02, Richard Biener <richard.guent...@gmail.com> wrote: > On Tue, Oct 23, 2012 at 7:36 AM, Zhenqiang Chen > <zhenqiang.c...@linaro.org> wrote: >> Hi, >> >> PRE bases on the result of value numbering (run_scc_vn). At the end, >> it free_scc_vn. But before free_scc_vn, it might call cleanup_tree_cfg >> (); >> >> if (do_eh_cleanup || do_ab_cleanup) >> cleanup_tree_cfg (); >> >> cleanup_tree_cfg might call make_ssa_name which might reuse some >> "name" from the FREE_SSANAMES list. If the VN_INFO of the "name" is >> NULL, free_scc_vn will "Segmentation fault". PR 54902 >> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54902) shows a real case. >> The attached log shows the gdb backtrace to create a new ssa name. >> >> Here is function VN_INFO: >> >> vn_ssa_aux_t >> VN_INFO (tree name) >> { >> vn_ssa_aux_t res = VEC_index (vn_ssa_aux_t, vn_ssa_aux_table, >> SSA_NAME_VERSION (name)); >> gcc_checking_assert (res); >> return res; >> } >> >> Can we make sure "res" is not NULL for the new ssa name? >> >> In trunk, Richard's "Make gsi_remove return whether EH cleanup is >> required" patches in r186159 and r186164 make "do_eh_cleanup" to >> false. So cleanup_tree_cfg is not called in PRE. Then no new ssa name >> will be created. >> >> Does the Richard's patch fix the root cause? > > I don't think so. Where does cfgcleanup call make_ssa_name? The solution > would be to post-pone cleaning up the CFG until after free_ssc_vn. To > be able to compute dominators we only have to remove unreachable blocks > (delete_unreachable_blocks)
The attachment (bt.log) in previous mail shows the trace to call make_ssa_name. PR 54902 includes a test case to reproduce it. The bt.log bases on 4.7. I have no case to reproduce it for trunk. But cleanup_tree_cfg is still called before free_ssc_vn. Thanks! -Zhenqiang
