Re: VN_INFO might be NULL in PRE

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Oct 23, 2012 at 7:36 AM, Zhenqiang Chen
<zhenqiang.chen@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)

Richard.

> Thanks!
> -Zhenqiang