]> git.ipfire.org Git - thirdparty/gcc.git/commit
lower-bitint: Fix up __builtin_{add,sub}_overflow{,_p} bitint lowering [PR116501]
authorJakub Jelinek <jakub@redhat.com>
Tue, 3 Sep 2024 08:20:44 +0000 (10:20 +0200)
committerJakub Jelinek <jakub@gcc.gnu.org>
Tue, 3 Sep 2024 08:21:53 +0000 (10:21 +0200)
commitd4d75a83007e884bfcd632ea3b3269704496f048
tree2199450388d22989b97f333eb3b5c6c862b52e79
parenta19cf635ea29658d5f9fc19199473d6d823ef2d1
lower-bitint: Fix up __builtin_{add,sub}_overflow{,_p} bitint lowering [PR116501]

The following testcase is miscompiled.  The problem is in the last_ovf step.
The second operand has signed _BitInt(513) type but has the MSB clear,
so range_to_prec returns 512 for it (i.e. it fits into unsigned
_BitInt(512)).  Because of that the last step actually doesn't need to get
the most significant bit from the second operand, but the code was deciding
what to use purely from TYPE_UNSIGNED (type1) - if unsigned, use 0,
otherwise sign-extend the last processed bit; but that in this case was set.
We don't want to treat the positive operand as if it was negative regardless
of the bit below that precision, and precN >= 0 indicates that the operand
is in the [0, inf) range.

2024-09-03  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/116501
* gimple-lower-bitint.cc (bitint_large_huge::lower_addsub_overflow):
In the last_ovf case, use build_zero_cst operand not just when
TYPE_UNSIGNED (typeN), but also when precN >= 0.

* gcc.dg/torture/bitint-73.c: New test.
gcc/gimple-lower-bitint.cc
gcc/testsuite/gcc.dg/torture/bitint-73.c [new file with mode: 0644]