https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98474
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-8 branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:8cbe9fc12453026f7efc02dad569c6270d595427 commit r8-10872-g8cbe9fc12453026f7efc02dad569c6270d595427 Author: Jakub Jelinek <ja...@redhat.com> Date: Thu Dec 31 11:06:56 2020 +0100 wide-int: Fix wi::to_mpz [PR98474] The following testcase is miscompiled, because niter analysis miscomputes the number of iterations to 0. The problem is that niter analysis uses mpz_t (wonder why, wouldn't widest_int do the same job?) and when wi::to_mpz is called e.g. on the TYPE_MAX_VALUE of __uint128_t, it initializes the mpz_t result with wrong value. wi::to_mpz has code to handle negative wide_ints in signed types by inverting all bits, importing to mpz and complementing it, which is fine, but doesn't handle correctly the case when the wide_int's len (times HOST_BITS_PER_WIDE_INT) is smaller than precision when wi::neg_p. E.g. the 0xffffffffffffffffffffffffffffffff TYPE_MAX_VALUE is represented in wide_int as 0xffffffffffffffff len 1, and wi::to_mpz would create 0xffffffffffffffff mpz_t value from that. This patch handles it by adding the needed -1 host wide int words (and has also code to deal with precision that aren't multiple of HOST_BITS_PER_WIDE_INT). 2020-12-31 Jakub Jelinek <ja...@redhat.com> PR tree-optimization/98474 * wide-int.cc (wi::to_mpz): If wide_int has MSB set, but type is unsigned and excess negative, append set bits after len until precision. * gcc.c-torture/execute/pr98474.c: New test. (cherry picked from commit a4d191d08c6acb24034af4182b3524e6ef97546c)
