On 01/15/14 10:07, Teresa Johnson wrote:
Handle NULL vdef for call in the case where we have a matching vnresult
that has a vdef (it already handles the NULL vdef case when !vnresult). This
can happen for promoted indirect calls if the fallback indirect call
(which has a vdef) can be proven equivalent to the promoted direct call
(which might not have a vdef).
This occurred for a case where we had a promoted indirect call,
where FRE determined that the promoted direct call and the fall-back indirect
call were equivalent (since earlier it determined that the function pointer
was always set to that target). The indirect call had been analyzed by
visit_reference_op_call first, and had a VDEF. The direct call did not have a
VDEF, presumably because it was a leaf function in the same module without any
stores. But visit_reference_op_call unconditionally calls set_ssa_val_to when
the previous vnresult had a vdef, leading to a seg fault in this case.
If we had analyzed the direct call first the failure wouldn't have occurred
since the !vnresult case guards the call to set_ssa_val_to with a check
for a NULL vdef, and the subsequent handling of the indirect call would
also not call set_ssa_val_to since vnresult would have had a null result_vdef.
Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?
2014-01-15 Teresa Johnson <tejohn...@google.com>
* tree-ssa-sccvn.c (visit_reference_op_call): Handle NULL vdef.
The patch is OK. Given this was an ICE, do you have a reduced test we
can add to the regression suite? I realize that order of visiting in
the SCC is important to trigger, but a regression test would still be
useful.
Thanks,
Jeff
