diff options
author | Jakub Jelinek <jakub@redhat.com> | 2024-02-23 11:36:15 +0100 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2024-02-23 11:36:15 +0100 |
commit | be1f2bc4522f772184a4d16d8f3fec75baed89cf (patch) | |
tree | 4c5510af7ac6edb11ab9ebcbee6481ae7392e96e /gcc/expr.cc | |
parent | f09a9dd319ef8b698d4bff90b975f5a0a7495de9 (diff) | |
download | gcc-be1f2bc4522f772184a4d16d8f3fec75baed89cf.zip gcc-be1f2bc4522f772184a4d16d8f3fec75baed89cf.tar.gz gcc-be1f2bc4522f772184a4d16d8f3fec75baed89cf.tar.bz2 |
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 <jakub@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.
Diffstat (limited to 'gcc/expr.cc')
0 files changed, 0 insertions, 0 deletions