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