https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040
--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:be1f2bc4522f772184a4d16d8f3fec75baed89cf commit r14-9150-gbe1f2bc4522f772184a4d16d8f3fec75baed89cf Author: Jakub Jelinek <ja...@redhat.com> Date: Fri Feb 23 11:36:15 2024 +0100 bitintlower: Fix .{ADD,SUB}_OVERFLOW lowering [PR114040] The following testcases show 2 bugs in the .{ADD,SUB}_OVERFLOW lowering, both related to storing of the REALPART_EXPR part of the result. On the first testcase prec is 255, prec_limbs is 4 and for the second limb in the loop the store of the REALPART_EXPR of .USUBC (_30) is stored through: if (_27 <= 3) goto <bb 12>; [80.00%] else goto <bb 15>; [20.00%] <bb 12> [local count: 1073741824]: if (_27 < 3) goto <bb 14>; [80.00%] else goto <bb 13>; [20.00%] <bb 13> [local count: 1073741824]: bitint.3[_27] = _30; goto <bb 15>; [100.00%] <bb 14> [local count: 858993464]: MEM[(unsigned long *)&bitint.3 + 24B] = _30; <bb 15> [local count: 1073741824]: The first check is right, as prec_limbs is 4, we don't want to store bitint.3[4] or above at all, those limbs are just computed for the overflow checking and nothing else, so _27 > 4 leads to no store. But the other condition is exact opposite of what should be done, if the current index of the second limb (_27) is < 3, then it should bitint.3[_27] = _30; and if it is == 3, it should MEM[(unsigned long *)&bitint.3 + 24B] = _30; and (especially important for the targets which would bitinfo.extended = 1) should actually in this case zero extend it from the 63 bits to 64, that is the handling of the partial limb. The if_then_if_then_else helper if there are 2 conditions sets m_gsi to be at the start of the edge_true_false->dest bb, i.e. when the first condition is true and second false, and that is where we store the SSA_NAME indexed limb store, so the condition needs to be reversed. The following patch does that and adds the cast as well, the usual assumption that already handle_operand has the partial limb type doesn't have to be true here, because the source operand could have much larger precision than the REALPART_EXPR of the lhs. 2024-02-23 Jakub Jelinek <ja...@redhat.com> PR tree-optimization/114040 * gimple-lower-bitint.cc (bitint_large_huge::lower_addsub_overflow): Use EQ_EXPR rather than LT_EXPR for g2 condition and change its probability from likely to unlikely. When handling the true true store, first cast to limb_access_type and then to l's type. * gcc.dg/torture/bitint-60.c: New test. * gcc.dg/torture/bitint-61.c: New test.
