MPIR 2.6 release progress

[Bill Hart]

Hi all,

we are currently working on the MPIR 2.6 release. The main new features are:

* new Windows 64 functionality (due to Brian Gladman)
* new FFT (due to William Hart)

The code has been developed on a separate branch, mpir-exp
(http://boxen.math.washington.edu/svn/mpir/mpir/branches/mpir-exp in
svn repo).

Here is the remaining list of things to do:

* 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
* Vlad report of MinGW sandybridge combination with FFT assert failure
* Chris report of mpz_get_ux failure on Itanium
* 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

Regarding the last item, Jason, would you be able to do the autoconf
stuff for this. My autotools is out-of-date and our system won't allow
us to install a more recent version (autotools fanboys observe --
autotools sucks once again).

Regarding the mpz_get_ux bug on Itanium, this fails on many
architectures, due to a common gcc bug. Jason wanted to set up a test
to reject all such broken compilers, but the test has to be run after
the test for stdint.h which isn't possible. So it is not possible to
reject such compilers. Which is probably just as well, as they are
extremely common. So we will just have to stick with the failing test.
Nothing we can do about it apparently. We'll add it to the long list
of known issues about which we can do nothing.

Bill.

[Bill Hart]

I can confirm that t-get_ux passes on an Itanium with a working
compiler. So it is definitely not an MPIR bug, as Jason found.

We also had failures on a solaris machine and gcc70 for the same test.

Bill.

[Bill Hart]

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

[Cactus]

We are probably ready to merge the MPIR-EXP branch into trunk but this will mean that there will be a (hopefully) short period during which the trunk won't build correctly.

 

To minimise this period, it will be necessary to coordinate changes to the source code and to Windows Visual Studio build, the Windows command line build and the *nix/GCC builds.  

 

There are quite a large number of new C files involved and many new tests for the new FFT. I can provide information about the differences between the trunk and the MPIR-EXP branch if this will help in making these changes.  

 

I assume that Jason will need to look at the Windows command line build after the merge.  Are you in a position to update this build if I now do this merge, Jason?  Or is it likely to pick up the changes without any manual action on your part?

  

          Brian 

[Case Van Horsen]

If you're interested, I have a modified command line build that worked
with mpir-exp a while ago. I can update it after the merge.

The batch files also support the selection of a specific version of VS
or the MS SDK compilers.

Case
>
> Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mpir-devel/-/dc-tkjET1dIJ.
>
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to
> mpir-devel+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.

[Brian Gladman]

-----Original Message-----
From: Case Van Horsen
Sent: Friday, July 20, 2012 9:07 AM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

On Fri, Jul 20, 2012 at 12:58 AM, Cactus <riem...@gmail.com> wrote:
>
>> We are probably ready to merge the MPIR-EXP branch into trunk but this
>> will mean that there will be a (hopefully) short period during which the
>> trunk won't build correctly.
>>
>> To minimise this period, it will be necessary to coordinate changes to
>> the
>> source code and to Windows Visual Studio build, the Windows command line
>> build and the *nix/GCC builds.
>>
>> There are quite a large number of new C files involved and many new tests
>> for the new FFT. I can provide information about the differences between
>> the
>> trunk and the MPIR-EXP branch if this will help in making these changes.
>>
>> I assume that Jason will need to look at the Windows command line build
>> after the merge. Are you in a position to update this build if I now do
>> this merge, Jason? Or is it likely to pick up the changes without any
>> manual action on your part?

If you're interested, I have a modified command line build that worked
with mpir-exp a while ago. I can update it after the merge.

===============
If you are willing to get the Windows command line build working after the
merge, that would be a great help as I am not sure that Jason has the time
to do this right now.

I think Bill will be happy to take on the *nix/GCC build changes but he
needs some help with autotools to do this. Again we may need a volunteer
to help with this if Jason is not in a position to take it on.

Brian

[Bill Hart]

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.

[Bill Hart]

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
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
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
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
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
C build.vc10/mpir_config.py
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
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!

Bill.

[Brian Gladman]

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

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

--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.

[Bill Hart]

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.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Thursday, July 26, 2012 10:34 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

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.

====================================
I think it will be far easier to move the changes in the mpir-exp branch
into trunk manually.

I can do this tomorrow if you have time to assist with it in case I run into
any issues.

Brian

[Bill Hart]

Urgh. So I don't know whether it will be Friday or Saturday. A final
decision apparently hasn't been made.

[Bill Hart]

Doing things manually risks overwriting changes that have been made in
trunk and may be error prone. We'd also lose the original commit data.

I don't like the idea of doing it without a proper merge.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart

Sent: Thursday, July 26, 2012 10:39 PM
To: mpir-...@googlegroups.com

Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

Urgh. So I don't know whether it will be Friday or Saturday. A final
decision apparently hasn't been made.

=======================
After tomorrow, I can't do anything until Monday as I have relatives
visiting over the weekend.

Brian

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Thursday, July 26, 2012 10:40 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

Doing things manually risks overwriting changes that have been made in
trunk and may be error prone. We'd also lose the original commit data.

I don't like the idea of doing it without a proper merge.

==================
The risks are minimal but I am happy to see what happens in a real merge
from trunk into mpir-exp and then from mpir-exp back into trunk if that is
what you want to do.

Brian

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Thursday, July 26, 2012 10:40 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

Doing things manually risks overwriting changes that have been made in
trunk and may be error prone. We'd also lose the original commit data.

I don't like the idea of doing it without a proper merge.

===========================================
Ok, I have done the merge from trunk to mpir-exp.

I am now going to test it on Windows. Do you want to test it on *nix before
the merge from exp into trunk?

I am going to try to complete these merges today if I can as I don't have
any time for this over the weekend.

So if you DON'T wan't the exp -> trunk merge done before you check the
merged exp branch on *nix please say so!

Brian

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Thursday, July 26, 2012 10:40 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

Doing things manually risks overwriting changes that have been made in
trunk and may be error prone. We'd also lose the original commit data.

I don't like the idea of doing it without a proper merge.

=================================
I have done the merge from trunk into the mpir-exp branch and all is well on
Windows.

Most of the stuff that SVN reported was spurious as far as I can see.

But we now have a potentially nasty problem - in testing the merge from
MPIR-EXP into trunk, I get the message:

Error: Querying mergeinfo requires version 3 of the FSFS filesystem schema;
filesystem
Error: '/home/mpir/svn_repos/mpir/db' uses only version 2

On googling, I find that solving this problem seems to require a Subversion
upgrade on the server followed by a repository dump and reload.

If we cannot organise this upgrade (which I assume won't be easy or quick
since there are likely to be many SVN users impacted by it), we will have to
revert to adding the changes in MPIR-EXP to the trunk manually as I
suggested yesterday.

What is your view on this Bill?

Brian

[Brian Gladman]

====================================
I have now figured out how to the merge without mergeinfo and I have merged
the mpir-exp branch into the trunk.

The Windows Visual Studio builds are working so I would much appreciate it
if Case can look at the Windows command line build and Bill can look at the
*nix builds to see if anything needs doing.

Brian

[Bill Hart]

Unfortunately the merge doesn't seem to have gone without issue. When
I try to build on linux now it configures ok, but I get the following
when it tries to link the mpn archive during the build:

