[PATCH] Fix segfault in FRE during SCC value numbering

[Teresa Johnson <tejohnson@google.com>]

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