https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127378
--- Comment #1 from Manjunath S Matti <mmatti.gnu at gmail dot com> ---
The minor fix, solves this issue!
diff --git a/gcc/gimple-lower-bitint.cc b/gcc/gimple-lower-bitint.cc
index e36534ba13d..6725dd45fd8 100644
--- a/gcc/gimple-lower-bitint.cc
+++ b/gcc/gimple-lower-bitint.cc
@@ -3271,15 +3271,20 @@ bitint_large_huge::lower_mergeable_stmt (gimple *stmt,
tree_code &cmp_code,
bitint_big_endian
? size_int (-1) : size_one_node);
insert_before (g);
- if (bitint_big_endian && rem != 0)
+ if (bitint_big_endian)
+ /* The loop descends, so test the index being stored rather
+ than the next one. A non-zero REM leaves the most
+ significant limb to the partial-limb store below, and a
+ non-zero BO_SHIFT leaves it to the trailing bit-field
+ store, so in those cases stop one limb earlier. */
g = gimple_build_cond (NE_EXPR, idx,
- size_int (bo_idx + 1),
+ size_int (bo_idx
+ + (rem != 0
+ || bo_shift != 0)),
NULL_TREE, NULL_TREE);
else
g = gimple_build_cond (NE_EXPR, idx_next,
- size_int (bo_idx
- + (bitint_big_endian
- ? 0 : end)),
+ size_int (bo_idx + end),
NULL_TREE, NULL_TREE);
insert_before (g);
m_gsi = gsi_for_stmt (stmt);
I have run make check on ppc64le and ppc64(m64,m32) the issue is resolved and
no regressions! But I need to check if this affects the s390 (the only other
big endian), alas the cfarm machines are down
@jakub is the fix at the appropriate.