mpn/.libs/preinv_divrem_1.o: In function `__gmpn_preinv_divrem_1':
preinv_divrem_1.c:(.text+0x0): multiple definition of `__gmpn_preinv_divrem_1'
mpn/.libs/divrem_euclidean_qr_1.o:divrem_euclidean_qr_1.as:(.text+0x0):
first defined here
mpn/.libs/addmul_2.o: In function `mpn_addmul_2':
addmul_2.as:(.text+0x0): multiple definition of `__gmpn_addmul_2'
mpn/.libs/redc_2.o:redc_2.c:(.text+0x0): first defined here
collect2: ld returned 1 exit status
make[2]: *** [libmpir.la] Error 1
make[2]: Leaving directory `/home/wbhart/mpir-new'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/wbhart/mpir-new'
make: *** [all] Error 2

There's no obvious reason for this, other than non-commuting patches
which have maybe screwed up a makefile or something. I'll try running
autoconf and automake again and see if it sorts itself out.

Bill.

[Bill Hart]

In fact, the problem already occurs in the mpir-exp branch. So this
must be the result of a merge conflict from trunk to mpir-exp.

Bill.

[Bill Hart]

Nope, autoconf and automake didn't do anything.

The problem must lie in one of the following files:

U Makefile.in
U cpuid.c

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

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

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

U .

In fact, the issue seems to occur at the final linking stage, not when
linking the mpn archive.

Bill.

[Bill Hart]

By a process of elimination, this problem occurs on both core2 and
k10, so it must be one of the following:

U cpuid.c
U mpn/x86_64/k8/k10/karasub.asm
U mpn/x86_64/core2/karasub.asm
U mpn/asm-defs.m4
U config.in
U configure.in

U gmp-h.in
U acinclude.m4
U Makefile.am

But we can exclude acinclude.m4 as this was the test for a broken gcc
4.3.2, which is not relevant.

We can exclude cpuid.c as this is cpu detection for sandybridge and atom.

We can exclude the karasub.asm files as these just define new versions
of karatsuba.

That leaves:

U mpn/asm-defs.m4
U config.in
U configure.in
U gmp-h.in
U Makefile.am

Looking through, this change in configure.in looks suspicious:

- sed -n 's/[^G]*GLOBAL_FUNC[:space:]*\(.*\)/\1/p' $tmp_file
+ sed -n 's/^;[ ]*PROLOGUE(\([^,]*\).*)/\1/p' $tmp_file ;

It looks like all the yasm files use GLOBAL_FUNC and all the gas files
use PROLOGUE, so I don't completely understand this change. It might
be correct.

Most of the other files that have changed have changes to something
relating to redc_2, which does show up in the error message. But it
can't explain both problems.

Anyhow, going back to the original error message, there is a file
mpn/generic/preinv_divrem_1.c which defines a symbol
mpn_preinv_divrem_1, which is guarded with:

#if USE_PREINV_DIVREM_1

But then we have:

[wbhart@eno mpir-exp]$ grep GLOBAL_FUNC mpn/divrem_euclidean_qr_1.as
GLOBAL_FUNC mpn_preinv_divrem_1
GLOBAL_FUNC mpn_divrem_euclidean_qr_1

In mpn/generic/redc_2.c we have:

#ifndef HAVE_NATIVE_mpn_addmul_2
mp_limb_t
mpn_addmul_2 (mp_ptr rp, mp_srcptr up, mp_size_t n, mp_srcptr vp)
{
rp[n] = mpn_addmul_1 (rp, up, n, vp[0]);
return mpn_addmul_1 (rp + 1, up, n, vp[1]);
}
#endif

But then we have:

[wbhart@eno mpir-exp]$ grep GLOBAL_FUNC mpn/addmul_2.as
GLOBAL_FUNC mpn_addmul_2

So it looks to me like this fix in configure.in is correct, but it
causes two other bugs (symbols defined when they shouldn't be) to show
up.

So we need to figure out how to set USE_PREINV_DIVREM_1 to 0 when it
is supposed to be and to define HAVE_NATIVE_mpn_addmul_2 when it is
supposed to be.

This is where we need Jason to jump in and say he knows how to fix the
problem....

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Saturday, July 28, 2012 1:52 AM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

By a process of elimination, this problem occurs on both core2 and
k10, so it must be one of the following:

U cpuid.c
U mpn/x86_64/k8/k10/karasub.asm
U mpn/x86_64/core2/karasub.asm
U mpn/asm-defs.m4
U config.in
U configure.in
U gmp-h.in
U acinclude.m4
U Makefile.am

==================================
I am a bit puzzled about the changes to the karasub subroutines since the
merge should have taken these from trunk.

I thought that I had watched for that but its possible that I missed some of
the assembler versions.

It would be worth checking this.

Brian

[Bill Hart]

Well, I was right to be suspicious of the following change:

- sed -n 's/[^G]*GLOBAL_FUNC[:space:]*\(.*\)/\1/p' $tmp_file
+ sed -n 's/^;[ ]*PROLOGUE(\([^,]*\).*)/\1/p' $tmp_file ;

I still don't understand what was intended here. I think the idea was
to give an alternative sed script for ripping PROLOGUE declarations,
probably due to some incompatibility on some systems. But instead of
adding the line it appears to have been written over the top of the
GLOBAL_FUNC line, which is definitely needed.

Adding it back in causes mpir to build correctly and pass its tests on
linux. This probably also fixes the issues we were having with MinGW
on the mpir-exp branch.

Bill.

[Bill Hart]

I have now fixed the main big item left for release, namely fixing
tuneup to give crossovers for the new fft.

However, in doing this I discovered that tuneup causes a double free
when tuning DC_BDIV_QR_THRESHOLD, so this will have to be fixed.

I have not added tuning code for the mpn_mulmod_Bexpp1 function. That
can get done in the next release.

I also noted that the name of the file fft/fft_negacyclic is
misspelled. This can't just be changed as everywhere it is referred to
by autotools also needs changing. Someone could volunteer to do the
easy fix, except that they would need access to a very specific
version of autotools. I'll add it to the list of things to be done
(either this release or the next).

Bill.

[Bill Hart]

I fixed the bug in tuneup. So here is the list of items for release now:

todo:
==========

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

interface for mpn_mulmod_2expp1

32 and 64 bit tuning for fft

remove old fft tuning params
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

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 **â

Done:
=====
remove old fft tuning code
add new fft crossover code to tuneup

tuneup fails on mpir-exp branch

Wont Fix:
=========
Vlad report of MinGW sandybridge combination with FFT assert failure -
new fft fixes this
Chris report of mpz_get_ux failure on Itanium - this is a compiler bug

Next Release:
=============

generic build option for sage

proper tuning code for mpn_mul_Bexpp1_fft
fft/fft_negacyclic.c is misspelled
move fft_tuning.c into tuneup

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Wednesday, August 08, 2012 7:38 AM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

I fixed the bug in tuneup. So here is the list of items for release now:

todo:
==========
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
interface for mpn_mulmod_2expp1
32 and 64 bit tuning for fft
remove old fft tuning params
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

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 **�

Done:
=====
remove old fft tuning code
add new fft crossover code to tuneup
tuneup fails on mpir-exp branch

Wont Fix:
=========
Vlad report of MinGW sandybridge combination with FFT assert failure -
new fft fixes this
Chris report of mpz_get_ux failure on Itanium - this is a compiler bug

Next Release:
=============
generic build option for sage
proper tuning code for mpn_mul_Bexpp1_fft
fft/fft_negacyclic.c is misspelled
move fft_tuning.c into tuneup

=============================
Great to see the progress you are making Bill.

I think there are a few further issues that need resolving:

1. The windows command line build needs testing and, possibly, correcting.
I think Case volunteered to do this (can you do this Case?)

2. Rob reported that support for _Decimal64 is now a GMP feature that MPIR
doesn't offer in GMP compatibility mode on mingw/mingw64. We need a
volunteer to add this or it needs to go onto the todo list for the next
release.

3. Now that the Python build generator for Visual Studio builds is robust,
I intend to deliver the Visual Studio build solution with fewer initial
build options since the user can add those that they need. I would like to
offer win32 and x64 builds for both static libraries and DLLS for: (a)
generic C, and (b) an assembler version that works on all x64 enables
processors.

Does anyone have any advice on which existing assembler version meets
requirement (b)? That is, which of the existing assembler builds can serve
as a generic assembler build for all Intel/AMD processors that can run
Windows x64?

[Bill Hart]

Currently MinGW doesn't build.

The error message is as follows:

libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I
.. -DOPERATION_divisible_p -m32 -O2 -fomit-frame-pointer -mtune=corei7 -march=co
rei7 -c divisible_p.c -o divisible_p.o
divisible_p.c: In function '__gmpn_divisible_p':
divisible_p.c:76:3: error: 'TMP_DECL' undeclared (first use in this function)
divisible_p.c:76:3: note: each undeclared identifier is reported only once for e
ach function it appears in
divisible_p.c:141:3: error: 'TMP_MARK' undeclared (first use in this function)
divisible_p.c:143:3: warning: implicit declaration of function 'TMP_ALLOC' [-Wim
plicit-function-declaration]
divisible_p.c:154:4: error: 'TMP_FREE' undeclared (first use in this function)
make[2]: *** [divisible_p.lo] Error 1
make[2]: Leaving directory `/home/user/mpir-trunk/mpn'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/home/user/mpir-trunk'

make: *** [all] Error 2

