I have now completed the following item: * 32 and 64 bit tuning for fft
This leaves: * 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 Bill. On 25 September 2012 17:02, Bill Hart <goodwillh...@googlemail.com> wrote: > 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.
