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 <ja...@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