If anyone has any idea what might be going wrong, I'd really
appreciate it. I don't have the foggiest idea. TMP_DECL should be
defined in gmp-impl.h and this is included in mpn/divisible_p.c, so I
don't see what can be wrong.

Bill.

On 8 August 2012 08:29, Brian Gladman <b...@gladman.plus.com> wrote:
> -----Original Message----- From: Bill Hart
> Sent: Wednesday, August 08, 2012 7:38 AM
>
> To: mpir-...@googlegroups.com
> Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress
>
> I fixed the bug in tuneup. So here is the list of items for release now:
>
> todo:
> ==========
> 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
> interface for mpn_mulmod_2expp1
> 32 and 64 bit tuning for fft
> remove old fft tuning params
> 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
>
> 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 **ā

[Bill Hart]

I have tried to figure out why things don't build on MinGW32 and
haven't gotten anywhere. Basically it is not populating config.h. This
is not the first time we've noticed this problem.

I've looked at the relevant code and see no problem. The bug is
probably in MinGW32 itself rather than MPIR, from what I can tell. And
I don't have a workaround.

So for now, MinGW32 is not supported.

Apparently MinGW64 does not suffer from this problem.

Bill.

[Bill Hart]

I fixed the documentation bug and checked if any flint bugs have ended
up in MPIR (they haven't).

There are only trivial things left now. The most complex is fixing the
interface for mpn_mulmod_2expp1.

I will hopefully get the rest of the things done tomorrow.

I don't know what this _Decimal64 thing is about. mpir-3.1.1 builds
just fine on my machine. Perhaps the person who reported this forgot
to specify where mpir was with --with-gmp-include=... and
--with-gmp-lib=... or perhaps forgot to pass --enable-gmpcompat to
MPIR's configure.

Bill.

[Sisyphus]

----- Original Message -----
From: "Bill Hart"

> I don't know what this _Decimal64 thing is about. mpir-3.1.1 builds
> just fine on my machine. Perhaps the person who reported this forgot
> to specify where mpir was with --with-gmp-include=... and
> --with-gmp-lib=... or perhaps forgot to pass --enable-gmpcompat to
> MPIR's configure.

Assuming that no-one else has posted about this, I guess *I* must be "the
person" ;-)

I think I got the configure args right. I used --with-gmp-build= instead of
the "include" and "lib" variants. I also (think I) remembered
to --enable-gmpcompat when building mpir-2.5.1 and to
specify --enable-decimal-float when building mpfr.

To build the two set/get _Decimal64 functions into mpfr-3.1.1, it seems to
be necessary that _GMP_IEEE_FLOATS be defined. (I think it's
the --enable-decimal-float that pulls in the condition that _GMP_IEEE_FLOATS
be defined.)

AFAICT, this is handled by gmp-impl.h in gmp-5.0.5, but when I grep the
entire mpir-2.5.1 source I can find only one file that contains the string
"_GMP_IEEE_FLOATS", and that's the ChangeLog.

Do you mean that you have successfully built mpfr-3.1.1 against mpir-2.5.1
such that mpfr_set_decimal64() and mpfr_get_decimal64() were built in ?

If so, I'll have another crack at it.

Cheers,
Rob

[Bill Hart]

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.

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.

Bill.

[Case Van Horsen]

>
> 1. The windows command line build needs testing and, possibly, correcting. I
> think Case volunteered to do this (can you do this Case?)

I will look at this evening.

>
> 3. Now that the Python build generator for Visual Studio builds is robust,
> I intend to deliver the Visual Studio build solution with fewer initial
> build options since the user can add those that they need. I would like to
> offer win32 and x64 builds for both static libraries and DLLS for: (a)
> generic C, and (b) an assembler version that works on all x64 enables
> processors.
>
> Does anyone have any advice on which existing assembler version meets
> requirement (b)? That is, which of the existing assembler builds can serve
> as a generic assembler build for all Intel/AMD processors that can run
> Windows x64?
>

I have used K8 assembly code successfully. Since it was the first x64
instruction set, it should work everywhere.

Case

[Sisyphus]

----- Original Message -----
From: "Bill Hart" <goodwi...@googlemail.com>
To: <mpir-...@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 ?

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

Cheers,
Rob

[Bill Hart]

On 8 August 2012 15:57, Sisyphus <sisy...@optusnet.com.au> wrote:
>
> ----- Original Message ----- From: "Bill Hart" <goodwi...@googlemail.com>
> To: <mpir-...@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.

[Bill Hart]

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 **â

[Bill Hart]

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.

[Bill Hart]

On 25 September 2012 17:02, Bill Hart <goodwi...@googlemail.com> wrote:

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

Below is the relevant information from a previous post by Jason which
explains what goes wrong. It has always been a problem on MinGW64, but
seems to be a problem now on MinGW32.

At any rate, all that would be required is to build mpir from svn
trunk starting with the revision corresponding to mpir-2.5.1 (where it
presumably last worked on MinGW32), i.e. revision 3850 and find which
commit before revision 3949 causes the config.h file to not be
properly populated as explained by Jason below.

Any volunteers?

---------------

I figured out what going on here , basically configure is failing to
populate config.h with the required
#define HAVE_NATIVE_mpn_addmul_2 1
and all the others , it has always done this on mingw64 but because of
the way the C file redc_2 uses addmul_2 it now causes a problem.A
quick fix is to delete the lines in the mpn/generic/redc_2.c file
where it trys to redefine addmul_2

I don't know why configure fails to populate config.h , it manages to
do the sym links

----------------

Bill.

[Bill Hart]

I've now fixed:

* t-next_likely_prime undefined reference to abort and exit

However, I also note there are some %d and %u format specifiers for
size_t that cause make check compiler warnings.

So that leaves:

* %d and %u format specifiers for size_t that cause make check
compiler warnings

* 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 Hart]

On Tuesday, 25 September 2012, Bill Hart wrote:

I've now fixed:

* t-next_likely_prime undefined reference to abort and exit

However, I also note there are some %d and %u format specifiers for
size_t that cause make check compiler warnings.

 

Why this happens, I don't know. 

%d and %u should be fine.

In C99 %zu was added for size_t and %zd was added for ssize_t. But we don't use C99!

I think I am going to leave these as they are and assume these are compiler bugs.

Bill.

[Pavel Holoborodko]

My environment:

1. Windows 7 Ultimate x64.

2. Latest MinGW32 with gcc 4.7.0 

(installed from official site: http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-20120426/mingw-get-inst-20120426.exe/download)

I've downloaded 3778 revision from the SVN (tagged as MPIR 2.5)  

./configure --prefix=/mingw --host=i686-pc-mingw32 --enable-gmpcompat
make clean 

make

....

libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divisible_p -m32 -O2 -fomit-frame-pointer -mtune=pentiumpro -march=pentiumpro -c divisible_p.c -o divisible_p.o

divisible_p.c: In function '__gmpn_divisible_p':

divisible_p.c:76:3: error: 'TMP_DECL' undeclared (first use in this function)

divisible_p.c:76:3: note: each undeclared identifier is reported only once for each function it appears in

divisible_p.c:141:3: error: 'TMP_MARK' undeclared (first use in this function)

divisible_p.c:143:3: warning: implicit declaration of function 'TMP_ALLOC' [-Wimplicit-function-declaration]

divisible_p.c:154:4: error: 'TMP_FREE' undeclared (first use in this function)

make[2]: *** [divisible_p.lo] Error 1

