On 5 October 2012 04:42, Case Van Horsen <cas...@gmail.com> wrote: > On Thu, Oct 4, 2012 at 7:36 PM, Case Van Horsen <cas...@gmail.com> wrote: >> On Thu, Oct 4, 2012 at 8:08 AM, Case Van Horsen <cas...@gmail.com> wrote: >>> On Thu, Oct 4, 2012 at 7:48 AM, Bill Hart <goodwillh...@googlemail.com> >>> wrote: >>>> I've gone through all the files and there are only the two extra >>>> symbols defined in mulfunc asm files which aren't provided by generic >>>> code. >>>> >>>> I also think we should be appending these #undefs on 64 bit as well. >>>> The reason is that we are removing the assembly files irrespective of >>>> ABI. >>>> >>>> So I think the following: >>>> >>>> if %ABI% == 32 (echo #undef HAVE_NATIVE_mpn_mod_1c >> ..\config.h) >>>> if %ABI% == 32 (echo #undef HAVE_NATIVE_mpn_divrem_1c >> ..\config.h) >>>> >>>> should be >>>> >>>> echo #undef HAVE_NATIVE_mpn_mod_1c >> ..\config.h >>>> echo #undef HAVE_NATIVE_mpn_divrem_1c >> ..\config.h >>>> echo #define HAVE_NATIVE_mpn_mod_1c 0 >> ..\config.h >>>> echo #define HAVE_NATIVE_mpn_divrem_1c 0 >> ..\config.h >>>> >>>> I am pretty sure we also need: >>>> >>>> echo #undef USE_PREINV_DIVREM_1 >> ..\config.h >>>> echo #define USE_PREINV_DIVREM_1 1 >> ..\config.h >>>> >>>> Case, do you want to try this out, and if it works on 32 and 64 bit >>>> builds, we'll call this problem fixed for now? Of course a more robust >>>> solution would grep the assembly files and see what symbols are >>>> available, etc. >> Just curious - why do you both #undef and #define to 0? Shouldn't >> #undef be sufficient? > Including the #define ... 0 lines causes errors. With the following, > all tests pass for 32-bit/pentium3, 32-bit/core2, 64-bit/K8, and > 64-bit/core2, and using both VS2008 and VS2010. > > > > echo #undef HAVE_NATIVE_mpn_mod_1c >> ..\config.h > echo #undef HAVE_NATIVE_mpn_divrem_1c >> ..\config.h > echo #define USE_PREINV_DIVREM_1 1 >> ..\config.h
Hmm, curious that the #define to 0 fails. I thought the tests were of the form #if rather than #ifdef. But I am happy if it works with the above three lines. It's late now, and I have meetings tomorrow, but I'll put up the alpha release as soon as I am able, probably tomorrow night. Everything else is done as far as I can tell. Brian, are you happy with everything? Bill. > > > Case > >> >> Case >>>> >>> I'll try that tonight. >>> Case >>>> Bill. >>>> >>>> On 4 October 2012 13:41, Bill Hart <goodwillh...@googlemail.com> wrote: >>>>> This should work, but we should actually be appending #undefs for all >>>>> the extra symbols in those files that get deleted (not for the ones >>>>> that get replaced by generics of course). >>>>> >>>>> This probably means going through each directory for each arch, >>>>> looking at the .asm files that are listed in make.bat (which get >>>>> deleted) and adding #undefs for all the extra symbols. >>>>> >>>>> Bill. >>>>> >>>>> On 4 October 2012 04:07, Case Van Horsen <cas...@gmail.com> wrote: >>>>>> On Wed, Oct 3, 2012 at 4:27 PM, Bill Hart <goodwillh...@googlemail.com> >>>>>> wrote: >>>>>>> Ah, I see. I'm slowly catching up. >>>>>>> >>>>>>> Perhaps the problem is that the .asm files don't all provide the same >>>>>>> symbols. Some may provide one of the symbols, others both. >>>>>>> >>>>>>> The general configure yoga in the *nix side of things culls all the >>>>>>> symbols to figure out which HAVE_NATIVE's to set probably. Because >>>>>>> this is hard to do on Windows, the complication is "avoided" by using >>>>>>> the generic files. >>>>>>> >>>>>>> I think the solution is to simply have make.bat purge the >>>>>>> HAVE_NATIVE_DIVREM_1c from the config.h file. This should always work. >>>>>>> In fact it is probably sufficient to simply append #undef >>>>>>> HAVE_NATIVE_DIVREM_1c and #define HAVE_NATIVE_DIVREM_1c 0 to the file. >>>>>>> >>>>>> >>>>>> You got it! I have attached a new make.bat file that appends the >>>>>> appropriate #undef's to the end of config.h. "make check" passes for a >>>>>> 64-bit/K8 build and a 32-bit/pentium3 build. >>>>>> >>>>>> Case >>>>>> >>>>>>> Bill. >>>>>>> >>>>>>> On 4 October 2012 00:22, Brian Gladman <b...@gladman.plus.com> wrote: >>>>>>>> -----Original Message----- From: Bill Hart >>>>>>>> Sent: Thursday, October 04, 2012 12:19 AM >>>>>>>> >>>>>>>> To: mpir-devel@googlegroups.com >>>>>>>> Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress >>>>>>>> >>>>>>>> In config.h which it says is generated by gen_config_h.bat, it has: >>>>>>>> >>>>>>>> #define HAVE_NATIVE_mpn_divrem_1c 1 >>>>>>>> >>>>>>>> This is why it is expecting to find that symbol. >>>>>>>> >>>>>>>> Because gen_config_h.bat is a *** Visual Studio build file *** that >>>>>>>> Jason >>>>>>>> 'borrowed'. >>>>>>>> >>>>>>>> And the Visual Studio build does provide this symbol. >>>>>>>> >>>>>>>> >>>>>>>> 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-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. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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. >>>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>>>> >>>> >>>> -- >>>> 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. >>>> > > -- > 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. > -- 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.
