https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
--- Comment #15 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Rohith Kapelli <[email protected]>: https://gcc.gnu.org/g:d794365c8f0dcf6c5cdd742296c64c19278de1f8 commit r17-4004-gd794365c8f0dcf6c5cdd742296c64c19278de1f8 Author: Rohith Kapelli <[email protected]> Date: Sun Sep 6 00:48:26 2026 +0530 ipa-icf: compare the field, not just the offset, under OEP_ADDRESS_OF [PR119006] func_checker::compare_operand compares non-memory operands with a bare operand_equal_p and OEP_MATCH_SIDE_EFFECTS. When the operand is an ADDR_EXPR, operand_equal_p recurses with OEP_ADDRESS_OF set, and for a COMPONENT_REF under OEP_ADDRESS_OF it accepts two different FIELD_DECLs whose DECL_FIELD_OFFSET and DECL_FIELD_BIT_OFFSET agree. That is correct for the value of the address, but ICF is not only comparing an address. The surviving body carries one of the two field types into every caller, and get_range_strlen_tree reads TYPE_DOMAIN and TYPE_MAX_VALUE off it. In the PR two structs hold a char array as their first member, one of 11 and one of 128 elements, with identical operator== bodies. ICF unifies them, the surviving body carries char[11], and the strlen machinery then concludes that a 15 character string cannot be there. Pass OEP_ADDRESS_OF_SAME_FIELD, which tree-core.h already documents for this case: "For OEP_ADDRESS_OF of COMPONENT_REFs, only consider same fields as equivalent rather than also different fields with the same offset." fold-const.cc honours it at the point where the two offsets would otherwise be accepted. PR ipa/119006 gcc/ChangeLog: * ipa-icf-gimple.cc (func_checker::compare_operand): Pass OEP_ADDRESS_OF_SAME_FIELD to operand_equal_p. gcc/testsuite/ChangeLog: * g++.dg/ipa/pr119006.C: New test. Signed-off-by: Rohith Kapelli <[email protected]>
