[PATCH] Fix segfault in FRE during SCC value numbering
Teresa Johnson
tejohnson@google.com
Wed Jan 15 17:07:00 GMT 2014
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 <tejohnson@google.com>
* tree-ssa-sccvn.c (visit_reference_op_call): Handle NULL vdef.
Index: tree-ssa-sccvn.c
===================================================================
--- tree-ssa-sccvn.c (revision 206100)
+++ tree-ssa-sccvn.c (working copy)
@@ -2792,7 +2792,7 @@ visit_reference_op_call (tree lhs, gimple stmt)
if (vnresult)
{
- if (vnresult->result_vdef)
+ if (vnresult->result_vdef && vdef)
changed |= set_ssa_val_to (vdef, vnresult->result_vdef);
if (!vnresult->result && lhs)
--
Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413
More information about the Gcc-patches
mailing list