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.