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.
2024-01-20 Jakub Jelinek <jakub@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.
{
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
--- /dev/null
+/* 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;
+}