On Jan 4, 6:38 pm, Bill Hart <goodwillh...@googlemail.com> wrote: > If it is the latter then here is the relevant code: > > wsize = usize + vsize; > > ..... > > if (wp == up || wp == vp) > { > free_me = wp; > free_me_size = w->_mp_alloc; > } > else > (*__gmp_free_func) (wp, w->_mp_alloc * BYTES_PER_MP_LIMB); > > w->_mp_alloc = wsize; > wp = (mp_ptr) (*__gmp_allocate_func) (wsize * BYTES_PER_MP_LIMB); > w->_mp_d = wp; > > Which shows that the only things that can go wrong are: > > 1) BYTES_PER_MP_LIMB is not 4 > > or > > 2) something is wrong with __gmp_allocate_func > > The latter is given by the following code: > > void * (*__gmp_allocate_func) _PROTO ((size_t)) = __gmp_default_allocate; > > void * > __gmp_default_allocate (size_t size) > { > void *ret; > #ifdef DEBUG > size_t req_size = size; > size += 2 * BYTES_PER_MP_LIMB; > #endif > ret = malloc (size); > if (ret == 0) > { > fprintf (stderr, "GNU MP: Cannot allocate memory (size=%u)\n", size); > abort (); > } > .... > > which is where your message is coming from. But malloc is clearly > being fed the right value. > > To check if the temporary allocation made by the FFT is correct is > slightly more work.... > > Bill. > > 2010/1/4 Bill Hart <goodwillh...@googlemail.com>: > > > This would be using the FFT. And the FFT should in theory require 4 > > times the input bit size in order to do the squaring. So to multiply > > integers of 2^31 bits, it will request 2^30 bytes of memory. This is > > all assuming that the FFT is written to use memory fairly efficiently. > > This is in addition to the amount of memory required for the input and > > output, which will be a total of 2^31 bits plus 2^32 bits. That makes > > a total of just below 8 times the input size, or 2^31 bytes. > > > It's possible to reduce the FFT memory usage a little below that in > > theory, but not much. > > > Or are you saying that the number of bytes allocated in the actual > > output mpz_t is the amount given there? > > > Bill. > > > 2010/1/4 Cactus <rieman...@googlemail.com>: > > >> On Jan 4, 2:43 pm, Bill Hart <goodwillh...@googlemail.com> wrote: > >>> uintptr_t is a c99 feature. So it "exists" on linux, but formally only > >>> in c99 mode. I'm not keen to switch MPIR to c99. But we can define > >>> something in mpir.h which on Windows in uintptr_t and on linux is the > >>> same size as an mp_limb_t or whatever (I think it is the case that an > >>> mp_limb_t should always be the same size as a pointer on the systems > >>> we care about). > > >> If I square numbers of increasin sizes, I get the output: > > >> 26 134217724 > >> 27 268435456 > >> 28 536870911 > >> 29 1073741821 > >> 30 2147483645 > >> GNU MP: Cannot allocate memory (size=4294837280) > > >> The number on the left is log2(number of bits in the input), the > >> number on the right being the number of bits in the result. > > >> As can be seen it fails for 2^31 input bits because memory for 2^32 > >> _bytes_ cannot be allocated. > > >> So it is asking for a lot more memory than its should need. > > >> mpz_mul asks for memory through the call: > > >> void *_mpz_realloc (mpz_ptr m, mp_size_t new_alloc) > > >> and mp_size_t is defined to be an int in gmp-impl.h: > > >> typedef long int mp_size_t; > > >> This is 32-bits on Windows so the realloc call will fail as soon as > >> 2^32 bytes are asked for. > > >> The define: > > >> typedef size_t mp_size_t; > > >> would seem to be better here. > > >> But this doesn't explain the excess memory request. > > >> Brian
This macro (and similar ones) is used in #define __GMP_REALLOCATE_FUNC_LIMBS(p, old_size, new_size) is used in void * _mpz_realloc (mpz_ptr m, mp_size_t new_alloc) where the arguments to the macro are mp_size_t ints that are 32-bits on Windows. So when the limb number request is above 2^32 / 2^8 = 2^24, the allocation will overflow even though the receiving variable is a size_t. It seems clear to me that I need to define mp_size_t as a type that is 32-bits on win32 and 64-bits on x64: typedef size_t mp_size_t; Is this going to mess up Linux/GCC? If so I can guard it with an _MSC_VER guard. Brian #define -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.