[Bug middle-end/113988] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470

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

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, I've tried
--- gcc/gimple-lower-bitint.cc.jj       2024-02-15 09:52:40.999145971 +0100
+++ gcc/gimple-lower-bitint.cc  2024-02-21 12:48:38.704163901 +0100
@@ -5307,12 +5307,15 @@ bitint_large_huge::lower_stmt (gimple *s
          final_cast_p = true;
          if (TREE_CODE (TREE_TYPE (lhs)) == INTEGER_TYPE
              && TYPE_PRECISION (TREE_TYPE (lhs)) > MAX_FIXED_MODE_SIZE
-             && gimple_assign_rhs_code (stmt) == VIEW_CONVERT_EXPR)
+             && (gimple_assign_rhs_code (stmt) == VIEW_CONVERT_EXPR
+                 || (TYPE_PRECISION (TREE_TYPE (lhs))
+                     == TYPE_PRECISION (TREE_TYPE (rhs1)))))
            {
-             /* Handle VIEW_CONVERT_EXPRs to not generally supported
-                huge INTEGER_TYPEs like uint256_t or uint512_t.  These
-                are usually emitted from memcpy folding and backends
-                support moves with them but that is usually it.  */
+             /* Handle VIEW_CONVERT_EXPRs or same precision casts to not
+                generally supported huge INTEGER_TYPEs like uint256_t or
+                uint512_t.  These are usually emitted from memcpy folding
+                and backends support moves with them but that is usually
+                it.  */
              if (TREE_CODE (rhs1) == INTEGER_CST)
                {
                  rhs1 = fold_unary (VIEW_CONVERT_EXPR, TREE_TYPE (lhs),
@@ -5339,6 +5342,7 @@ bitint_large_huge::lower_stmt (gimple *s
                  rhs1 = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (lhs),
                                 m_vars[part]);
                  gimple_assign_set_rhs1 (stmt, rhs1);
+                 gimple_assign_set_rhs_code (stmt, VIEW_CONVERT_EXPR);
                }
              update_stmt (stmt);
              return;
and while that fixes #c14 bar and qux, foo and baz still ICE, this time during
expansion:
pr113988.c: In function ‘foo’:
pr113988.c:12:3: internal compiler error: in convert_move, at expr.cc:223
   12 |   __builtin_memcpy (p, &x, sizeof x);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0x801435 convert_move(rtx_def*, rtx_def*, int)
        ../../gcc/expr.cc:223
0x826b99 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        ../../gcc/expr.cc:9799
0x82c8f5 expand_expr_real_gassign(gassign*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        ../../gcc/expr.cc:11096
0x82d4b2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        ../../gcc/expr.cc:11277
0x825541 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
        ../../gcc/expr.cc:9440
0x81a2df store_expr(tree_node*, rtx_def*, int, bool, bool)
        ../../gcc/expr.cc:6740
0x818717 expand_assignment(tree_node*, tree_node*, bool)
        ../../gcc/expr.cc:6461
The problem is that for bar/qux it is a VCE from an array, so nothing tries to
change it into something else, for e.g. foo bitintlower turns it into
  uint256_t _2;

  <bb 2> [local count: 1073741824]:
  _2 = VIEW_CONVERT_EXPR<uint256_t>(x);
  MEM <uint256_t> [(char * {ref-all})p_4(D)] = _2;
where x is TREE_ADDRESSABLE _BitInt(256) PARM_DECL, but forwprop3 turns that
into
  _2 = (uint256_t) x_1(D);
and expansion isn't able to expand that (BLKmode PARM_DECL expanded as a MEM
NOP_EXPR converted to OImode.

So, either we could somehow handle that case during expansion (treat it
basically as VCE), or tweak the
/* For integral conversions with the same precision or pointer
   conversions use a NOP_EXPR instead.  */
(simplify
  (view_convert @0)
  (if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type))
       && (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0)))
       && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0)))
   (convert @0)))
match.pd rule not to do that for INTEGER_TYPEs with PRECISION >
MAX_FIXED_TYPE_PRECISION (then we don't need the gimple-lower-bitint.cc changes
either).
--- gcc/match.pd.jj     2024-02-19 09:42:16.583617451 +0100
+++ gcc/match.pd        2024-02-21 13:32:06.567816298 +0100
@@ -4679,7 +4679,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (view_convert @0)
   (if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type))
        && (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE
(@0)))
-       && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0)))
+       && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0))
+       /* Punt for conversions from or to barely supported huge
+         INTEGER_TYPEs.  Those can handle just loads/stores/moves but
+         nothing else.  */
+       && (TYPE_PRECISION (type) <= MAX_FIXED_MODE_SIZE
+          || (TREE_CODE (type) != INTEGER_TYPE
+              && TREE_CODE (TREE_TYPE (@0)) != INTEGER_TYPE)))
    (convert @0)))

 /* Strip inner integral conversions that do not change precision or size, or