* [PATCH] expr: Fix &bitint_var handling in initializers [PR112336]
@ 2023-11-23 10:04 Jakub Jelinek
2023-11-23 11:41 ` Richard Biener
0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2023-11-23 10:04 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
Hi!
As the following testcase shows, we ICE when trying to emit ADDR_EXPR of
a bitint variable which doesn't have mode width.
The problem is in the EXTEND_BITINT stuff which makes sure we treat the
padding bits on memory reads from user bitint vars as undefined.
When expanding ADDR_EXPR on such vars inside outside of initializers,
expand_expr_addr* uses EXPAND_CONST_ADDRESS modifier and EXTEND_BITINT
does nothing, but in initializers it keeps using EXPAND_INITIALIZER
modifier. So, we need to treat EXPAND_INITIALIZER the same as
EXPAND_CONST_ADDRESS for this regard.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2023-11-23 Jakub Jelinek <jakub@redhat.com>
PR middle-end/112336
* expr.cc (EXTEND_BITINT): Don't call reduce_to_bit_field_precision
if modifier is EXPAND_INITIALIZER.
* gcc.dg/bitint-41.c: New test.
--- gcc/expr.cc.jj 2023-11-14 18:26:05.401613476 +0100
+++ gcc/expr.cc 2023-11-22 19:03:59.121599029 +0100
@@ -10698,6 +10698,7 @@ expand_expr_real_1 (tree exp, rtx target
&& mode != BLKmode \
&& modifier != EXPAND_MEMORY \
&& modifier != EXPAND_WRITE \
+ && modifier != EXPAND_INITIALIZER \
&& modifier != EXPAND_CONST_ADDRESS) \
? reduce_to_bit_field_precision ((expr), NULL_RTX, type) : (expr))
--- gcc/testsuite/gcc.dg/bitint-41.c.jj 2023-11-22 19:09:48.986726861 +0100
+++ gcc/testsuite/gcc.dg/bitint-41.c 2023-11-22 19:09:29.804993983 +0100
@@ -0,0 +1,36 @@
+/* PR middle-end/112336 */
+/* { dg-do compile { target bitint } } */
+/* { dg-options "-std=c2x" } */
+
+unsigned _BitInt(1) v1;
+unsigned _BitInt(1) *p1 = &v1;
+signed _BitInt(2) v2;
+signed _BitInt(2) *p2 = &v2;
+unsigned _BitInt(11) v11;
+unsigned _BitInt(11) *p11 = &v11;
+signed _BitInt(12) v12;
+signed _BitInt(12) *p12 = &v12;
+unsigned _BitInt(21) v21;
+unsigned _BitInt(21) *p21 = &v21;
+signed _BitInt(22) v22;
+signed _BitInt(22) *p22 = &v22;
+unsigned _BitInt(31) v31;
+unsigned _BitInt(31) *p31 = &v31;
+signed _BitInt(32) v32;
+signed _BitInt(32) *p32 = &v32;
+unsigned _BitInt(41) v41;
+unsigned _BitInt(41) *p41 = &v41;
+signed _BitInt(42) v42;
+signed _BitInt(42) *p42 = &v42;
+#if __BITINT_MAXWIDTH__ >= 128
+unsigned _BitInt(127) v127;
+unsigned _BitInt(127) *p127 = &v127;
+signed _BitInt(128) v128;
+signed _BitInt(128) *p128 = &v128;
+#endif
+#if __BITINT_MAXWIDTH__ >= 258
+unsigned _BitInt(257) v257;
+unsigned _BitInt(257) *p257 = &v257;
+signed _BitInt(258) v258;
+signed _BitInt(258) *p258 = &v258;
+#endif
Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] expr: Fix &bitint_var handling in initializers [PR112336]
2023-11-23 10:04 [PATCH] expr: Fix &bitint_var handling in initializers [PR112336] Jakub Jelinek
@ 2023-11-23 11:41 ` Richard Biener
0 siblings, 0 replies; 2+ messages in thread
From: Richard Biener @ 2023-11-23 11:41 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Richard Biener, gcc-patches
On Thu, Nov 23, 2023 at 11:05 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> Hi!
>
> As the following testcase shows, we ICE when trying to emit ADDR_EXPR of
> a bitint variable which doesn't have mode width.
> The problem is in the EXTEND_BITINT stuff which makes sure we treat the
> padding bits on memory reads from user bitint vars as undefined.
> When expanding ADDR_EXPR on such vars inside outside of initializers,
> expand_expr_addr* uses EXPAND_CONST_ADDRESS modifier and EXTEND_BITINT
> does nothing, but in initializers it keeps using EXPAND_INITIALIZER
> modifier. So, we need to treat EXPAND_INITIALIZER the same as
> EXPAND_CONST_ADDRESS for this regard.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
> 2023-11-23 Jakub Jelinek <jakub@redhat.com>
>
> PR middle-end/112336
> * expr.cc (EXTEND_BITINT): Don't call reduce_to_bit_field_precision
> if modifier is EXPAND_INITIALIZER.
>
> * gcc.dg/bitint-41.c: New test.
>
> --- gcc/expr.cc.jj 2023-11-14 18:26:05.401613476 +0100
> +++ gcc/expr.cc 2023-11-22 19:03:59.121599029 +0100
> @@ -10698,6 +10698,7 @@ expand_expr_real_1 (tree exp, rtx target
> && mode != BLKmode \
> && modifier != EXPAND_MEMORY \
> && modifier != EXPAND_WRITE \
> + && modifier != EXPAND_INITIALIZER \
> && modifier != EXPAND_CONST_ADDRESS) \
> ? reduce_to_bit_field_precision ((expr), NULL_RTX, type) : (expr))
>
> --- gcc/testsuite/gcc.dg/bitint-41.c.jj 2023-11-22 19:09:48.986726861 +0100
> +++ gcc/testsuite/gcc.dg/bitint-41.c 2023-11-22 19:09:29.804993983 +0100
> @@ -0,0 +1,36 @@
> +/* PR middle-end/112336 */
> +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-std=c2x" } */
> +
> +unsigned _BitInt(1) v1;
> +unsigned _BitInt(1) *p1 = &v1;
> +signed _BitInt(2) v2;
> +signed _BitInt(2) *p2 = &v2;
> +unsigned _BitInt(11) v11;
> +unsigned _BitInt(11) *p11 = &v11;
> +signed _BitInt(12) v12;
> +signed _BitInt(12) *p12 = &v12;
> +unsigned _BitInt(21) v21;
> +unsigned _BitInt(21) *p21 = &v21;
> +signed _BitInt(22) v22;
> +signed _BitInt(22) *p22 = &v22;
> +unsigned _BitInt(31) v31;
> +unsigned _BitInt(31) *p31 = &v31;
> +signed _BitInt(32) v32;
> +signed _BitInt(32) *p32 = &v32;
> +unsigned _BitInt(41) v41;
> +unsigned _BitInt(41) *p41 = &v41;
> +signed _BitInt(42) v42;
> +signed _BitInt(42) *p42 = &v42;
> +#if __BITINT_MAXWIDTH__ >= 128
> +unsigned _BitInt(127) v127;
> +unsigned _BitInt(127) *p127 = &v127;
> +signed _BitInt(128) v128;
> +signed _BitInt(128) *p128 = &v128;
> +#endif
> +#if __BITINT_MAXWIDTH__ >= 258
> +unsigned _BitInt(257) v257;
> +unsigned _BitInt(257) *p257 = &v257;
> +signed _BitInt(258) v258;
> +signed _BitInt(258) *p258 = &v258;
> +#endif
>
> Jakub
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-11-23 11:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-23 10:04 [PATCH] expr: Fix &bitint_var handling in initializers [PR112336] Jakub Jelinek
2023-11-23 11:41 ` Richard Biener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).