I have now removed all the old fft tuning parameters from the gmp-mparam.h files.
By my reckoning, the issues that remain for a release are at the bottom of this email. I propose releasing an alpha *before* fixing the mingw issue. I would *really* appreciate some help with the Mingw32 issue. What we need to do is bisect the repo (svn trunk) and rebuild mpir until we find out which commit caused mingw32 to stop working. It might only be necessary to run configure and check to see if config.h has been populated correctly with all the HAVE_NATIVE flags, which would save a lot of time. If anyone would like to help with this, I would most appreciate the help at this time. Bill. Release TODO: =========== 32 and 64 bit tuning for fft t-next_likely_prime undefined reference to abort and exit fft_combine_bits const warning (see below) ../mpn/generic/gcdext.c:238: warning: integer overflow in expression _mp_release_macro volker braun reported tuning problems with fft cutoffs mingw32 build issue, svn bisection make tune on platforms we have access to update version numbers release paperwork const warning: ============== In file included from mul_truncate_sqrt2.c:2: ../fft/mul_truncate_sqrt2.c: In function â__gmpn_mul_truncate_sqrt2â: ../fft/mul_truncate_sqrt2.c:113: warning: passing argument 2 of â__fft_combine_bitsâ from incompatible pointer type ../mpir.h:1860: note: expected âconst mp_limb_t **â but argument is of type âmp_limb_t **â On 9 August 2012 01:43, Bill Hart <goodwillh...@googlemail.com> wrote: > On 8 August 2012 15:57, Sisyphus <sisyph...@optusnet.com.au> wrote: >> >> ----- Original Message ----- From: "Bill Hart" <goodwillh...@googlemail.com> >> To: <mpir-devel@googlegroups.com> >> Sent: Wednesday, August 08, 2012 10:59 PM >> >> Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress >> >> >>> I was building against trunk in svn. *But* I have just realised you >>> were using MinGW64. I was using Linux 64 bit. >>> >>> I will try MinGW64 later and probably hit the same problem. >> >> >> Why would it work for Linux64 bit, but not MinGW64 ? > > I honestly don't know. Autocrap probably. > >> >> >>> Either way, this is a MinGW64, or possibly a Windows problem, not a >>> *nix problem as such. So I would appreciate any help/guidance on what >>> actually needs to be done. >>> >>> Are these _Decimal64 functions documented in the GMP manual? If so, >>> then we'd need to replicate them in MPIR to remain compatible. If not, >>> then MPFR shouldn't rely on them for an MPIR build. >> >> >> I don't think gmp knows anything at all about the _Decimal64 type. It's only >> mpfr that has any interaction at all with the _Decimal64. >> It looks like the mpfr-3.1.1 source utilises some of gmp's bit field packing >> structures (union ieee_double_extract) in order to handle the conversion >> between mpfr_t and _Decimal64. > > Ok, thanks for the information. That could be helpful. > > Bill. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@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.
