On Jan 8, 5:19 pm, Cactus <rieman...@googlemail.com> wrote: > The change to mp_size_t and mp_exp_t on WIndows to use a 64-bit long > long type seems to be incompatible with MPFR. > > After accounting for the addition of a __GMP_MP_SIZE_T_INT value of 2, > the following MPFR assertion fails: > > ..\..\init2.c:42: MPFR assertion failed: > ((mp_exp_t)((~((~(unsigned int)0)>>1))+2)) == (((-2147483647L - > 1))+2) > > This is the the following macro: > > /* Check for correct EXP NAN, ZERO & INF in both mpfr.h and in mpfr- > impl.h */ > MPFR_ASSERTN( __MPFR_EXP_NAN == MPFR_EXP_NAN ); > > which can be tracked to: > > #if __GMP_MP_SIZE_T_INT > #define __MPFR_EXP_NAN ((mp_exp_t)((~((~(unsigned int)0)>>1))+2)) > #else > #define __MPFR_EXP_NAN ((mp_exp_t)((~((~(unsigned long)0)>>1))+2)) > #endif > > and: > > # define MPFR_EXP_NAN (MPFR_EXP_MIN+2) > > I haven't much of a clue what is going on but we don't want a release > that doesn't support MPFR.
Unfortunately MPFR depends on mp_size_t, mp_exp_t and __GMP_MP_SIZE_T_INT in quite a few palces so MPFR is not going to work with MPIR unless we either revert to a 32-bit type for these types or the MPFR team makes changes to accomodate our changes to MPIR in thsi regard. So we have to decide what to do: 1) revert to 32-bit types and give up huge integer values 2) request changes to MPFR to accomadate our needed MPIR changes. ANy view on whiich way to go? 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.