https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116501
--- Comment #3 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:d4d75a83007e884bfcd632ea3b3269704496f048 commit r15-3408-gd4d75a83007e884bfcd632ea3b3269704496f048 Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Sep 3 10:20:44 2024 +0200 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 <ja...@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.
