https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98474
--- Comment #7 from Jeff Hurchalla <jeffhurchalla at gmail dot com> --- 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.
