[Bug tree-optimization/98474] [8/9/10 Regression] incorrect results using __uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98474 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a4d191d08c6acb24034af4182b3524e6ef97546c commit r10-9224-ga4d191d08c6acb24034af4182b3524e6ef97546c Author: Jakub Jelinek 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 0x TYPE_MAX_VALUE is represented in wide_int as 0x len 1, and wi::to_mpz would create 0x 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 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 9e603837f7ad886df62e02ac0cd395ec17b7d587)
[Bug tree-optimization/98474] [8/9/10 Regression] incorrect results using __uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98474 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 Known to work||11.0
[Bug tree-optimization/98474] [8/9/10 Regression] incorrect results using __uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98474 --- Comment #7 from Jeff Hurchalla --- Thanks for the info. After reading your comment and after reading the description of wide_int at the top of wide-int.h, the newly patched function wi::to_mpz() makes sense to me and it looks correct. I'm curious though why the particular constant from the original test case (_uint128_t a = ((__uint128_t) 1) << 65;) would have caused any trouble for wi::to_mpz prior to patching. My understanding of wide_int is that this particular constant in wide_int representation would not be sign-extended/compressed - i.e. len times HOST_BITS_PER_WIDE_INT would be greater than precision for this constant. During this test case, does niter analysis receive some other wide_int that was being incorrectly converted to mpz? It's not that important I expect, but it's all that's unclear to me.
[Bug tree-optimization/98474] [8/9/10 Regression] incorrect results using __uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98474 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |incorrect results using |incorrect results using |__uint128_t |__uint128_t --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
