On 2020-09-21 18:16:15 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre <vinc...@vinc17.net> writes:
>
> So the overflow occurs in "mpz_add_ui (z, z, 1);", though this
> operation doesn't need a larger mpz_t and could even be done
> in place: no carry occurs here, and note that a carry for a
> huge number is very unlikely to occur.
>
> No bug. You're (presumably deliberately) dancing on the edge of mpz
> overflow. The overflow detection flags some false positives, which is
> by design.
This is not properly documented, then. The manual says:
'mpz_add_ui', 'mpz_sub_ui', 'mpf_add_ui' and 'mpf_sub_ui' benefit
from an in-place operation like 'mpz_add_ui(x,x,y)', since usually
^^^^^^^^^^^^^^^^^^
only one or two limbs of 'x' will need to be changed. The same
applies to the full precision 'mpz_add' etc if 'y' is small. If
'y' is big then cache locality may be helped, but that's all.
Since this should be an in-place operation (as there is no carry),
an overflow is unexpected here.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
_______________________________________________
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