make[2]: Leaving directory `/u/Development/trunk/libs/mp-mingw/mpir/mpn'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/u/Development/trunk/libs/mp-mingw/mpir'

make: *** [all] Error 2

Generated configure.h is in attachment.

Let me know how I can help you in fixing this problem.

Pavel Holoborodko

-- 

Multiprecision Computing Toolbox for MATLAB

http://www.advanpix.com 

Bill.

[Pavel Holoborodko]

Please ignore error report from my previous e-mail. I just forgot to run autoreconf -i.

I've successfully compiled (all tests passed) the latest revision 3947 from the trunk using the following configuration

./configure --prefix=/mingw --host=i686-pc-mingw32 --enable-gmpcompat

I've used latest mingw32 with gcc 4.7.0

On Wed, Sep 26, 2012 at 1:52 AM, Bill Hart <goodwi...@googlemail.com> wrote:

Bill.

[Sisyphus]

----- Original Message -----
From: "Pavel Holoborodko" <pa...@holoborodko.com>
To: <mpir-...@googlegroups.com>
Sent: Wednesday, September 26, 2012 5:00 PM
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

> Please ignore error report from my previous e-mail. I just forgot to run
> autoreconf -i.
>
> I've successfully compiled (all tests passed) the latest revision 3947
> from
> the trunk using the following configuration
>
> ./configure --prefix=/mingw --host=i686-pc-mingw32 --enable-gmpcompat
>
> I've used latest mingw32 with gcc 4.7.0

Did the generated config.h contain the following #define:

#define HAVE_NATIVE_mpn_addmul_2 1

Were *any* of the HAVE_NATIVE* symbols defined in your config.h ?

It may be that there's something to be learned from comparing the configure
script that Pavel built with the one that shipped with rev 3947.

When I build the same trunk revision (3947) with mingw64.sf's (64-bit)
gcc-4.7.0 compiler, I find that *none* of the HAVE_NATIVE* symbols are
defined .... I also find that there's *no* problem with that for me - at
least, not that I'm aware of.

Am I not looking at something correctly ?
Is it that the failure to define the HAVE_NATIVE symbols is a problem only
with the mingw32 builds ?

I'll build the same trunk revision with mingw.org's (32-bit) gcc-4.5.2
tomorrow night and see how that fares. (I've no time right now.)

Btw, unlike Pavel, I used the configure script that came with the 'svn co'
of trunk.
And, while Pavel's msys shell was installed by mingw-get-inst-20120426.exe,
mine was installed by mingw-get-inst-20110802.exe. (I use the same msys
shell for both 32-bit and 64-bit builds.)

Cheers,
Rob

[Bill Hart]

Thanks for giving this a try.

Two things you may have to do:

* turn off your antivirus, especially if configure causes a problem
with the generated program a.exe
* run mingw shell as administrator

I also had exactly the same problem as you. I think it is due to
problems with config.h not being populated.

However, what you subsequently wrote gave me an idea. I was not aware
that autoreconf actually worked with mpir. The reason is that it runs
libtoolize, which replaces the libtool with a broken one (this has
always been a problem with mpir). So I decided to run the other
programs that autoreconf runs, and I noticed that aclocal gives us a
diff.

Just trying that now with the latest svn revision.

Bill.

[Bill Hart]

No, that didn't work. As usual, config.h is unpopulated. However,
oddly enough, the error message I got was the same as what Pavel got
before autoreconf.

So we've confirmed that revision 3947 from trunk works with these
steps and the latest revision does not work without them.

I will try replicating Pavel's steps exactly (which shouldn't be
needed) to see what happens.

Bill.

[Bill Hart]

On 26 September 2012 17:34, Bill Hart <goodwi...@googlemail.com> wrote:
> No, that didn't work. As usual, config.h is unpopulated. However,
> oddly enough, the error message I got was the same as what Pavel got
> before autoreconf.
>
> So we've confirmed that revision 3947 from trunk works with these

Sorry, I mean 3778 works with those steps.

[Bill Hart]

And much to my surprise, running autoreconf -i actually fixes the
problem with the latest revision.

I've committed the changes to the repo (the only file that changed was
configure).

However, I now note that make distclean does not clean the following files:

? autom4te.cache
? yasm/autom4te.cache
? tests/fft/Makefile
? mpn/preinv_divrem_1.c

So that has to be added to the list of things to fix. I'm a bit
surprised autotools doesn't figure these out for itself.

I hope that those cache files are not the reason for it working after
autoreconf -i. I'll have to check into that.

Bill.

[Bill Hart]

No, the problem comes back if I check out directly from the repo.

Clearly autoreconf -i is altering some non-versioned files which are
required for it to build on MinGW32. And those files must be listed
below.

We are closer to solving this mystery though!

Bill.

[Bill Hart]

So if I check non-versioned files after make distclean when checked
out directly from repo, I just get:

? tests\fft\Makefile

But if I first do autoreconf -i, then I get

? tests\fft\Makefile
? yasm\YASM-VERSION-FILE
? yasm\YASM-VERSION.h
? yasm\autom4te.cache
? autom4te.cache

So it looks like the first is not cleaned up when it should be, which
is a separate issue.

And the last file must be the one responsible for fixing the issue we
are having.

Anyone know what this file is for? Should we just commit it to the repo?

Bill.

[Bill Hart]

Oh wait, not so fast. When I do svn commit after autoreconf -i on MinGW32 I get:

M ltmain.sh
M config.in
M yasm/configure
M configure
M aclocal.m4

Why on earth does it modify all those files? It looks like the version
of autotools on MinGW32 does completely different stuff to the version
on Linux.

But this *completely* defeats the purpose of it being a cross-platform
build system!!

Bill.

[Pavel Holoborodko]

Few more details on my tests.

In total I've tried to compile such revisions: 3850, 3899, 3921, 3947.

All of them didn't compile without autoreconf -i, same error as I described in my first e-mail came up every time.

****

With the following sequence these revisions were compiled fine: 

autoreconf -i

./configure --prefix=/mingw --host=i686-pc-mingw32 --enable-gmpcompat

make

Moreover config.h was properly populated (even few HAVE_NATIVE were defined), please check config.h created for 3947 revision in attachment.

@Bill Hart

I don't have antivirus and I run MSYS under administrator privileges.

@Sisyphus

Although HAVE_NATIVE_mpn_addmul_2 was not in config.h, there are few other HAVE_NATIVE switches were defined.

Hope this helps somehow. Let me know how I can assist you further.

****

One more thing, I've been using MPIR in commercial project - Multiprecision Computing Toolbox for MATLAB, http://www.advanpix.com

Usage of MPIR is clearly attributed on the product's main page as well as in "About" dialog.

I don't know the rules, but is it "Ok" to ask to put link to this project on MPIR page in (as project using MPIR)? 

I would appreciate this very much.

Pavel Holoborodko

[Bill Hart]

On 27 September 2012 02:19, Pavel Holoborodko <pa...@holoborodko.com> wrote:
> Few more details on my tests.
>
> In total I've tried to compile such revisions: 3850, 3899, 3921, 3947.
>
> All of them didn't compile without autoreconf -i, same error as I described
> in my first e-mail came up every time.
>
> ****
> With the following sequence these revisions were compiled fine:
>
> autoreconf -i
> ./configure --prefix=/mingw --host=i686-pc-mingw32 --enable-gmpcompat
> make
>
> Moreover config.h was properly populated (even few HAVE_NATIVE were
> defined), please check config.h created for 3947 revision in attachment.

Thanks for the extra information.

This is definitely an autotools problem. It's not something we can fix
as far as I can tell. The version of autotools on our linux
development machine does not produce a MinGW compatible build. Clearly
the one on MinGW does.

Perhaps we will find that someone else has encountered this problem
with some other package and has found a bug fix or solution.

>
> @Bill Hart
> I don't have antivirus and I run MSYS under administrator privileges.
>
> @Sisyphus
> Although HAVE_NATIVE_mpn_addmul_2 was not in config.h, there are few other
> HAVE_NATIVE switches were defined.

Of course, whether or not this is defined depends on whether there is
a native addmul_2, which there isn't for many machines (it's not often
more efficient).

>
> Hope this helps somehow. Let me know how I can assist you further.
> ****
>
> One more thing, I've been using MPIR in commercial project - Multiprecision
> Computing Toolbox for MATLAB, http://www.advanpix.com
> Usage of MPIR is clearly attributed on the product's main page as well as in
> "About" dialog.
>
> I don't know the rules, but is it "Ok" to ask to put link to this project on
> MPIR page in (as project using MPIR)?
> I would appreciate this very much.

I personally have no objections. If no one else raises any, we should
be able to do this around the time of the release. It would seem to be
in our best interest to list packages that use MPIR.

Bill.

>
> Pavel Holoborodko

[Sisyphus]

----- Original Message -----
From: "Pavel Holoborodko"

> My environment:
> 1. Windows 7 Ultimate x64.
> 2. Latest MinGW32 with gcc 4.7.0
> (installed from official site:
> http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-20120426/mingw-get-inst-20120426.exe/download
> )

Hi Pavel,

(This is an offlist post.)

I was keen to grab a more recent version of autoreconf, so I downloaded the
installer from the same link as you did (above).

But when I executed that installer, it installed gcc-4.6.2 (not 4.7.0) ...
and no MSYS !!

Do you know why that happened ?

Cheers,
Rob

[Pavel Holoborodko]

I've selected "Download latest repository catalogues" during the installation instead of default "Use pre-packaged repository catalogues".

Plus I've also included MSYS, C++ and Fortran compilers in "Select Components" window.

Hope this helps.

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To post to this group, send email to mpir-...@googlegroups.com.

To unsubscribe from this group, send email to mpir-devel+unsubscribe@googlegroups.com.

[Sisyphus]

----- Original Message -----
From: "Sisyphus"

>
> Hi Pavel,
>
> (This is an offlist post.)
>

Ummm ... perhaps not, though that was my intention ... ;-))))

Cheers,
Rob

[Bill Hart]

It's possible to delete posts if you wish. However, I personally see
no problem with this being on list.

Bill.

[Bill Hart]

Some possible good news.

The autoconf/autoreconf/automake versions I have on MinGW32 are
*identical* to the ones we have on our linux development machine.

This further confirms my suspicions that this is an extremely
irritating autotools bug. There should be no difference whatsoever in
the configure and Makefiles created by the precise same version of
autotools between machines from the same input files. It is, after
all, supposed to create a cross platform build system!

But the possible good news is that maybe we can commit the changes
made by autoreconf -i on MinGW32 and it will work everywhere, not just
Linux and OSX. I am not confident it will work on older macs, because
I've had that problem before. But these are pretty rare these days,
and we might just get away with it.

I will start experimenting with this to see what happens. Commit coming shortly.

Bill.

[Sisyphus]

----- Original Message -----
From: "Pavel Holoborodko" <pa...@holoborodko.com>
To: <mpir-...@googlegroups.com>
Sent: Thursday, September 27, 2012 10:21 PM
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

> I've selected "Download latest repository catalogues" during the
> installation instead of default "Use pre-packaged repository catalogues".

Yep -I had used the default.

> Plus I've also included MSYS, C++ and Fortran compilers in "Select
> Components" window.

And I hadn't scrolled down far enough to see the 'MSYS' options.

Thanks, Pavel - I've rectified the mistakes I made, and all is now fine.

Cheers,
Rob

[Bill Hart]

This did not work. The problem is I *cannot* commit the changes to svn
because of Windows line endings.

Changing the svn:eol-style to native for those files does not fix the
problem (this only affects the line style used when the file is
checked out). Making this change to svn properties and then checking
out the repo again on MinGW32 doesn't fix the problem either.

Also, it doesn't seem to be a case of the input files having incorrect
line endings either, as for example config.in is one of the files,
which as far as I know is not created by running configure or make.

{pulls hair out}

Bill.

[Bill Hart]

Omigosh!!

There was a single \n in the middle of a comment in the config.in
generated on MinGW32 which prevented me from committing it to the
repo. After fixing this I was able to commit the differences to the
autotools files as generated by MinGW32's autoreconf 2.68 over the
Linux autoreconf 2.68.

The good news is this works on Linux. The bad news is it still doesn't
work on MinGW.

Clearly there are unversioned files (not committed to svn) which are
required for correct operation on MinGW.

make distclean
svn status | grep ^?

yields only:

? tests\fft\Makefile

whereas

autoreconf -i
svn status | grep ^?

yields:

? tests\fft\Makefile
? yasm\YASM-VERSION-FILE
? yasm\YASM-VERSION.h
? yasm\autom4te.cache
? autom4te.cache

So, presumably one or more of those last four files needs to be under
version control. Any guesses?

Bill.

[Bill Hart]

Obviously yasm files cannot be responsible for configure not filling
config.h correctly.

And the autom4te.cache files are only to speed up autoreconf, not the
build system itself. (I tried committing these, but this didn't fix
the problem.)

Running autoreconf -i followed by svn commit now yields nothing.

So if no versioned files change between Windows and Linux and no
unversioned files are responsible for it not working, then what on
earth could be responsible?

This is the most stupid bug I have ever encountered!

Bill.

[Bill Hart]

More bad news.

The filename mpir-2.5.1/build.vc10/mpir-tests/fft.fft_ifft_mfa_truncate_sqrt2/fft.fft_ifft_mfa_truncate_sqrt2.vcxproj
is apparently too long, so we cannot create a tarball of MPIR.

Bill.

[Cactus]

On Thursday, 27 September 2012 16:43:55 UTC+1, Bill Hart wrote:

More bad news.

The filename  mpir-2.5.1/build.vc10/mpir-tests/fft.fft_ifft_mfa_truncate_sqrt2/fft.fft_ifft_mfa_truncate_sqrt2.vcxproj
is apparently too long, so we cannot create a tarball of MPIR.

How do we want to play this - most of the length comes from the underlying test file name. Do we want to add another shorter named file for Visual Studio use (with the obvious maintenance overhead) or should we shorten the name of the test file?  Removing the duplication in the folder name and file name in the Visual Studio naming would involve a major rewrite of parts of the Visual Studio design.  I would really want to avoid this.

Brian

[Bill Hart]

Yes, we should change the name of the file in the fft directory and
the test file in the tests/fft directory.

We'll have to use something like:

fft_ifft_mfa_trunc_sqrt2.c, etc

I don't think we can abbreviate much more than that without changing a
whole load of other files to be consistent. I think this is likely to
be enough though.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Thursday, September 27, 2012 5:19 PM
To: Cactus
Cc: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

Yes, we should change the name of the file in the fft directory and
the test file in the tests/fft directory.

We'll have to use something like:

fft_ifft_mfa_trunc_sqrt2.c, etc

I don't think we can abbreviate much more than that without changing a
whole load of other files to be consistent. I think this is likely to
be enough though.

==================
Ok,

I'll do this since I have to do quite a bit of renaming.

Brian

[Bill Hart]

Some good news.

If I hack together a tarball on my linux machine for mpir using make
dist then copy this to my MinGW32 machine, it builds no problem.

I still cannot figure out for the life of me what is different between
the two. According to svn, there is no difference!!

It seems we simply cannot build on MinGW32 from an svn checkout
without first doing autoreconf -i.

Fortunately, it is the tarball, not the svn checkout that we put on
the website for users. So I am calling it quits trying to solve this
problem.

From now on, MinGW32 is only supported out-of-the-box when using a
tarball from the MPIR website, not when using an svn checkout.

Bill.

[Bill Hart]

Herewith latest release todo list:

mpir-todo:
==========
* 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
* filename mpir-2.5.1/build.vc10/mpir-tests/fft.fft_ifft_mfa_truncate_sqrt2/fft.fft_ifft_mfa_truncate_sqrt2.vcxproj
is too long
* make dist doesn't pick up tests/fft and make distclean doesn't
remove tests/fft/Makefile
* implicit declaration warning (see below)
* integer overflow warning (see below)
* test start/end warning (see below)
* update library version number
* test on platforms we have access to
* make tune on platforms we have access to
* release paperwork
* list pavel's Multiprecision Computing Toolbox for MATLAB,
http://www.advanpix.com on website

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 **â

implicit declaration warning:
=============================
libtool: link: gcc -std=gnu99 -m32 -O2 -fomit-frame-pointer -mtune=corei7 -march
=corei7 -o t-mul_i.exe t-mul_i.o ../../tests/.libs/libtests.a /home/user/mpir-2
.5.1/.libs/libmpir.a ../../.libs/libmpir.a
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../tests -m32 -O2 -fo
mit-frame-pointer -mtune=corei7 -march=corei7 -c t-next_likely_prime.c
t-next_likely_prime.c: In function 'main':
t-next_likely_prime.c:67:11: warning: implicit declaration of function 'abort' [
-Wimplicit-function-declaration]
t-next_likely_prime.c:67:11: warning: incompatible implicit declaration of built
-in function 'abort' [enabled by default]
t-next_likely_prime.c:90:11: warning: incompatible implicit declaration of built
-in function 'abort' [enabled by default]
t-next_likely_prime.c:99:5: warning: implicit declaration of function 'exit' [-W
implicit-function-declaration]
t-next_likely_prime.c:99:5: warning: incompatible implicit declaration of built-
in function 'exit' [enabled by default]

integer overflow warning:
=========================
libtool: link: gcc -std=gnu99 -m32 -O2 -fomit-frame-pointer -mtune=corei7 -march
=corei7 -o t-set_str.exe t-set_str.o ../../tests/.libs/libtests.a /home/user/mp
ir-2.5.1/.libs/libmpir.a ../../.libs/libmpir.a
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../tests -m32 -O2 -fo
mit-frame-pointer -mtune=corei7 -march=corei7 -c t-set_sx.c
t-set_sx.c: In function 'check_data':
t-set_sx.c:60:26: warning: integer overflow in expression [-Woverflow]
t-set_sx.c:60:55: warning: integer overflow in expression [-Woverflow]

tests start/end warning:
========================
libtool: link: gcc -std=gnu99 -m32 -O2 -fomit-frame-pointer -mtune=corei7 -march
=corei7 -o t-mt.exe t-mt.o ../../tests/.libs/libtests.a /home/user/mpir-2.5.1/.
libs/libmpir.a ../../.libs/libmpir.a
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../tests -m32 -O2 -fo
mit-frame-pointer -mtune=corei7 -march=corei7 -c t-rand.c
t-rand.c: In function 'main':
t-rand.c:157:3: warning: implicit declaration of function 'tests_start' [-Wimpli
cit-function-declaration]
t-rand.c:292:3: warning: implicit declaration of function 'tests_end' [-Wimplici
t-function-declaration]

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Thursday, September 27, 2012 5:19 PM
To: Cactus
Cc: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

Yes, we should change the name of the file in the fft directory and
the test file in the tests/fft directory.

We'll have to use something like:

fft_ifft_mfa_trunc_sqrt2.c, etc

I don't think we can abbreviate much more than that without changing a
whole load of other files to be consistent. I think this is likely to
be enough though.

===================
I have cut the length slightly without changing any filenames.

Could you let me know if it now works before I start changing filenames?

Brian

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Thursday, September 27, 2012 5:19 PM
To: Cactus
Cc: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

Yes, we should change the name of the file in the fft directory and
the test file in the tests/fft directory.

We'll have to use something like:

fft_ifft_mfa_trunc_sqrt2.c, etc

I don't think we can abbreviate much more than that without changing a
whole load of other files to be consistent. I think this is likely to
be enough though.

=============================
Assuming my small name shortening doesn't work, do we want to keep the
association between file names and defined symbols?

Do we want to uniformly replace 'truncate' with 'trunc' in file names and
symbols?

Brian

[Bill Hart]

Hi Brian,

the file name:

mpir-2.5.1/build.vc10/mpir-tests/f.fft_ifft_mfa_truncate_sqrt2/f.fft_ifft_mfa_truncate_sqrt2.vcxproj

is still too long. The maximum length appears to be 99, so we are
still 1 character over the limit I think.

I think we should change all the truncates to trunc in the fft and
tests/fft directory.

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-...@googlegroups.com.
> To unsubscribe from this group, send email to

> mpir-devel+...@googlegroups.com.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Thursday, September 27, 2012 8:01 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

Hi Brian,

the file name:

mpir-2.5.1/build.vc10/mpir-tests/f.fft_ifft_mfa_truncate_sqrt2/f.fft_ifft_mfa_truncate_sqrt2.vcxproj

is still too long. The maximum length appears to be 99, so we are
still 1 character over the limit I think.

I think we should change all the truncates to trunc in the fft and
tests/fft directory.

========================
I have changed 'truncate' in all all files AND symbols associated with the
FFT to 'trunc'.

I have changed the Makefile.am files where appropriate but there may be
other *nix build files where file names need to change.

The Visual Studio build works fine but the *nix build now needs careful
testing as there are a lot of changes to a lot of files.

Brian

[Bill Hart]

Thanks Brian,

I'll give it a bit of a go on linux now and report. If it gets
difficult I'll resume tomorrow.

Bill.

[Bill Hart]

Hi Brian,

After discovering that the libtool in MinGW32 is different in version
number by 0.001 and therefore completely *incompatible*, according to
autoreconf on Linux, I did manage to get it to reconf and am happy to
report it builds and passes tests on Linux.

I also added tests/fft to the relevant Makefile.am and the fft tests
now run. We've not run these before on Linux, but I'm happy to report
they pass on x86_64. I'll try them shortly on MinGW32. Then I'll pack
it in for the night.

Brian, I've attached a tarball produced by make dist. Could you verify
that this builds on Windows and that make dist hasn't omitted
anything. If it has, can you let me know what and I'll try to modify
it so that it is picked up. This is not an svn issue, but an autotools
one. Yes, autotools even interacts with the MSVC build!!

I think this brings our list of release tasks down to the following
(the worst of which is to fix the problem with finding fft tuning
cutoffs -- the code is there, it just doesn't seem to give consistent
cutoffs):

mpir-todo:
==========
* 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

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Thursday, September 27, 2012 10:06 PM
To: mpir-...@googlegroups.com
Cc: Brian Gladman
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

Hi Brian,

After discovering that the libtool in MinGW32 is different in version
number by 0.001 and therefore completely *incompatible*, according to
autoreconf on Linux, I did manage to get it to reconf and am happy to
report it builds and passes tests on Linux.

I also added tests/fft to the relevant Makefile.am and the fft tests
now run. We've not run these before on Linux, but I'm happy to report
they pass on x86_64. I'll try them shortly on MinGW32. Then I'll pack
it in for the night.

Brian, I've attached a tarball produced by make dist. Could you verify
that this builds on Windows and that make dist hasn't omitted
anything. If it has, can you let me know what and I'll try to modify
it so that it is picked up. This is not an svn issue, but an autotools
one. Yes, autotools even interacts with the MSVC build!!

==============
The only problem I had was that tune-fft.c was not present (or not where I
expected it).

Otherwise it worked fine on x64.

Brian

[Bill Hart]

All the tests pass on MinGW32, including the fft tests. So this is good news.

Tomorrow I will try to sort out the tuning issues.

I also just noticed that make speed doesn't work. It seems to be due
to some problems in speed.h. I'll add it to the list of things to fix.

Bill.

[Bill Hart]

OK, thanks. I'll add that program to the relevant makefile.am.

Bill.

[Bill Hart]

fft/tune/tune-fft.c is now included in the distribution tarball.

I also discovered that make speed is working after all. I simply
hadn't built the library.

I also checked the fft cutoffs by hand and it is producing reasonable
cutoffs. It's surprising to me that the toom8h code is competitive
(with some crossovers along the way) all the way up to 11000 limbs. So
the 7500 limbs that the tuning code selects on my machine is quite
reasonable, if not a little large.

I will make one final check that I have the code for timing the fft
set up correctly. But probably it is just due to not having an
iterative fft implementation to speed things up for small sizes, and a
very fast toom8h (which we added from the GMP project).

I'd like to get this crossover much lower, but for an initial release
with the new fft this will be fine. We'll have to work on some fast
assembly code for it and an iterative version for small convolution
lengths.

Anyhow, this brings the list of todo items to the following:

mpir-todo:
==========
* fft_combine_bits const warning (see below)
* ../mpn/generic/gcdext.c:238: warning: integer overflow in expression
* _mp_release_macro volker braun reported

* implicit declaration warning (see below)
* integer overflow warning (see below)
* test start/end warning (see below)
* update library version number
* test on platforms we have access to
* make tune on platforms we have access to
* release paperwork

* make mpir-2.6.0 branch in svn

* list pavel's Multiprecision Computing Toolbox for MATLAB,
http://www.advanpix.com on website

I will now try to fix all these compiler warnings. They should all be
easy one line fixes.

Bill.

[Bill Hart]

Does anyone have any idea about this t-set_sx code.

It sets up an array of structs (not all fully populated):

{ 0L, 0 },
{ 1L, 1, { 1 } },
{ -1L, -1, { 1 } },

#if GMP_NUMB_BITS >= BITS_PER_UINTMAX
{ INTMAX_MAX, 1, { INTMAX_MAX, 0 } },
{ -INTMAX_MAX, -1, { INTMAX_MAX, 0 } },
#else
{ INTMAX_MAX, 2, { INTMAX_MAX & GMP_NUMB_MASK, INTMAX_MAX >>
GMP_NUMB_BITS } },
{ -INTMAX_MAX, -2, { INTMAX_MAX & GMP_NUMB_MASK, INTMAX_MAX >>
GMP_NUMB_BITS } },
#endif

#if GMP_NUMB_BITS >= BITS_PER_UINTMAX
{ INTMAX_MIN, -1, { -INTMAX_MIN, 0 } },
#else
{ INTMAX_MIN, -2, { -INTMAX_MIN & GMP_NUMB_MASK, -INTMAX_MIN >>
GMP_NUMB_BITS } },
#endif

In each case it gives a value n which is read in using mpz_set_sx,
followed by a number of limbs. Then it gives a pair of limbs to
compare with.

But I cannot understand how the last set is supposed to work.

INTMAX_MIN is already negative, and the most negative number
representable in an intmax_t.

What I don't understand is the purpose of the minus signs before the
INTMAX_MIN value. These cause a compiler warning because the result is
the same value, i.e.

INTMAX_MIN == -INTMAX_MIN.

Anyone know why the minus signs are there? Is there any reason I
shouldn't just remove them?

Bill.

[Brian Gladman]

==============================

Mathematically, -INTMAX_MIN is what is needed on the right but integer
wraparound happens to make this redundant.

I don't recall that there was any more to it than this.

Brian

[Bill Hart]

I'm not sure I understand why -INTMAX_MIN is needed mathematically.
After all, INTMAX_MIN is already a negative integer, so -INTMAX_MIN
would be positive, in which case the answer would be wrong, due to
truncation.

I personally think that both codewise and mathematically, what is
needed is just INTMAX_MIN.

I think I am going to change them to INTMAX_MIN instead of -INTMAX_MIN.

After that, everything but the paperwork is done on the linux side.

What's the Windows todo list looking like? Are we getting near the
time where we can issue an alpha release?

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, September 28, 2012 11:13 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

On 28 September 2012 22:15, Brian Gladman <b...@gladman.plus.com> wrote:
> -----Original Message----- From: Bill Hart
> Sent: Friday, September 28, 2012 9:39 PM
> To: mpir-...@googlegroups.com

> Mathematically, -INTMAX_MIN is what is needed on the right but integer
> wraparound happens to make this redundant.
>
> I don't recall that there was any more to it than this.
>
>

I'm not sure I understand why -INTMAX_MIN is needed mathematically.
After all, INTMAX_MIN is already a negative integer, so -INTMAX_MIN
would be positive, in which case the answer would be wrong, due to
truncation.

=================================

Maybe I am not explaining myself well.

Consider what has to be done to convert a negative integer of_any_length
into the limbs in an mpn.

The first step is to reverse its sign.

I am not saying that this is needed in _this_ case, just that the logical
steps in the general (indeterminate length) case are (1) reverse the sign,
(2) divide it into chunks.

All I am saying is that this is possibly the motivation for the sign.

Brian

[Bill Hart]

Ah yes, you are right. I understand now.

I don't know how this can be represented without an overflow warning
in C and still make sense.

Anyhow, I've changed it now to avoid the compiler warning. If we come
up with something more meaningful we can change it again.

Bill.

[Brian Gladman]

=============================================
Apart form tuning, which is just moving Linux tuning data into the Windows
directories once it is available, I am not aware of any issues that now need
resolution.

As far as I know, the command line build now works as I have added a call to
the Python script that generates the needed cfg.h files. We might want to
document the Python dependency but it is hardly necessary since it puts out
a "Cannot build without Python" message.

I have tested the Windows command line build for one architecture but I
don't normally use so it would make sense for a regular user to check this.

So, I think we are ready for an alpha release.

Brian

[Case Van Horsen]

I managed to do a quick test of the command line build last. Their was
an error with "make check". I should have time to look at it tonight.

Case

>
> So, I think we are ready for an alpha release.
>
> Brian
>
>

[Case Van Horsen]

Interesting. If I use ABI=64, then "make" and "make check" succeed.

If I use "configure.bat ABI=32 --cpu=pentium3", then "make" succeeds
but I get the following error for "make check":

try.c
try.obj : error LNK2001: unresolved external symbol ___gmpn_mod_1c
try.obj : error LNK2001: unresolved external symbol ___gmpn_divrem_1c
try.exe : fatal error LNK1120: 2 unresolved externals
ERROR

Any ideas where to look?

[Brian Gladman]

-----Original Message-----
From: Case Van Horsen
Sent: Tuesday, October 02, 2012 7:43 AM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

[snip]

> I managed to do a quick test of the command line build last. Their was
> an error with "make check". I should have time to look at it tonight.
>
> Case

Interesting. If I use ABI=64, then "make" and "make check" succeed.

If I use "configure.bat ABI=32 --cpu=pentium3", then "make" succeeds
but I get the following error for "make check":

try.c
try.obj : error LNK2001: unresolved external symbol ___gmpn_mod_1c
try.obj : error LNK2001: unresolved external symbol ___gmpn_divrem_1c
try.exe : fatal error LNK1120: 2 unresolved externals
ERROR

Any ideas where to look?

=======================================
Hi Case,

Oddly, your failure report allowed me to discover an error in my Python
build generator for win32 builds. I have now corrected this in the
repository but this only affects Visual Studio builds so I don't see how it
can cause the problem you are seeing.

If try was linking with a library built using the Visual Studio IDE, this
error would have caused the failure you are seeing. which leads me to wonder
whether the command line build is putting the library in the right place for
linking with tests, try, tune, ... etc. Maybe there is an old version of
the library built with Visual Studio in the correct place and this is not
being overwritten when the command line build is performed?

Brian

[Brian Gladman]

-----Original Message-----
From: Case Van Horsen
Sent: Tuesday, October 02, 2012 7:43 AM

To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

[snip]

Interesting. If I use ABI=64, then "make" and "make check" succeed.

If I use "configure.bat ABI=32 --cpu=pentium3", then "make" succeeds
but I get the following error for "make check":

try.c
try.obj : error LNK2001: unresolved external symbol ___gmpn_mod_1c
try.obj : error LNK2001: unresolved external symbol ___gmpn_divrem_1c
try.exe : fatal error LNK1120: 2 unresolved externals
ERROR

Any ideas where to look?

=============================================

On Windows exported symbols for win32 are prefixed with three '___' whereas
the prefix for x64 symbols is '__'.

If win32 and x64 versions of MPIR both exist, when try is built it will use
the headers for the last built version of the library. Hence if a link is
done for an x64 version of try but the last built version of MPIR is for
win32, an x64 build will be done but it will use win32 headers. I have
seen build errors of the type you are seeing where this is the cause.

Brian

[Bill Hart]

Hi all,

I had a look through the svn log to try and construct a list of things
which have changed since the last release. Unfortunately, all the log
entries for mpir-exp have been lost in the merge to trunk, but I
looked through the mpir-exp log so that they will at least be
reflected in the Changelog.

Here is what I have found so far:

Bugs:

* fixed build issue due to incorrect redc_2 header include
* proper test for unpatched gcc-4.3.2
* bug in speed/common for dc_bdiv_qr_n
* documentation error wrt -ve exponents in mpz_powm_ui
* correct mpq_cmp_ui declaration error found by David Cleaver
* correct bug in Windows assembler code for karasub

Improvements:

* Completely new FFT implementation (William Hart)
* Support for choice of intmax_t integer types in ui/si functions
(Brian Gladman)
* Visual Studio 11 support (Brian Gladman)
* added cpuid support for more x86_64 CPUs (Jason Moxham)
* new redc_1 for sandybridge and bobcat (Jason Moxham)
* Python Windows build generator (Brian Gladman)

Compatibility:

* additional macro support for mpfr-3.1.0
* Add macros for __GNU_MP_RELEASE and __MPIR_RELEASE

Is there anything missing? Any corrections? Anything that shouldn't be there?

When all is ok, I'll do the paperwork for the new release.

I also think we should do a release 2.5.2 based on revision 3897 which
fixes the redc_2 build issue in 2.5.1 (it looks like Jason was
intending to do a 2.5.2 release for this reason). This will give
people a nice stable MPIR to use if they aren't comfortable with
switching over to the new FFT immediately (though it has been used
pretty extensively in flint for some time now).

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart

===========================

Although I made a few changes to cater for it, I have not yet added Visual
Studio 11 builds for MPIR. So the item:

* Visual Studio 11 support (Brian Gladman)

should really be 'prepare for Visual Studio 11'.

Brian

[Bill Hart]

Ok, I might remove this for now.

Are you happy with the rest?

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Tuesday, October 02, 2012 5:58 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

Ok, I might remove this for now.

Are you happy with the rest?

=============

Yes. The only known outstanding issue on Windows is the issue that Case
found with the command line build.

I have made quite a few changes today to improve the way the auxiliary
programs (i.e the tests, tune, speed and try) are built on Windows but
nothing that directly impacts on MPIR end users.

Brian

[Bill Hart]

No problem. I won't do the actual release until the issue Case reported is fixed. I'll wait to hear back from him after your last lot of suggestions before doing anything.

Is it possible this is to do with GLOBAL_FUNC declarations. At some point a whole load of these got altered to PROLOGUE statements, but this broke the Linux build. Given that MinGW32 works I can't see how this could be the problem as I think Case reported problems only on Win32.

Late tonight I'll release 2.5.2 which will work on more systems than 2.5.1, but won't have the new fft or other mpir-exp changes. I've actually prepared that release but had to shut down to catch a bus. I'm on my way out for a few hours.

I'll also finish off the 2.6.0 release paperwork tonight. I've done much of it already.

Once the issue Case reported is solved I'll issue a 2.6.0 alpha. Then we can begin testing on loads of platforms.

Bill.

[Bill Hart]

Oh for goodness sake! MinGW32 runs out of memory after half an hour
when trying to create a tarball for MPIR.

Bill.

[Case Van Horsen]

On Tue, Oct 2, 2012 at 1:36 AM, Brian Gladman <b...@gladman.plus.com> wrote:
> -----Original Message----- From: Case Van Horsen
> Sent: Tuesday, October 02, 2012 7:43 AM
> To: mpir-...@googlegroups.com
> Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress
>
> [snip]
>
>
> Interesting. If I use ABI=64, then "make" and "make check" succeed.
>
> If I use "configure.bat ABI=32 --cpu=pentium3", then "make" succeeds
> but I get the following error for "make check":
>
> try.c
> try.obj : error LNK2001: unresolved external symbol ___gmpn_mod_1c
> try.obj : error LNK2001: unresolved external symbol ___gmpn_divrem_1c
> try.exe : fatal error LNK1120: 2 unresolved externals
> ERROR
>
> Any ideas where to look?

I don't have an answer yet but I have a clue. At line 110 in make.bat,
the obj files created from several asm files are deleted and replaced
by their generic equivalents. If I remove mod_1 from that block, I fix
one of the error messages but also generate a warning somewhere else.

Do you have any idea why those particular files are replaced?

Could there be an issue with the generic replacements?

Case

>
> =============================================
>
> On Windows exported symbols for win32 are prefixed with three '___' whereas
> the prefix for x64 symbols is '__'.
>
> If win32 and x64 versions of MPIR both exist, when try is built it will use
> the headers for the last built version of the library. Hence if a link is
> done for an x64 version of try but the last built version of MPIR is for
> win32, an x64 build will be done but it will use win32 headers. I have
> seen build errors of the type you are seeing where this is the cause.
>
>
> Brian
>

[Brian Gladman]

==========================
Hi Case

That pins it down nicely.

The command line build depends on my Visual Studio build generator to
produce the config.h files and, in particular, the HAVE_NATIVE_symbol
defines for any symbols that are defined in any assembler files used. But
the command line build is not able to handle files which define multiple
symbols (I don't remember why) so any that are known to (or might) do so are

deleted and replaced by their generic equivalents.

However my build system is more sophisticated and builds a symbol table for
all the assembler files used and generates HAVE_NATIVE_symbol defines for
all the symbols found.

What this means is that any symbols that I pick up from files with more than
one symbol are expected to be available in the build. But they won't be in
the command line build because the files in question have been replaced by
generic files that don't define these symbols.

Sadly knowing what is wrong and solving it are two different things. There
are several options.

Firstly, we could try to modify the command line build to handle files with
multiple symbols but Jason would need to remind us what the problem is (Or
we need to find it).

Second, we can split off a version of my build generator and modify it to
avoid generating HAVE_NATIVE_symbol defines for files with multiple symbols.

Third we can just remove the secondary symbols from all files that define
them. This will have a small impact on performance but certainly not a
significant one. I don't think this would matter much on win32 but it would
be a pity to reduce the performance of the Visual Studio x64 build in this
way (I think some x64 files may have the same problem).

Perhaps Jason can advise us on the best approach (I am not sure if he is
listening at the moment though).

A more interesting option (for the future) is to use my build generator to
build the command line build files.

Brian

[Bill Hart]

I definitely don't think option 3 will work. We need the defines for
the MinGW32 build, and having just gotten that to work, I definitely
don't want to risk breaking it.

Option 1 seems best to me (being ignorant of the aforementioned
problems with this approach). Failing that, we can try 2.

Brian, there must be two stages to this. The first must be a stage
which looks through the assembly files for GLOBAL_FUNC macros and
outputs the relevant HAVE_NATIVEs. I assume this is your Python build
generator?

Is it this build generator which does the deletion and replacement
with generic files? If so, does it replace with *both* generic files,
one for each symbol to be defined?

What is the other part of the process? I mean the part that Jason says
has a problem with multiply defined symbols. I assume this is the
command line build system itself? Is that make.bat or some other file
where this happens?

Maybe with the right information, I can track down the problem and
find a suitable workaround.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart

Sent: Wednesday, October 03, 2012 3:25 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

I definitely don't think option 3 will work. We need the defines for
the MinGW32 build, and having just gotten that to work, I definitely
don't want to risk breaking it.

Option 1 seems best to me (being ignorant of the aforementioned
problems with this approach). Failing that, we can try 2.

Brian, there must be two stages to this. The first must be a stage
which looks through the assembly files for GLOBAL_FUNC macros and
outputs the relevant HAVE_NATIVEs. I assume this is your Python build
generator?

==========================
Yes, my build generator collects a list of the assembler files in the x86w
and x86_64w directory and their sub-directories and then scans these files
for the symbol definitions (looking for the various procedure MACROs such as
LEAF_PROC, FRAME_PROC etc.). These are then used to build the a symbol table
for each sub-directory.

The symbols defined by the files in each directory are then used to build
the cfg.h files in each directory and these are then used to build the
HAVE_NATIVE_symbol defines.
==========================

Is it this build generator which does the deletion and replacement
with generic files? If so, does it replace with *both* generic files,
one for each symbol to be defined?

==========================
No, this is done in make.bat, the command line batch file.
==========================

What is the other part of the process? I mean the part that Jason says
has a problem with multiply defined symbols. I assume this is the
command line build system itself? Is that make.bat or some other file
where this happens?

==========================
This is an issue with make.bat (bear in mind that I know little or nothing
about this since it is Jason's creation that is being maintained by Case at
the moment).

As I said earlier, I remember Jason having issues with files that define
multiple symbols but I don't recall what the problem was.
==========================

Maybe with the right information, I can track down the problem and
find a suitable workaround.

==========================
A lot of the multiple symbols are of the form:

carry_entry:
go to entry
main_entry:
set carry = 0
entry:
code ...

Another solution, at the coast of more binary code, is to duplicate all of
these files and define a single symbol in each file.
==========================

Brian

[Case Van Horsen]

Just to clarify, I only use the command line tools for convenience to
build an old version of gmpy. All builds for gmpy2 require MPFR and
MPC so I now use the full Visual Studio builds. If fixing the command
line tools becomes, I don't really need them.

>
> As I said earlier, I remember Jason having issues with files that define
> multiple symbols but I don't recall what the problem was.
> ==========================
>
>
> Maybe with the right information, I can track down the problem and
> find a suitable workaround.
>
> ==========================
> A lot of the multiple symbols are of the form:
>
> carry_entry:
> go to entry
> main_entry:
> set carry = 0
> entry:
> code ...
>
> Another solution, at the coast of more binary code, is to duplicate all of
> these files and define a single symbol in each file.
> ==========================
>
>
> Brian
>

[Bill Hart]

It seems that someone has removed the definition of MPIR_VERSION from
gmp-h.in. Is there any reason for this? I don't seem to be able to
issue a release without it.

I notice _MSC_MPIR_VERSION is now defined. I don't get why it was
changed. Isn't the former name more sensible? It's needed by configure
for example.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Wednesday, October 03, 2012 4:32 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress

It seems that someone has removed the definition of MPIR_VERSION from
gmp-h.in. Is there any reason for this? I don't seem to be able to
issue a release without it.

I notice _MSC_MPIR_VERSION is now defined. I don't get why it was
changed. Isn't the former name more sensible? It's needed by configure
for example.

=================================

I don't think I did this - if I did it was not intentional!

Brian