https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118756
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Martin Jambor <jamb...@gcc.gnu.org>: https://gcc.gnu.org/g:d05b64bdd048ffb7f72d97553888934a9bcd13fa commit r15-7792-gd05b64bdd048ffb7f72d97553888934a9bcd13fa Author: Martin Jambor <mjam...@suse.cz> Date: Mon Mar 3 14:53:03 2025 +0100 ipa-vr: Handle non-conversion unary ops separately from conversions (PR 118785) Since we construct arithmetic jump functions even when there is a type conversion in between the operation encoded in the jump function and when it is passed in a call argument, the IPA propagation phase must also perform the operation and conversion in two steps. IPA-VR had actually been doing it even before for binary operations but, as PR 118756 exposes, not in the case on unary operations. This patch adds the necessary step to rectify that. Like in the scalar constant case, we depend on expr_type_first_operand_type_p to determine the type of the result of the arithmetic operation. On top this, the patch special-cases ABSU_EXPR because it looks useful an so that the PR testcase exercises the added code-path. This seems most appropriate for stage 4, long term we should probably stream the types, probably after also encoding them with a string of expr_eval_op rather than what we have today. A check for expr_type_first_operand_type_p was also missing in the handling of binary ops and the intermediate value_range was initialized with a wrong type, so I also fixed this. gcc/ChangeLog: 2025-02-24 Martin Jambor <mjam...@suse.cz> PR ipa/118785 * ipa-cp.cc (ipa_vr_intersect_with_arith_jfunc): Handle non-conversion unary operations separately before doing any conversions. Check expr_type_first_operand_type_p for non-unary operations too. Fix type of op_res. gcc/testsuite/ChangeLog: 2025-02-24 Martin Jambor <mjam...@suse.cz> PR ipa/118785 * g++.dg/lto/pr118785_0.C: New test.
