Windows batch file build fails with 2.1.0

[Case Vanhorsen]

Hi,

To build a new version of gmpy, I normally use the configure.bat and
make.bat approach to building MPIR. This only requires the SDK tools
and it works very well when targeting 64-bit code. It works fine with
1.3.1 and 2.0.0 but fails with 2.1.0.

After installing yasm.exe and copying yasm.rules, I use the following commands:

> "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\vcvars64.bat"
> cd C:\src\mpir-2.1.0\build.vc9
> configure
> make
> make check

The first test that fails is:

mpf.reuse : ERROR ( -1073741819 )

and then more failures:

mpn.dc_bdiv_q : ERROR ( -1073741819 )
mpn.dc_bdiv_q_n : ERROR ( -1073741819 )
mpn.dc_bdiv_qr : ERROR ( 3 )
failed: quotient wrong!
nn = 584, dn = 212, qn = 372

<<skipping the rest of the failures>>

Is this a tuning bug?

casevh

[Cactus]

Hi Case,

I don't maintain the batch script - Jason does - so he may be able to
figure out what is going on better than I can.

It looks like the script is not setting up the build correctly.

What is the content of the file 'config_params.bat' after the build?

Which configuration are you trying to build?

Ohe thing I noticed is that the configure batch file sets up a
compilation environment itself so your first line:

"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin
\vcvars64.bat"

may get over-ruled in some way before make.bat is invoked (i.e where
the build is done).

Maybe this would work:

cd C:\src\mpir-2.1.0\build.vc9
configure
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin
\vcvars64.bat"

make

"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin
\vcvars64.bat"

make check

Brian

[Cactus]

>       Brian- Hide quoted text -
>
> - Show quoted text -

Hi again Case,

