This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: VN_INFO might be NULL in PRE


On Wed, Oct 24, 2012 at 3:13 AM, Zhenqiang Chen
<zhenqiang.chen@linaro.org> wrote:
> On 23 October 2012 18:02, Richard Biener <richard.guenther@gmail.com> wrote:
>> 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)
>
> 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.

Ah, call folding on block merging ... :/  I suppose we can even end up
leaking memory that way when SSA names are released there.

Let me take the bug.

Richard.

> Thanks!
> -Zhenqiang


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]