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