Emmanuel Thomé emmanuel.thome at
Tue Oct 5 17:07:46 UTC 2021


You can use the mpn layer, which does not suffer from the same limitation.

Another option, if you're ok with having a bastardized GMP that breaks
the ABI, you can use the following patch, which makes mpz_t able to
cope with larger integers. The patch is against gmp-6.2.1. Note that
it's not a change that is desired in general, since the overhead for
small integers can't be neglected. But it's a quick enough fix. I've
successfully used this to bench multiplication times for 2^40-bit

And again, this breaks the ABI, so you should very much know what
you're doing, and not install such a library in /usr ; you've been



On Tue, Oct 5, 2021 at 9:13 AM Tomás Oliveira e Silva <tos at> wrote:
> I very recently did a computation requiring integers of potentially
> extreme large size using gmp 6.2.1.
> Unfortunately, the program was terminated early due to overflow in the
> mpz type.
> Reading the 6.2.1 documentation (page 18, version 6.2.1) I was expecting
> the number of limbs to be stored in a field of type mp_size_t.
> To my surprise that is not so. In gmp.h (and both _mp_alloc
> and _mp_size are plain integers (int data type).
> That probably makes it much harder for someone without intimate
> knowledge of the inner workings of the library to compile a custom
> version of the library where those fields are longs, and, more
> importantly, to have confidence that the now long sizes are handled
> correctly in all places.
> Any ideas about to address this particular problem? For my problem,
> 2^{31}-1 limbs are not enough...
> --
> _______________________________________________
> gmp-discuss mailing list
> gmp-discuss at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enterprise_gmp.patch
Type: text/x-patch
Size: 2435 bytes
Desc: not available
URL: <>

More information about the gmp-discuss mailing list