I don't normally use the command line build but I have just tried it
with both VC9 and VC10 on nehalem (my Core2 machine is broken right
now so I couldn't try this).

I found an issue with detecting Python (that I have now resolved in
SVN) but, otherwise, both command line builds worked without any
problems. I did not have to set the VC++ environment in order to do
this so this may be relevant.

Brian

[Case Vanhorsen]

Hi Brian,

Oops. I just realized I made an error in my bug report. When it fails,
I'm actually passing the --cpu-k8 option to configure. I thought I saw
the failure without that option last night, too.

I don't have an actual K8 machine but I'm using that option to build a
cross-CPU binary. Is K8 still the best "generic" option or should I
use "core2"?

I just tried --cpu-K10 and that fails to compile with:

c:\src\mpir-2.1.0\gmp-impl.h(117) : fatal error C1083: Cannot open
include file: 'gmp-mparam.h': No such file or directory

casevh

>
>      Brian
>
> --
> You received this message because you are subscribed to the Google Groups "mpir-devel" group.
> To post to this group, send email to mpir-...@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.
>
>

[Cactus]

On Jun 9, 2:31 pm, Case Vanhorsen <cas...@gmail.com> wrote:

I would go with k8 myself but Jason may know better.

> I just tried --cpu-K10 and that fails to compile with:
>
> c:\src\mpir-2.1.0\gmp-impl.h(117) : fatal error C1083: Cannot open
> include file: 'gmp-mparam.h': No such file or directory
>
> casevh
>

Hi Case

Did you do a 'make clean' before these builds?

What can happen is that some files don't get built if they already
exist and this can lead to a situation where a build is done with the
wrong config.h and gmp-mparam.h files.

Brian

[Case Vanhorsen]

I am doing a "make clean" between attempts. I've even removed the
entire source directory and untarred the source distribution again.

[Cactus]

On Jun 9, 3:02 pm, Case Vanhorsen <cas...@gmail.com> wrote:

> > For more options, visit this group athttp://groups.google.com/group/mpir-devel?hl=en.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -

>
> - Show quoted text -

HI Case

I have reproduced this now and I know what is happening but not yet
why :-(

I have a prebuild step that is supposed to copy the correct gmp-
mparam.h file into the build directory before the build starts but
there is already one there and it is not overwriting it for some
reason. I would be interessted to know if the build succeeds if you
delete the gmp-mparam.h file in builkd.vc9 before you start the build.

Brian

[Cactus]

> > > For more options, visit this group athttp://groups.google.com/group/mpir-devel?hl=en.-Hide quoted text -

>
> > - Show quoted text -- Hide quoted text -
>
> > - Show quoted text -
>
> HI Case
>
> I have reproduced this now and I know what is happening but not yet
> why :-(
>
> I have a prebuild step that is supposed to copy the correct gmp-
> mparam.h file into the build directory before the build starts but
> there is already one there and it is not overwriting it for some
> reason.    I would be interessted to know if the build succeeds if you
> delete the gmp-mparam.h file in builkd.vc9 before you start the build.
>

>    Brian- Hide quoted text -
>
> - Show quoted text -

This is a major failure - ALL the WIndows builds now fail 25 tests
even though nothing Windows specific has changed recently.

It appears to be related to the division code in some way :-(

Brian

[Case Vanhorsen]

I'm at work now so I won't be able to test until this evening.

[Cactus]

On Jun 9, 4:22 pm, Case Vanhorsen <cas...@gmail.com> wrote:

> >> > For more options, visit this group athttp://groups.google.com/group/mpir-devel?hl=en.-Hide quoted text -

>
> >> - Show quoted text -- Hide quoted text -
>
> >> - Show quoted text -
>
> > HI Case
>
> > I have reproduced this now and I know what is happening but not yet
> > why :-(
>
> > I have a prebuild step that is supposed to copy the correct gmp-
> > mparam.h file into the build directory before the build starts but
> > there is already one there and it is not overwriting it for some
> > reason.    I would be interessted to know if the build succeeds if you
> > delete the gmp-mparam.h file in builkd.vc9 before you start the build.
>
> I'm at work now so I won't be able to test until this evening.

The Core2 and nehalem builds work fine but the k8 and k10 builds
fail.

It appears that simply copying the Linux k8/k10 gmp-mparam.h file into
the Windows builds - as I have always done before - no longer works
for the k8 and the K10 :(

Brian

[Cactus]

> > >> > For more options, visit this group athttp://groups.google.com/group/mpir-devel?hl=en.-Hidequoted text -

>
> > >> - Show quoted text -- Hide quoted text -
>
> > >> - Show quoted text -
>
> > > HI Case
>
> > > I have reproduced this now and I know what is happening but not yet
> > > why :-(
>
> > > I have a prebuild step that is supposed to copy the correct gmp-
> > > mparam.h file into the build directory before the build starts but
> > > there is already one there and it is not overwriting it for some
> > > reason.    I would be interessted to know if the build succeeds if you
> > > delete the gmp-mparam.h file in builkd.vc9 before you start the build.
>
> > I'm at work now so I won't be able to test until this evening.
>
> The Core2 and nehalem builds work fine but the k8 and k10 builds
> fail.
>
> It appears that simply copying the Linux k8/k10 gmp-mparam.h file into
> the Windows builds - as I have always done before - no longer works
> for the k8 and the K10 :(
>

>       Brian- Hide quoted text -
>
> - Show quoted text -

Ok, I've found the problem.

There is a long standing but latent bug in my Windows assembler code
that has only now been triggered because of recent changes in higher
level code.

In outline the K8/K10 mpn_sublsh_n function entry point (in the file
mpn\x86_64w\k8sublsh_n.asm) was not being set up correctly.

I will correct this in SVN within the next few minutes.

I am afraid, Minh, that this is serious enough to require either a re-
release of MPIR 2.1.0 or a step release.

My apologies to all for not picking this up prior to the release - I
would have done so in the past but all my K8 machines have gone to
meet their maker :-(

Brian

[Case Vanhorsen]

I would prefer if the new release is called 2.1.1. One a source
distribution has been published, I don't think we should change the
contents of the file without changing the version number too.

>
> My apologies to all for not picking this up prior to the release - I
> would have done so in the past but all my K8 machines have gone to
> meet their maker :-(
>
>     Brian
>

[Cactus]

On Jun 9, 5:49 pm, Minh Nguyen <nguyenmi...@gmail.com> wrote:
> Hi Brian,
>
> On Thu, Jun 10, 2010 at 2:19 AM, Cactus <rieman...@gmail.com> wrote:
>
> <SNIP>

>
> > I am afraid, Minh, that this is serious enough to require either a re-
> > release of MPIR 2.1.0 or a step release.
>

> How about a quick MPIR 2.1.1 bug fix release? Just tell me when you're
> done with fixing the above bug, and I'll announce an RC for testing.
> When things looks OK, we could announce an MPIR 2.1.1 bug fix release.
>
> I have updated the list of known issues on the MPIR website.
>
> --
> Regards
> Minh Van Nguyen

Its all done in SVN now. I have added better Python detection to the
command line build scripts.

Only Windows x64 builds for K8 and K10 need testing so a short RC
cycle should be fine.

Sorry for the extra work. And thanks to Case for finding this bug
quickly.

Brian

[Bill Hart]

Yep, this will only affect the Windows build, so no need for a full
round of testing. Simply do a sample linux build on sage.math just to
make sure something unexpected didn't happen and then call for a round
of Windows testing.

It should be called 2.1.1 which means running the setversion script again etc.

Bill.