[Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65233

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard.guenther at gmail dot com

--- Comment #20 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #19)
> Right.  That's the last step for updating the CFG for a series of jump
> threads.
> 
> It's certainly the case that the redirections can leave unreachable blocks. 
> But the first thing that the cfg cleanup routines ought to be doing is
> removing those unreachable blocks -- before we call any of the block merging
> code.
> 
> That happens in cleanup_tree_cfg_noloop.  So I'd be real interested to know
> if we have any unreachable blocks in the CFG after cleanup_tree_cfg_noloop
> has completed.

I see.

Then, something's definitely odd here.

The PHI which ended up empty is SR.33_23:

  <bb 30>:
  # SR.33_23 = PHI <>
  # SR.32_80 = PHI <>
  # DEBUG this => D#8
  goto <bb 12>;

This entire block got wiped by delete_unreachable_blocks (correctly) through
cleanup_tree_cfg_noloop.

However, we still have references to
SR.33_23, which is no longer being set because BB 30 no longer exists:

  <bb 13>:
  # SR.33_83 = PHI <SR.33_23(47)>
  # SR.32_16 = PHI <SR.32_80(47)>
  # DEBUG this => &D.3962
  # DEBUG D#1 => &D.3962.pn
  # DEBUG this => D#1
  # DEBUG this => SR.33_83
  _18 = SR.33_83->_vptr.C;
  _19 = *_18;
  OBJ_TYPE_REF(_19;(struct C)SR.33_23->0) (SR.33_23);
  goto <bb 15>;

We get the ICE because, while we are analyzing OBJ_TYPE_REF() above,
we try to analyze the SR.33_23, which still points to the now defunct
PHI.

Although, if I understand Richi correctly here:

https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00038.html

...ipa_polymorphic_call_context::ipa_polymorphic_call_context() should
not be calling walk_ssa_copies() at all when called through
fold_stmt() which is certainly the case here.  Apparently,
fold_stmt() and its derivatives should not walk the SSA usa-def chain.
Is this what you meant Richi?  (BTW, where is this restriction on
fold_stmt() documented?)

If that's the case, I may have to put this PR back for Honza to
tackle/redesign.