[Bug ipa/109652] [14 Regression] ICE on valgrind-3.20.0: in modify_expression, at ipa-param-manipulation.cc:1866 since r14-295-gd89e23f27215fc

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

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we're replacing (in a call this time) the aggregate argument ri_3(D)->ARMri5
(it's a union) with a register

(gdb) p debug_tree (repl)
 <parm_decl 0x7ffff7fc9900 ISRA.3
    type <integer_type 0x7ffff736fa80 UInt sizes-gimplified SI

and we VIEW_CONVERT that to the original aggregate type.  That's not
really GIMPLE IL we want to have.  Instead in this case ISRA.3 should
be forced a non-register.  The question is whether we can detect this
case where I originally tried to fix the original issue - namely

diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
index 42488ee09c3..473d759f983 100644
--- a/gcc/ipa-param-manipulation.cc
+++ b/gcc/ipa-param-manipulation.cc
@@ -1384,6 +1384,8 @@ ipa_param_body_adjustments::common_initialization (tree
old_fndecl,
          DECL_CONTEXT (new_parm) = m_fndecl;
          TREE_USED (new_parm) = 1;
          DECL_IGNORED_P (new_parm) = 1;
+         if (is_gimple_reg_type (new_type))
+           DECL_NOT_GIMPLE_REG_P (new_parm) = 1;
          layout_decl (new_parm, 0);
          m_new_decls.quick_push (new_parm);

I only see

(gdb) p *apm
$7 = {type = <integer_type 0x7ffff736fa80 UInt>, 
  alias_ptr_type = <pointer_type 0x7ffff739eb28>, unit_offset = 0, 
  base_index = 0, prev_clone_index = 0, op = IPA_PARAM_OP_SPLIT, 
  prev_clone_adjustment = 0, param_prefix_index = 1, reverse = 0, 
  user_flag = 0}

so there doesn't seem to be something indicating there's an aggregate use?

Of course in theory we can fix up in modify_expression by copying the
register to a non-register for such case but that might not be the
most efficient way to deal with this.

The "easiest" fix is to let this case slip through.  It isn't catched
by my planned extra IL checking.  We'll generate

  iregEnc (VIEW_CONVERT_EXPR<union
{
  struct
  {
    UInt imm5;
  } I5;
}>(_7));