On Jun 9, 4:29 pm, Cactus <[email protected]> wrote:
> On Jun 9, 4:22 pm, Case Vanhorsen <[email protected]> wrote:
>
>
>
>
>
> > On Wed, Jun 9, 2010 at 7:19 AM, Cactus <[email protected]> wrote:
>
> > > On Jun 9, 3:02 pm, Case Vanhorsen <[email protected]> wrote:
> > >> On Wed, Jun 9, 2010 at 6:47 AM, Cactus <[email protected]> wrote:
>
> > >> > On Jun 9, 2:31 pm, Case Vanhorsen <[email protected]> wrote:
> > >> >> On Wed, Jun 9, 2010 at 5:33 AM, Cactus <[email protected]> wrote:
>
> > >> >> > On Jun 9, 11:33 am, Cactus <[email protected]> wrote:
> > >> >> >> On Jun 9, 8:06 am, Case Vanhorsen <[email protected]> wrote:
>
> > >> >> >> > 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
>
> > >> >> >> 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- 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.
>
> > >> >> 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 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.
>
> > >> I am doing a "make clean" between attempts. I've even removed the
> > >> entire source directory and untarred the source distribution again.
>
> > >> 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 [email protected].
> > >> > To unsubscribe from this group, send email to
> > >> > [email protected].
> > >> > 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
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
