Urgh. So I don't know whether it will be Friday or Saturday. A final decision apparently hasn't been made.
On 26 July 2012 22:34, Bill Hart <goodwillh...@googlemail.com> wrote: > svn doesn't do merges by diffing the branches. It has to replay the > commits from trunk over the top of mpir-exp in the correct order, > starting with the state of mpir-exp at the point the branch was made. > At least that is how I think it does it. > > So some of those C's are "create", others "conflict", depending on > which column they are in, I think. The number of actual conflicts is > listed at the bottom. > > My schedule got rearranged about 10 mins ago, and I will now be > attempting the update of mpir-exp tomorrow night instead of Saturday. > I will be unavailable Saturday. > > Bill. > > On 26 July 2012 22:22, Brian Gladman <b...@gladman.plus.com> wrote: >> -----Original Message----- From: Bill Hart >> Sent: Thursday, July 26, 2012 9:48 PM >> To: mpir-devel >> Subject: [mpir-devel] Re: MPIR 2.6 release progress >> >> >> The first stage of merging mpir-exp back into trunk is to "bring your >> branch in sync with the trunk again, just as you've been doing all >> along". >> >> [wbhart@eno mpir-exp]$ svn merge --dry-run ^/mpir/trunk >> --- Merging r3747 through r3925 into '.': >> U Makefile.in >> U cpuid.c >> >> C new_fft_with_flint.c >> C new_fft.c >> =========== >> these can be deleted in trunk >> >> >> C mpn/x86_64w/bobcat/redc_1.asm >> C mpn/x86_64w/bobcat/mul_1.asm >> C mpn/x86_64w/bobcat/mul_basecase.asm >> C mpn/x86_64w/bobcat/sqr_basecase.asm >> C mpn/x86_64w/sandybridge/redc_1.asm >> C mpn/x86_64w/sandybridge/mul_1.asm >> C mpn/x86_64w/sandybridge/mul_basecase.asm >> C mpn/x86_64w/sandybridge/sqr_basecase.asm >> C mpn/x86_64w/atom/mul_1.asm >> C mpn/x86_64w/atom/mul_basecase.asm >> C mpn/x86_64w/atom/sqr_basecase.asm >> C mpn/x86_64w/netburst/mul_1.asm >> C mpn/x86_64w/netburst/mul_basecase.asm >> C mpn/x86_64w/netburst/sqr_basecase.asm >> =========== >> The above compare as identical when comparing trunk with mpir-exp so I am >> not sure why there are conflicts >> >> >> U mpn/x86_64w/fat/fat_entry.asm >> U mpn/powerpc64/gmp-mparam.h >> U mpn/x86_64/k8/karasub.asm >> U mpn/x86_64/k8/k10/karasub.asm >> U mpn/x86_64/bobcat/karasub.asm >> A mpn/x86_64/bobcat/redc_1.as >> U mpn/x86_64/sandybridge/karasub.asm >> A mpn/x86_64/sandybridge/redc_1.as >> U mpn/x86_64/atom/karasub.asm >> U mpn/x86_64/netburst/karasub.asm >> U mpn/x86_64/nehalem/karasub.asm >> U mpn/x86_64/core2/karasub.asm >> =========== >> Not sure here >> >> >> C mpn/generic/subadd_n.c >> C mpn/generic/redc_2.c >> C mpn/generic/addadd_n.c >> U mpn/generic/hgcd.c >> C mpn/generic/sumdiff_n.c >> C mpn/generic/addsub_n.c >> U mpn/generic/gcdext_subdiv_step.c >> =========== >> Several of these compare identical in the two branches so how can they be in >> conflict? The others have only minor differences. >> >> >> C mpn/x86w/p3/cfg.h >> C mpn/x86w/p4/cfg.h >> U mpn/asm-defs.m4 >> U devel/setversion >> U doc/mpir.info-1 >> U doc/mpir.texi >> U doc/mpir.info-2 >> U doc/mpir.info >> U doc/stamp-vti >> U doc/version.texi >> U config.in >> U NEWS >> U configure.in >> =========== >> Don't know about these >> >> C build.vc10/mpir_config.py >> =========== >> This one is identical except for one line where the string 'fft' has been >> added. >> >> >> C build.vc10/lib_mpir_nehalem/lib_mpir_nehalem.vcxproj >> C build.vc10/lib_mpir_nehalem/lib_mpir_nehalem.vcxproj.filters >> C build.vc10/lib >> C build.vc10/dll >> C build.vc10/dll_mpir_nehalem/dll_mpir_nehalem.vcxproj >> C build.vc10/dll_mpir_nehalem/dll_mpir_nehalem.vcxproj.filters >> C build.vc10/lib_mpir_p0/lib_mpir_p0.vcxproj >> C build.vc10/lib_mpir_p0/lib_mpir_p0.vcxproj.filters >> C build.vc10/lib_mpir_p3/lib_mpir_p3.vcxproj.filters >> C build.vc10/lib_mpir_p3/lib_mpir_p3.vcxproj >> C build.vc10/lib_mpir_p4/lib_mpir_p4.vcxproj.filters >> C build.vc10/lib_mpir_p4/lib_mpir_p4.vcxproj >> U build.vc10/mpir-tests.sln >> C build.vc10/dll_mpir_k8/dll_mpir_k8.vcxproj.filters >> C build.vc10/dll_mpir_k8/dll_mpir_k8.vcxproj >> C build.vc10/lib_mpir_gc/lib_mpir_gc.vcxproj >> C build.vc10/lib_mpir_gc/lib_mpir_gc.vcxproj.filters >> C build.vc10/lib_mpir_cxx/lib_mpir_cxx.vcxproj >> C build.vc10/lib_mpir_core2/lib_mpir_core2.vcxproj >> C build.vc10/lib_mpir_core2/lib_mpir_core2.vcxproj.filters >> C build.vc10/dll_mpir_core2/dll_mpir_core2.vcxproj >> C build.vc10/dll_mpir_core2/dll_mpir_core2.vcxproj.filters >> C build.vc10/lib_mpir_k8/lib_mpir_k8.vcxproj.filters >> C build.vc10/lib_mpir_k8/lib_mpir_k8.vcxproj >> C build.vc10/dll_mpir_p0/dll_mpir_p0.vcxproj.filters >> C build.vc10/dll_mpir_p0/dll_mpir_p0.vcxproj >> C build.vc10/dll_mpir_p3/dll_mpir_p3.vcxproj.filters >> C build.vc10/dll_mpir_p3/dll_mpir_p3.vcxproj >> C build.vc10/dll_mpir_p4/dll_mpir_p4.vcxproj >> C build.vc10/dll_mpir_p4/dll_mpir_p4.vcxproj.filters >> C build.vc10/lib_mpir_k10/lib_mpir_k10.vcxproj >> U build.vc10/lib_mpir_k10/lib_mpir_k10.vcxproj.filters >> C build.vc10/dll_mpir_gc/dll_mpir_gc.vcxproj >> C build.vc10/dll_mpir_gc/dll_mpir_gc.vcxproj.filters >> C build.vc10/dll_mpir_k10/dll_mpir_k10.vcxproj >> U build.vc10/dll_mpir_k10/dll_mpir_k10.vcxproj.filters >> =========== >> I can sort all the VC++ files after the merge by regenerating them. In any >> event most of these VC++ builds will not be part of the next release because >> the user will be able to use mpir_config.py to generate the VC++ build files >> for themselves. >> >> >> >> U configure >> U tests/mpn/t-addadd_n.c >> U tests/mpn/t-addsub_n.c >> U tests/mpn/t-subadd_n.c >> U tests/devel/try.c >> U gmp-h.in >> U acinclude.m4 >> U Makefile.am >> Summary of conflicts: >> Text conflicts: 47 >> Tree conflicts: 10 >> >> Ouch, what a mess! It looks like many changes have been made to trunk >> without ever merging them into mpir-exp. >> >> The second step will be the reintegration merge of mpir-exp back into >> trunk. I daren't even do a dry-run of that until we pluck up the >> courage to bring mpir-exp up-to-date! >> >> =========== >> I really don't understand most of the supposed conflicts - are we have >> LF/CRLF problems? >> >> Brian >> >> >> Bill. >> >> On 26 July 2012 21:35, Bill Hart <goodwillh...@googlemail.com> wrote: >>> >>> I have now done the autotools update for the mpir-exp branch and >>> committed to svn. Everything again builds and passes on *nix. >>> >>> This brings us to the following list for this release: >>> >>> * merge with trunk >>> * tuneup fails on mpir-exp branch >>> * mpir build fails on MinGW due to mpn_addmul_2 symbol defined twice Pavel >>> * mpz_powm_ui doc says -ve exponent supported, which is rubbish >>> * fix flint bugs in primality testing code >>> * 32 and 64 bit tuning for fft >>> * make sure the redc_2 include bug is fixed in trunk >>> * remove old FFT tuning code and tuning params >>> * Add t-get_ux compiler bug to list of known issues on website >>> >>> The first three are the most significant, the remainder being >>> essentially trivial. I will try to look at one of them tomorrow or >>> Saturday. >>> >>> I will try a dry-run of the merge with trunk right now and report back. >>> >>> The following will be left for the next release, or until someone else >>> can do it: >>> >>> * generic build option for sage >>> >>> Bill. >>> >>> On 19 July 2012 20:53, Bill Hart <goodwillh...@googlemail.com> wrote: >>>> >>>> (I've put Jason in CC in the hope that he will see this soon.) >>>> >>>> The FFT assert issue was with the old FFT, so this doesn't need >>>> fixing. That brings the list down to: >>>> >>>> * tuneup fails on mpir-exp branch >>>> * generic build option for sage >>>> * mpir build fails on MinGW due to mpn_addmul_2 symbol defined twice >>>> Pavel >>>> * mpz_powm_ui doc says -ve exponent supported, which is rubbish >>>> * fix flint bugs in primality testing code >>>> * 32 and 64 bit tuning for fft >>>> * make sure the redc_2 include bug is fixed in trunk >>>> * set up autotools to recognize new mpn/generic/mulmod_bexpp1.c file >>>> * remove old FFT tuning code and tuning params >>>> * Add t-get_ux compiler bug to list of known issues on website >>>> >>>> Unfortunately, things have ground to a halt until someone can do the >>>> autotools update for the new file Brian just added >>>> mpn/generic/mulmod_bexpp1.c. I've tried multiple ways of making >>>> autotools cooperate on my machine, and no luck. Until this is fixed, I >>>> can't build the latest revision of the mpir-exp branch. >>>> >>>> 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. >> >> >> >> -- >> 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.
