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 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.
