Hi!

The following patch ICEs because fre3 leaves around unfolded
  _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
statement and in handle_cast I was expecting just SSA_NAMEs for the
large/huge _BitInt to large/huge _BitInt casts; INTEGER_CST is something
we can handle in that case exactly the same, as the handle_operand recursion
handles those.

Of course, maybe we should also try to fold_stmt such cases somewhere in
bitint lowering preparation.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-01-20  Jakub Jelinek  <ja...@redhat.com>

        PR tree-optimization/113462
        * gimple-lower-bitint.cc (bitint_large_huge::handle_cast):
        Handle rhs1 INTEGER_CST like SSA_NAME.

        * gcc.dg/bitint-76.c: New test.

--- gcc/gimple-lower-bitint.cc.jj       2024-01-19 10:01:37.696673929 +0100
+++ gcc/gimple-lower-bitint.cc  2024-01-19 18:36:34.175254308 +0100
@@ -1250,7 +1250,7 @@ bitint_large_huge::handle_cast (tree lhs
 {
   tree rhs_type = TREE_TYPE (rhs1);
   gimple *g;
-  if (TREE_CODE (rhs1) == SSA_NAME
+  if ((TREE_CODE (rhs1) == SSA_NAME || TREE_CODE (rhs1) == INTEGER_CST)
       && TREE_CODE (lhs_type) == BITINT_TYPE
       && TREE_CODE (rhs_type) == BITINT_TYPE
       && bitint_precision_kind (lhs_type) >= bitint_prec_large
--- gcc/testsuite/gcc.dg/bitint-76.c.jj 2024-01-19 18:39:23.883980766 +0100
+++ gcc/testsuite/gcc.dg/bitint-76.c    2024-01-19 18:38:48.758451335 +0100
@@ -0,0 +1,16 @@
+/* PR tree-optimization/113462 */
+/* { dg-do compile { target bitint } } */
+/* { dg-options "-std=c23 -O2" } */
+
+#if __BITINT_MAXWIDTH__ >= 129
+typedef _BitInt(129) B;
+#else
+typedef _BitInt(63) B;
+#endif
+
+B
+foo (void)
+{
+  struct { B b; } s = {};
+  return s.b;
+}

        Jakub

Reply via email to