On Jan 4, 8:02 pm, Cactus <rieman...@googlemail.com> wrote: > On Jan 4, 6:56 pm, Bill Hart <goodwillh...@googlemail.com> wrote: > > > > > It looks like we have the following in mpir.h: > > > #if defined (_CRAY) && ! defined (_CRAYMPP) > > /* plain `int' is much faster (48 bits) */ > > #define __GMP_MP_SIZE_T_INT 1 > > typedef int mp_size_t; > > typedef int mp_exp_t; > > #else > > #define __GMP_MP_SIZE_T_INT 0 > > typedef long int mp_size_t; > > typedef long int mp_exp_t; > > #endif > > > So on most linux machines we'll have mp_size_t is a long. That is > > indeed the problem for Windows. I think it is safer to guard it to > > prevent any possibility of issues. I'm unsure what happens on Sparc. > > I will also have to add other options to __GMP_MP_SIZE_T_INT to set > the right follow on definitions in gmp-impl.h: > > #if __GMP_MP_SIZE_T_INT > #define MP_SIZE_T_MAX INT_MAX > #define MP_SIZE_T_MIN INT_MIN > #else > #define MP_SIZE_T_MAX LONG_MAX > #define MP_SIZE_T_MIN LONG_MIN > #endif > I have now tried this and, unfortunately, one test (mpz io_raw) fails when MPIR calls realloc with a current memory block of 8 bytes and a new block request of 1 byte.
It _ssems_ (I am not yet sure about this) that Windows doesn't bother to reallocate in this situation and MPIR sees this as an error. Brian -- 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.