Sam James <[email protected]> writes: > 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.
Ignore this part, I misread. >> /* 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; >> -- >> 2.51.0
