[Bug ipa/60912] [4.10 Regression] wrong code with -O -fno-inline -fipa-pta

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60912

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, the issue here is that Bar::Bar()s ->callers is empty even though it is
called by main.

main/7 (int main()) @0x7ffff6daea40
  Type: function definition analyzed
  Visibility: externally_visible public
  References: 
  Referring: 
  Availability: available
  First run: 0
  Function flags: body only_called_at_startup
  Called by: 
  Calls: _ZN3BarC1Ev/6 (1.00 per call) _Znwm/14 (1.00 per call) (can throw
external) 
  Has 1 outgoing edges for indirect calls.

_ZN3BarC2Ev/5 (Bar::Bar()) @0x7ffff6dae7b0
  Type: function definition analyzed
  Visibility: externally_visible public weak comdat comdat_group:_ZN3BarC5Ev
one_only artificial
  Same comdat group as: _ZN3BarC1Ev/6
  References: _ZTV3Bar/8 (addr)
  Referring: _ZN3BarC1Ev/6 (alias)
  Availability: available
  First run: 0
  Function flags: body
  Called by: 
  Calls: _ZN4IFooC2Ev/2 (1.00 per call) 

Ah, main() calls _ZN3BarC1Ev/6 but we only have a body for _ZN3BarC2Ev/5.

_ZN3BarC1Ev/6 (Bar::Bar()) @0x7ffff6dae8f8
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: externally_visible public weak comdat comdat_group:_ZN3BarC5Ev
one_only artificial
  Same comdat group as: _ZN3BarC2Ev/5
  References: _ZN3BarC2Ev/5 (alias)
  Referring: 
  Availability: available
  First run: 0
  Function flags:
  Called by: main/7 (1.00 per call) 
  Calls: 

That means that

      for (e = node->callers; e; e = e->next_caller)
        {
          if (!e->call_stmt)
            continue;

...
        }

to walk all call stmts that call node doesn't work.

But next_/previous_sharing_asm_name is empty (of course).

Oh, we do associate_varinfo_to_alias in PTA which of course breaks the
above (at least for functions).

So we really need a way to walk, given a ultimate callee, all edges
that ultimately result in it.  With the caching done for
find_what_var_points_to we can avoid this walking.  Let's do that.

The issue is latent on branches.