> Am 20.01.2024 um 10:39 schrieb Jakub Jelinek <ja...@redhat.com>:
>
> Hi!
>
> The following patch ICEs because fre3 leaves around unfolded
> _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
Hmm, const_unop should handle this, I suppose either we fail to convert this to
a NOP_EXPR or native encode/interpret do not handle it?
Richard
> 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?
Ok
Richard
> 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
>
