public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] lower-bitint: Fix handle_cast ICE [PR113102]
@ 2023-12-22  8:12 Jakub Jelinek
  2023-12-22 10:07 ` Richard Biener
  0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2023-12-22  8:12 UTC (permalink / raw)
  To: Richard Biener; +Cc: gcc-patches

Hi!

My recent change to use m_data[save_data_cnt] instead of
m_data[save_data_cnt + 1] when inside of a loop (m_bb is non-NULL)
broke the following testcase.  When we create a PHI node on the loop
using prepare_data_in_out, both m_data[save_data_cnt{, + 1}] are
computed and the fix was right, but there are also cases when we in
a loop (m_bb non-NULL) emit a nested cast with too few limbs and
then just use constant indexes for all accesses - in that case
only m_data[save_data_cnt + 1] is initialized and m_data[save_data_cnt]
is NULL.  In those cases, we want to use the former.

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

2023-12-22  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/113102
	* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Only
	use m_data[save_data_cnt] if it is non-NULL.

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

--- gcc/gimple-lower-bitint.cc.jj	2023-12-21 11:13:32.000000000 +0100
+++ gcc/gimple-lower-bitint.cc	2023-12-21 13:28:56.953120687 +0100
@@ -1491,7 +1491,7 @@ bitint_large_huge::handle_cast (tree lhs
 		m_data_cnt = tree_to_uhwi (m_data[save_data_cnt + 2]);
 	      if (TYPE_UNSIGNED (rhs_type))
 		t = build_zero_cst (m_limb_type);
-	      else if (m_bb)
+	      else if (m_bb && m_data[save_data_cnt])
 		t = m_data[save_data_cnt];
 	      else
 		t = m_data[save_data_cnt + 1];
--- gcc/testsuite/gcc.dg/bitint-58.c.jj	2023-12-21 13:33:25.882383838 +0100
+++ gcc/testsuite/gcc.dg/bitint-58.c	2023-12-21 13:32:54.408821172 +0100
@@ -0,0 +1,31 @@
+/* PR tree-optimization/113102 */
+/* { dg-do compile { target bitint } } */
+/* { dg-options "-std=c23 -O2" } */
+
+_BitInt(3) a;
+#if __BITINT_MAXWIDTH__ >= 4097
+_BitInt(8) b;
+_BitInt(495) c;
+_BitInt(513) d;
+_BitInt(1085) e;
+_BitInt(4096) f;
+
+void
+foo (void)
+{
+  a -= (_BitInt(4097)) d >> b;
+}
+
+void
+bar (void)
+{
+  __builtin_sub_overflow ((_BitInt(767)) c >> e, 0, &a);
+}
+
+void
+baz (void)
+{
+  _BitInt(768) x = (_BitInt(257))f;
+  b /= x >> 0 / 0;	/* { dg-warning "division by zero" } */
+}
+#endif

	Jakub


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] lower-bitint: Fix handle_cast ICE [PR113102]
  2023-12-22  8:12 [PATCH] lower-bitint: Fix handle_cast ICE [PR113102] Jakub Jelinek
@ 2023-12-22 10:07 ` Richard Biener
  0 siblings, 0 replies; 2+ messages in thread
From: Richard Biener @ 2023-12-22 10:07 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc-patches



> Am 22.12.2023 um 09:12 schrieb Jakub Jelinek <jakub@redhat.com>:
> 
> Hi!
> 
> My recent change to use m_data[save_data_cnt] instead of
> m_data[save_data_cnt + 1] when inside of a loop (m_bb is non-NULL)
> broke the following testcase.  When we create a PHI node on the loop
> using prepare_data_in_out, both m_data[save_data_cnt{, + 1}] are
> computed and the fix was right, but there are also cases when we in
> a loop (m_bb non-NULL) emit a nested cast with too few limbs and
> then just use constant indexes for all accesses - in that case
> only m_data[save_data_cnt + 1] is initialized and m_data[save_data_cnt]
> is NULL.  In those cases, we want to use the former.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok

> 2023-12-22  Jakub Jelinek  <jakub@redhat.com>
> 
>    PR tree-optimization/113102
>    * gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Only
>    use m_data[save_data_cnt] if it is non-NULL.
> 
>    * gcc.dg/bitint-58.c: New test.
> 
> --- gcc/gimple-lower-bitint.cc.jj    2023-12-21 11:13:32.000000000 +0100
> +++ gcc/gimple-lower-bitint.cc    2023-12-21 13:28:56.953120687 +0100
> @@ -1491,7 +1491,7 @@ bitint_large_huge::handle_cast (tree lhs
>        m_data_cnt = tree_to_uhwi (m_data[save_data_cnt + 2]);
>          if (TYPE_UNSIGNED (rhs_type))
>        t = build_zero_cst (m_limb_type);
> -          else if (m_bb)
> +          else if (m_bb && m_data[save_data_cnt])
>        t = m_data[save_data_cnt];
>          else
>        t = m_data[save_data_cnt + 1];
> --- gcc/testsuite/gcc.dg/bitint-58.c.jj    2023-12-21 13:33:25.882383838 +0100
> +++ gcc/testsuite/gcc.dg/bitint-58.c    2023-12-21 13:32:54.408821172 +0100
> @@ -0,0 +1,31 @@
> +/* PR tree-optimization/113102 */
> +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-std=c23 -O2" } */
> +
> +_BitInt(3) a;
> +#if __BITINT_MAXWIDTH__ >= 4097
> +_BitInt(8) b;
> +_BitInt(495) c;
> +_BitInt(513) d;
> +_BitInt(1085) e;
> +_BitInt(4096) f;
> +
> +void
> +foo (void)
> +{
> +  a -= (_BitInt(4097)) d >> b;
> +}
> +
> +void
> +bar (void)
> +{
> +  __builtin_sub_overflow ((_BitInt(767)) c >> e, 0, &a);
> +}
> +
> +void
> +baz (void)
> +{
> +  _BitInt(768) x = (_BitInt(257))f;
> +  b /= x >> 0 / 0;    /* { dg-warning "division by zero" } */
> +}
> +#endif
> 
>    Jakub
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-12-22 10:07 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-22  8:12 [PATCH] lower-bitint: Fix handle_cast ICE [PR113102] Jakub Jelinek
2023-12-22 10:07 ` 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).