On 10/14/25 5:40 AM, Siddhesh Poyarekar wrote:
On 2025-10-12 00:30, Sam James wrote:
Linsen Zhou <[email protected]> writes:

After commit 51b85dfeb19652bf3e0aaec08828ba7cee1e641c, when the pointer
offset is a variable in the loop, the object size of point may also need
to be reexamined.
Which make gcc_assert in the check_for_plus_in_loops failed.

gcc/ChangeLog:

         tree-object-size.cc (check_for_plus_in_loops): Skip check for
         the variable offset

Signed-off-by: Linsen Zhou <[email protected]>
---

Could you add a testcase to the patch, and also add a reference to
PR122012 in the commit message and in the ChangeLog?

I can't review this though, cc'd Sid whose patch exposed this.


Related Alpine Linux issues:

https://gitlab.alpinelinux.org/alpine/aports/-/issues/17416
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87912

  gcc/tree-object-size.cc | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/tree-object-size.cc b/gcc/tree-object-size.cc
index 8545eff61a3..413e67a8125 100644
--- a/gcc/tree-object-size.cc
+++ b/gcc/tree-object-size.cc
@@ -2147,10 +2147,9 @@ check_for_plus_in_loops (struct object_size_info *osi, tree var)
        tree basevar = gimple_assign_rhs1 (stmt);
        tree cst = gimple_assign_rhs2 (stmt);
-      gcc_assert (TREE_CODE (cst) == INTEGER_CST);
-

I think keeping the tree in 'cst' is confusing if we can on longer rely
on it being a constant expression, but please let others comment first.

Agreed, lets call this `offset`.


        /* Skip non-positive offsets.  */
-      if (integer_zerop (cst) || compare_tree_int (cst, offset_limit) > 0)
+      if (TREE_CODE (cst) != INTEGER_CST
+      || integer_zerop (cst) || compare_tree_int (cst, offset_limit) > 0)
          return;
        osi->depths[SSA_NAME_VERSION (basevar)] = 1;

This looks good to me; I had made the incorrect assumption that only constant expressions would make it here.  I can't approve though, you'll need a maintainer to do that.
Sid, given you wrote this code and ACK'd, I'll rubber-stamp.

Ideally this would include a testcase we can use in our testsuite.

Given it triggers an ICE, just adding a suitable file to gcc.dg/torture should be sufficient.

Given this changes target independent code it needs to be bootstrapped and regression tested on one of the primary platforms. Most folks use x86-64 or aarch64 for the bootstrap & regression test.

Can you do these things Linsen?

jeff


Reply via email to