Re: MPIR 2.1.0-rc1 released
Cactus
On May 26, 8:00 am, Minh Nguyen <nguyenmi...@gmail.com> wrote:
> Hi folks,
>
> MPIR 2.1.0-rc1 was released on 25th May 2010.
>
> Source:http://www.mpir.org/mpir-2.1.0-rc1.tar.gz
>
> Documentation:http://www.mpir.org/mpir-2.1.0.pdf
>
> The main features and changes in this release cycle are:
>
> * Fixed the xgcd normalisation issue and redid the tuning code for gcd and xgcd
> * Fixes for compiling with GCC 4.5.0 on Itanium
> * Set default flags for GCC to -O2 on Itanium as GCC 4.5.0 fails to handle -O3
> * Experimental build with Visual Studio 2010
> * Removed all old gcdext_threshold that were set to zero
> * Changed all mpn_sqr_n to mpn_sqr
>
> The changelog for the MPIR 2.1.0 release cycle is available at
>
> http://www.mpir.org/changes.html
>
> If it is missing something, please report to this list. Please test
> and report all issues.
>
> As I'm progressing in managing this release cycle, I'm fleshing out
> details on issuing an MPIR release. The current document [1] is a work
> in progress and based on Bill's recent post [2] in which he outlines
> necessary workflows. Comments, suggestions, or enhancements are
> welcome.
>
> [1]http://www.mpir.org/release.html
>
> [2]http://groups.google.com/group/mpir-devel/browse_thread/thread/f939c5...
>
> --
> Regards
> Minh Van Nguyen
Hi Minh,
Congratulations on your progress in taking on the release management
role!
There was a minor error in 'setversion' that meant that the Windows
version string was not being set.
I think (maybe 'hope' as I am not a frequent user of Unix text
processing tools) I have corrected setversion and gmp-h.in in the SVN
repository accordingly.
Brian
Jason Moxham
On Wednesday 26 May 2010 09:29:49 Cactus wrote:PASS: t-dc_bdiv_q_n
PASS: t-dc_bdiv_qr_n
PASS: t-dc_bdiv_qr
PASS: t-dc_bdiv_q
/bin/sh: line 4: 617 Segmentation fault ${dir}$tst
FAIL: t-gcdext
PASS: st_fat
PASS: st_instrument
=============================================================
1 of 48 tests failed
Please report to http://groups.google.co.uk/group/mpir-devel/
=============================================================
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory
`/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsystem/tests/mpn'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory
`/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsystem/tests/mpn'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory
`/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsystem/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsystem'
make: *** [check] Error 2
sca-m0n8.scsystem
FAILED CC=gcc CXX=g++ configure=
jasonmoxham@sca-m0n8 ~/mpir/branches/test_stuff $
We need a better set of default params , we cant have gcdext crashing on any
system we havent tuned.
Note varro gives some spurious errors sometimes , they go away when you retry
the operation , this must be something to do with NFS
looks fine to me
>
> Brian
Jason Moxham
gcc -std=gnu99 -m64 -mcpu=970 -O3 -o .libs/t-gcdext t-gcdext.o
../../tests/.libs/libtests.a
/home/jasonmoxham/mpir/branches/test_stuff/varro/.libs/libmpir.dylib
../../.libs/libmpir.dylib
creating t-gcdext
make check-TESTS
PASS: t-asmtype
PASS: t-aors_1
PASS: t-divrem_1
PASS: t-fat
PASS: t-get_d
PASS: t-instrument
PASS: t-iord_u
PASS: t-mulmid
PASS: t-mp_bases
PASS: t-perfsqr
PASS: t-scan
PASS: t-lorrshift1
PASS: t-divebyff
PASS: t-addadd_n
PASS: t-addsub_n
PASS: t-subadd_n
PASS: t-redc_basecase
PASS: t-divebyBm1of
PASS: t-mullowhigh
PASS: t-mullow_basecase
PASS: t-neg
PASS: t-mulmod_2expp1
PASS: t-mulmod_2expm1
PASS: t-tdiv_q
PASS: t-sb_divappr_q
PASS: t-dc_divappr_q_n
PASS: t-inv_divappr_q_n
PASS: t-invert
PASS: t-sb_div_q
PASS: t-sb_div_qr
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
FAIL: t-dc_div_q
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
FAIL: t-dc_div_qr
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
FAIL: t-dc_divappr_q
PASS: t-dc_div_qr_n
PASS: t-inv_divappr_q
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
FAIL: t-inv_div_q
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
FAIL: t-inv_div_qr
PASS: t-inv_div_qr_n
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
FAIL: t-tdiv_qr
PASS: t-sb_bdiv_q
PASS: t-sb_bdiv_qr
PASS: t-dc_bdiv_q_n
PASS: t-dc_bdiv_qr_n
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
FAIL: t-dc_bdiv_qr
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
FAIL: t-dc_bdiv_q
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
FAIL: t-gcdext
PASS: st_fat
PASS: st_instrument
=============================================================
Please report to http://groups.google.co.uk/group/mpir-devel/
=============================================================
make[4]: *** [check-TESTS] Error 1
varro
PASSED CC=gcc CXX=g++ configure=
PASSED CC=gcc CXX=g++ configure= --enable-cxx --enable-gmpcompat
FAILED CC=gcc CXX=g++ configure= --enable-cxx --enable-gmpcompat --enable-
assert --enable-alloca=debug
This is on varro 64 bit ie mpn/powerpc64/gmp-mparam.h
and this has been tuned
On Wednesday 26 May 2010 13:23:25 Jason Moxham wrote:
> This on Cato , note make tune fails on cato , so we cannot tune the
> parameters
>
>
> On Wednesday 26 May 2010 09:29:49 Cactus wrote:PASS: t-dc_bdiv_q_n
> PASS: t-dc_bdiv_qr_n
> PASS: t-dc_bdiv_qr
> PASS: t-dc_bdiv_q
> /bin/sh: line 4: 617 Segmentation fault ${dir}$tst
> FAIL: t-gcdext
> PASS: st_fat
> PASS: st_instrument
> =============================================================
> 1 of 48 tests failed
> Please report to http://groups.google.co.uk/group/mpir-devel/
> =============================================================
> make[4]: *** [check-TESTS] Error 1
> make[4]: Leaving directory
> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsystem/tests/
>mpn' make[3]: *** [check-am] Error 2
> make[3]: Leaving directory
> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsystem/tests/
>mpn' make[2]: *** [check-recursive] Error 1
> > >5. ..
Bill Hart
called are in mul.c and mul_n.c, and directly from toom8h_mul.c
itself.
In all cases, it is impossible, with those thresholds, to have bn < 86.
Something is definitely going wrong. Either it is picking up the wrong
tuning values somehow, the library needs rebuilding, there is a
compiler bug, something is wrong with the assert. I don't know.
But I'm pretty confident it is not a bug in the way the thresholds are handled.
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.
> For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
>
>
Jason Moxham
> I've checked the code over and the only places this function is even
> called are in mul.c and mul_n.c, and directly from toom8h_mul.c
> itself.
>
> In all cases, it is impossible, with those thresholds, to have bn < 86.
>
> Something is definitely going wrong. Either it is picking up the wrong
> tuning values somehow, the library needs rebuilding, there is a
> compiler bug, something is wrong with the assert. I don't know.
>
> But I'm pretty confident it is not a bug in the way the thresholds are
> handled.
>
> Bill.
I forced boxen to use those gmp-mparam values , and I got the assertion
failure again , so those values are bad , I will retune again
> >>ts/ mpn' make[3]: *** [check-am] Error 2
> >> make[3]: Leaving directory
> >> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsystem/tes
> >>ts/ mpn' make[2]: *** [check-recursive] Error 1
> >> make[2]: Leaving directory
> >> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsystem/tes
> >>ts' make[1]: *** [check-recursive] Error 1
> >> > >39c 5. ..
Bill Hart
Which tuning values did you change for boxen which caused the issue to
show up there?
It must be one of the division cutoffs is wrong. That must cause a
negative value to be passed for bn to toom8h_mul or something. But
that is something we'll want to fix.
Bill.
Bill Hart
look ok to me. The dc division code doesn't get unhappy until the
number of limbs gets to about 6 and the cutoff there is 21.
It looks like the failure must be triggered by either line 134 or 136
of dc_divappr_q.c
So you have qn = nn - dn (line 48), thus qn >= 3 (line 45). But dn >=
6 (line 44) and qn >= dn (line 53) . But line 59, qn is reduced to be
<= dn, but not 0, (or 1 see line 67). But then qn < dn (line 131).
Then bn is either dn - qn or qn, depending on which is smaller.
Hmm. Don't see how there can be an issue. :-(
Bill.
Jason Moxham
> But that is a serious problem!
>
> Which tuning values did you change for boxen which caused the issue to
> show up there?
i just copied powerpc64/gmp-mparam.h to x86_64/core2/penryn/gmp-mparam.h
I can try a few at a time , to see if we can narrow it down
> >> >>tes ts/ mpn' make[3]: *** [check-am] Error 2
> >> >> make[3]: Leaving directory
> >> >> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsystem/
> >> >>tes ts/ mpn' make[2]: *** [check-recursive] Error 1
> >> >> make[2]: Leaving directory
> >> >> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsystem/
> >> >>tes ts' make[1]: *** [check-recursive] Error 1
> >> >> > >/f9 39c 5. ..
Jason Moxham
#define MUL_TOOM8H_THRESHOLD 224
to
#define MUL_TOOM8H_THRESHOLD 173
so that it matches powerpc64
then we get the assertion failure
and it still happens if I change all the mul params over
> > >> >>m/ tes ts/ mpn' make[3]: *** [check-am] Error 2
> > >> >> make[3]: Leaving directory
> > >> >> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsyste
> > >> >>m/ tes ts/ mpn' make[2]: *** [check-recursive] Error 1
> > >> >> make[2]: Leaving directory
> > >> >> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsyste
> > >> >>m/ tes ts' make[1]: *** [check-recursive] Error 1
> > >> >> make[1]: Leaving directory
> > >> >> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scsyste
> > >> >>m' make: *** [check] Error 2
> > >> >> > >ad /f9 39c 5. ..
Bill Hart
I don't see how the function can ever be called with bn < 86.
Scratches head.... I must be missing something obvious....
Bill.
Bill Hart
Here is a fix:
lines 149-153 of mpn/mul.c need to be:
#if GMP_NUMB_BITS == 32
if ((ABOVE_THRESHOLD (un + vn, 2*MUL_TOOM8H_THRESHOLD)) && (vn >=
86) && (5*un <= 11*vn))
#else
if ((ABOVE_THRESHOLD (un + vn, 2*MUL_TOOM8H_THRESHOLD)) && (vn >=
86) && (4*un <= 13*vn))
#endif
The problem occurs when un is very large and vn is small, but the sum
still over the threshold.
Better still, could replace that 86 with TOOM8H_MIN_SIZE in gmp-impl.h
or something.
Bill.
Jason Moxham
thanks
Jason
> >>> > >> >ylib ../../.libs/libmpir.dylib
> >>> > >> >>yste m/ tes ts/ mpn' make[3]: *** [check-am] Error 2
> >>> > >> >> make[3]: Leaving directory
> >>> > >> >> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scs
> >>> > >> >>yste m/ tes ts/ mpn' make[2]: *** [check-recursive] Error 1
> >>> > >> >> make[2]: Leaving directory
> >>> > >> >> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scs
> >>> > >> >>yste m/ tes ts' make[1]: *** [check-recursive] Error 1
> >>> > >> >> make[1]: Leaving directory
> >>> > >> >> `/.root0/home/jasonmoxham/mpir/branches/test_stuff/sca-m0n8.scs
> >>> > >> >>yste m' make: *** [check] Error 2
> >>> > >> >> > >thre ad /f9 39c 5. ..
Jeff Gilchrist
> MPIR 2.1.0-rc1 was released on 25th May 2010.
Here are some testing results with: configure -enable-cxx; make; make check.
- Linux 64bit - Core2 - icc (ICC) 11.0 20090318
All tests passed
- Linux 64bit - Core2 - gcc version 4.1.2 20080704
All tests passed
- Linux 64bit - Itanium2 - icc (ICC) 11.0 20090318
All tests passed
- Linux 64bit - Itanium2 - gcc version 4.1.2 20070115
All tests passed
- Linux 64bit - K8 - gcc version 3.4.6 20060404
All tests passed
Jeff.
Jason Moxham
On t2 64bit
PASS: t-dc_bdiv_qr
PASS: t-dc_bdiv_q
gcdext.c:1156: GNU MP assertion failed: an >= n
/bin/bash: line 1: 5208 Abort (core dumped) ${dir}$tst
FAIL: t-gcdext
PASS: st_fat
PASS: st_instrument
=============================================================
1 of 48 tests failed
Please report to http://groups.google.co.uk/group/mpir-devel/
=============================================================
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory `/scratch/jason/t2/tests/mpn'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/scratch/jason/t2/tests/mpn'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/scratch/jason/t2/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/scratch/jason/t2'
make: *** [check] Error 2
t2
PASSED CC=gcc CXX=g++ configure=
PASSED CC=gcc CXX=g++ configure= --enable-cxx --enable-gmpcompat
FAILED CC=gcc CXX=g++ configure= --enable-cxx --enable-gmpcompat --enable-
assert --enable-alloca=debug
the tuning has been done (on mark.skynet) so params should be correct
Jason Moxham
PASS: t-redc_basecase
PASS: t-divebyBm1of
mulhigh_n.c:106: GNU MP assertion failed: n >= 3
/bin/bash: line 1: 16923 Abort (core dumped) ${dir}$tst
FAIL: t-mullowhigh
PASS: t-neg
PASS: t-mulmod_2expp1
PASS: t-mulmod_2expm1
PASS: t-tdiv_q
PASS: t-sb_divappr_q
PASS: t-dc_divappr_q_n
PASS: t-inv_divappr_q_n
PASS: t-invert
PASS: t-sb_div_q
PASS: t-sb_div_qr
PASS: t-dc_div_qr
PASS: t-dc_divappr_q
PASS: t-dc_div_qr_n
PASS: t-inv_divappr_q
PASS: t-inv_div_q
PASS: t-inv_div_qr
PASS: t-inv_div_qr_n
PASS: t-tdiv_qr
PASS: t-sb_bdiv_q
PASS: t-sb_bdiv_qr
PASS: t-dc_bdiv_q_n
PASS: t-dc_bdiv_qr_n
PASS: t-dc_bdiv_q
PASS: t-gcdext
PASS: st_fat
PASS: st_instrument
=============================================================
1 of 48 tests failed
Please report to http://groups.google.co.uk/group/mpir-devel/
=============================================================
make[4]: *** [check-TESTS] Error 1
make[3]: *** [check-am] Error 2
make[2]: *** [check-recursive] Error 1
make[1]: *** [check-recursive] Error 1
make: *** [check] Error 2
t2
PASSED CC=gcc CXX=g++ configure=ABI=32
PASSED CC=gcc CXX=g++ configure=ABI=32 --enable-cxx --enable-gmpcompat
FAILED CC=gcc CXX=g++ configure=ABI=32 --enable-cxx --enable-gmpcompat --
enable-assert --enable-alloca=debug
We have seen this error before , it's just the tuning on t2 32bit doesn't
exclude that trivial case , we just manually fixed the param file last time ,
mulhigh is not used internally at the mo , and it's not documented so it wont
effect any code , i'll fix it manually now , and try and work out why the tuning
for it is broken (on sparc only)
I think we should have a automatic mechanism for checking that the thresholds
that mpir builds with satisfy all the restrictions even when we dont build
with --enable-assert , something like
CHECK_ASSERT(threshold_kara >=2 ) in the mul_n.c
which are empty macros for building mpir
and a script(python?) that extracts all out into one big c file , compiles and
runs it at build time to see if it is satisfied (check_assert macro not empty)
Jason
Bill Hart
Bill Hart
before line 155 of tests/mpn/t-gcdext.c just put if (un < vn)
continue;
Bill.
Jason Moxham
> You can set minimum values in tuneup.c itself.
>
it's already set to 3 , just wonder why it not doing what it should . I looked
at this before , but clearly gave up. lazy boy....
a script is an overkill , something simple like
cat *.c | grep -e CHECK_ASSERT > check.c
gcc -DCHECK_ASSERT(x)=etc... check.c
as part of the prebuild ie with fac_ui.h etc
I was pondering getting rid of the prebuild (among other things), to simplify
the excessively complicated configure mechanism , or rather moving it into the
predist phase (ie in make dist) . At the mo configure has to run on all systems
, which means that we get odd errors on some systems that arn't tested much
like bsd/solaris/mingw. If we push all the complicated configure bits into make
dist then we only have to make them work on common systems(linux :) (OK
windows if you want ) ( I joke , but modern , bug fixed systems ,
linux/cygwin/solaris?) . Note we dont have to push all the complicated
configure mechanism out of the way , just the bits that arn't maintained by the
GNU foundation , ie just the existing gmp extensions . Other advantages are we
can upgrade easily to the latest gnulib,autotools etc .
Enough prattle for now....
Jason Moxham
chrmhoffmann
I am building with vs2010 and the build works fine. I have just a
question regarding the vsyasm.exe. I don't really like the idea that I
have to put the vsyasm.exe in the visual studio installation path.
Can't the solution just pick whatever vsyasm.exe that is in the PATH?
Or at least have it configurable with envinronment variable? Some
users may not have administrator rights on their development boxes and
can't modify the installation.
Thanks,
Chris
Cactus
Hi Chris,
You can change the vsyasm location by editing the vsyasm path set in
the <CommandLineTemplate> line in the vsyasm.props file.
The use of the VC++ tools path is a convenient location because this
is where the default path where the IDE looks for tools.
I'll look at the possibility of allowing an environment variable to
override the default.
Brian
Cactus
Ok, I've made a change to vsyasm.props in the MPIR repository that
adds the ability to override the default vsyasm path.
If the environment variable YASMPATH is set to the directory
(including the final backslash) where vsyasm is located, this will
override the default vsyasm location.
Brian
chrmhoffmann
> Ok, I've made a change to vsyasm.props in the MPIR repository that
> adds the ability to override the default vsyasm path.
>
> If the environment variable YASMPATH is set to the directory
> (including the final backslash) where vsyasm is located, this will
> override the default vsyasm location.
Hi,
thanks. That seems to work. I would have preferred without \ as this
is always a bit confusing. I would also suggest that the configure.bat
would then use same YASMPATH environment variable instead of YASM.
BTW: that configure.bat is giving a cryptic error message ("The syntax
of the command is incorrect."), if YASM environment variable is not
set. I guess it gets confused in line 92 in the "if" statement.
Regards and thanks,
Chris
chrmhoffmann
I am now trying to compile with win x64 and I have problems doing
that. With the native x64 compiler I am running into a problem with
the TRACKER.
The error message is:
1>------ Build started: Project: gen-mpir, Configuration: Debug Win32
------
1>Build started 5/27/2010 3:45:07 PM.
1>InitializeBuildStatus:
1> Touching "Win32\Debug\gen-mpir.unsuccessfulbuild".
1>TRACKER : error TRK0002: Failed to execute command: ""C:\Program
Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\CL.exe" @C:\Users
\hoffmann\AppData\Local\Temp\dde019b3422e463eb47e508fcc2c70e8.rsp".
The handle is invalid.
(I think this is maybe similar problem as described here:
https://connect.microsoft.com/VisualStudio/feedback/details/543804/?wa=wsignin1.0).
If I use the x64 cross compiler, I run into the following issue when
compiling e.g. the dll_mpir_nehalem project:
1>Win32\Debug\gen-mpir.obj : fatal error LNK1112: module machine type
'x64' conflicts with target machine type 'X86'
It looks like the common projects: gen-bases, gen-fac_ui, gen-fib, gen-
mpir and gen-psqr don't have a x64 configuration.
Regards,
Chris
Cactus
The trailing backslash is there to conform to the Visual Studio path
conventions.
The command line stuff is Jason's so I will leave him to sort it out.
Brian
Cactus
On May 27, 2:46 pm, chrmhoffmann <chrmhoffm...@gmail.com> wrote:
> Hi again,
>
> I am now trying to compile with win x64 and I have problems doing
> that. With the native x64 compiler I am running into a problem with
> the TRACKER.
> The error message is:
> 1>------ Build started: Project: gen-mpir, Configuration: Debug Win32
> ------
> 1>Build started 5/27/2010 3:45:07 PM.
> 1>InitializeBuildStatus:
> 1> Touching "Win32\Debug\gen-mpir.unsuccessfulbuild".
> 1>TRACKER : error TRK0002: Failed to execute command: ""C:\Program
> Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\CL.exe" @C:\Users
> \hoffmann\AppData\Local\Temp\dde019b3422e463eb47e508fcc2c70e8.rsp".
> The handle is invalid.
>
> (I think this is maybe similar problem as described here:https://connect.microsoft.com/VisualStudio/feedback/details/543804/?w...).
>
> If I use the x64 cross compiler, I run into the following issue when
> compiling e.g. the dll_mpir_nehalem project:
>
> 1>Win32\Debug\gen-mpir.obj : fatal error LNK1112: module machine type
> 'x64' conflicts with target machine type 'X86'
>
> It looks like the common projects: gen-bases, gen-fac_ui, gen-fib, gen-
> mpir and gen-psqr don't have a x64 configuration.
Hi Chris,
The prebuild files don't have x64 configurations as they are not
architecture dependent - hence I just run them as win32
applications.
I have just cleaned and built dll_mpir_nehalem project and its works
fine here. It invokes the prebuild files as win32 projects without
any problems.
Brian
Cactus
It shouldn't be necessary but I have added x64 configurations to the
pre-build steps to see if it solves your problem.
Brian
>
> Brian
Jeff Gilchrist
> MPIR 2.1.0-rc1 was released on 25th May 2010.
Mac OSX test results:
- OSX Leopard - gcc version 4.0.1 (Apple Inc. build 5493) - 64bit Core2
All tests passed
- OSX Leopard - gcc version 4.0.1 (Apple Inc. build 5493) - 32bit Core2
All tests passed
Windows test results:
- Windows 7 - Visual Studio 2010 - 64bit Core2
All tests passed
- Windows 7 - Visual Studio 2010 - 32bit Pentium 4
All tests passed
- Windows 7 - Visual Studio 2008 - 64bit Core2
All tests passed
- Windows 7 - Visual Studio 2008 - 32bit Pentium 4
All tests passed
- Cygwin32 - gcc version 3.4.4 (cygming special, gdc 0.12, using dmd
0.125) - 32bit Core2
All tests passed
Jeff.
chrmhoffmann
> It shouldn't be necessary but I have added x64 configurations to the
> pre-build steps to see if it solves your problem.
Hi,
That works for me now and all tests pass OK. I don't know why we see
different behavior. Anyway. Thanks.
Regards,
Chris
jason
Jason
jason
>
>
> Documentation:http://www.mpir.org/mpir-2.1.0.pdf
>
> The main features and changes in this release cycle are:
>
> * Fixed the xgcd normalisation issue and redid the tuning code for gcd and xgcd
> * Fixes for compiling with GCC 4.5.0 on Itanium
> * Set default flags for GCC to -O2 on Itanium as GCC 4.5.0 fails to handle -O3
> * Experimental build with Visual Studio 2010
> * Removed all old gcdext_threshold that were set to zero
> * Changed all mpn_sqr_n to mpn_sqr
Thanks
Jason
Bill Hart
case in inv_divappr_q.c. I'll have to figure out which other files are
affected by the same bug. I likely copied this from somewhere.
I've committed a fix to svn anyhow.
Bill.
On 29 May 2010 17:11, Minh Nguyen <nguye...@gmail.com> wrote:
> Hi Jason,
>
> On Sun, May 30, 2010 at 1:18 AM, jason <ja...@njkfrudils.plus.com> wrote:
>
> <SNIP>
>
>> Some suggested changes
>
> The news section [1] and changelog [2] have been updated. Thank you.
>
> [1] http://www.mpir.org
>
> [2] http://www.mpir.org/changes.html
>
> --
> Regards
> Minh Van Nguyen
>
Bill Hart
All tests pass on my machine and on sextus.
Bill.
Bill Hart
(i.e. ones that aren't due to incorrectly set up machines or bugs in
gcc and excluding duplicates):
* gcc55 - undefined reference to _gmpn_invert_limb
* cicero - t-dc_bdiv_q
inv_divappr_q.c:45: GNU MP assertion failed: dn >= 6
* t-dc_bdiv_q
/bin/sh: line 4: 10641 Segmentation fault (probably a tuning issue
- tuning code broken)
* rosemary
redefinition of ‘__gmpn_divrem_hensel_qr_1 (will need access to be
able to fix this)
* bsd.math
Invalid configuration `longlong-apple-darwin10.3.0
* gcc 101
ylwrap: No such file or directory (probably automake --addmissing
will fix this, but we'd need to put ylwrap under version control?)
* t2
Invalid configuration `longlong-sun-solaris2.10
Bill.
Bill Hart
> So here's a summary of the remaining bugs that we can actually fix
> (i.e. ones that aren't due to incorrectly set up machines or bugs in
> gcc and excluding duplicates):
>
> * gcc55 - undefined reference to _gmpn_invert_limb
>
For this one, the file being compiled is tests/t-bswap.c, which
doesn't actually use mpn_invert_limb as fas as I can see. So this is a
linker error.
Perhaps to fix it we can put:
#if defined (invert_limb)
#define mpn_invert_limb __MPN(invert_limb)
#endif
on line 2526 of gmp-impl.h? Should that work?
Bill.
Bill Hart
> (i.e. ones that aren't due to incorrectly set up machines or bugs in
> gcc and excluding duplicates):
>
> * gcc55 - undefined reference to _gmpn_invert_limb
>
> * cicero - t-dc_bdiv_q
> inv_divappr_q.c:45: GNU MP assertion failed: dn >= 6
I've fixed this in svn. It was in fact a missing check for that case.
Bill Hart
> (i.e. ones that aren't due to incorrectly set up machines or bugs in
> gcc and excluding duplicates):
>
> * gcc55 - undefined reference to _gmpn_invert_limb
>
> * cicero - t-dc_bdiv_q
> inv_divappr_q.c:45: GNU MP assertion failed: dn >= 6
>
> * t-dc_bdiv_q
> /bin/sh: line 4: 10641 Segmentation fault (probably a tuning issue
> - tuning code broken)
Actually, this seems to be a duplicate bug. I think it is already fixed now.
I think I have fixed all the really difficult bugs now. I suspect
Jason will have no problems with the remainder.
I will be marking exams for about the next week or so, thus I won't be
able to work on fixing any more bugs unless they become urgent
somehow.
Bill.
Jason Moxham
> So here's a summary of the remaining bugs that we can actually fix
> (i.e. ones that aren't due to incorrectly set up machines or bugs in
> gcc and excluding duplicates):
>
> * gcc55 - undefined reference to _gmpn_invert_limb
>
> * cicero - t-dc_bdiv_q
> inv_divappr_q.c:45: GNU MP assertion failed: dn >= 6
>
> * t-dc_bdiv_q
> /bin/sh: line 4: 10641 Segmentation fault (probably a tuning issue
> - tuning code broken)
>
> * rosemary
> redefinition of ‘__gmpn_divrem_hensel_qr_1 (will need access to be
> able to fix this)
>
> * bsd.math
> Invalid configuration `longlong-apple-darwin10.3.0
>
> * gcc 101
> ylwrap: No such file or directory (probably automake --addmissing
> will fix this, but we'd need to put ylwrap under version control?)
>
ylwrap is in rc1, we can still add it to the svn though , otherwise we will
need to --add-missing every time we make dist , however for the bsd error I
dont know what is going on here , there appear to be similar errors reported
on the web but it doesn't look like any help , I assume ylwrap got unpacked
properly and the system didn't run out of disk quota or some such?
> * t2
> Invalid configuration `longlong-sun-solaris2.10
>
fixed the test script
Bill Hart
> On Tuesday 01 June 2010 00:16:06 Bill Hart wrote:
>> So here's a summary of the remaining bugs that we can actually fix
>> (i.e. ones that aren't due to incorrectly set up machines or bugs in
>> gcc and excluding duplicates):
>>
>> * gcc55 - undefined reference to _gmpn_invert_limb
>>
>> * cicero - t-dc_bdiv_q
>> inv_divappr_q.c:45: GNU MP assertion failed: dn >= 6
>>
>> * t-dc_bdiv_q
>> /bin/sh: line 4: 10641 Segmentation fault (probably a tuning issue
>> - tuning code broken)
>>
>> * rosemary
>> redefinition of ‘__gmpn_divrem_hensel_qr_1 (will need access to be
>> able to fix this)
So if we can get access to rosemary, (Minh?) we can see what is the
cause of this, and I think it will be time for another RC.
>>
>> * bsd.math
>> Invalid configuration `longlong-apple-darwin10.3.0
>>
> fixed the test script
>
>> * gcc 101
>> ylwrap: No such file or directory (probably automake --addmissing
>> will fix this, but we'd need to put ylwrap under version control?)
>>
> ylwrap is in rc1, we can still add it to the svn though , otherwise we will
> need to --add-missing every time we make dist , however for the bsd error I
> dont know what is going on here , there appear to be similar errors reported
> on the web but it doesn't look like any help , I assume ylwrap got unpacked
> properly and the system didn't run out of disk quota or some such?
OK, so this one looks like a BSD related bug to do with autotools. I
would recommend creating a ticket, adding it to the list of "Known
Problems" on the website and move on. I don't think it is worth
spending the time screwing around with this at this point. No sense in
holding up the majority of users for a handful.
Having said that, it might be interesting to see if GMP suffers from
the same problem on this machine, and if not, try to determine why.
Jason Moxham
> On 1 June 2010 00:16, Bill Hart <goodwi...@googlemail.com> wrote:
> > So here's a summary of the remaining bugs that we can actually fix
> > (i.e. ones that aren't due to incorrectly set up machines or bugs in
> > gcc and excluding duplicates):
> >
> > * gcc55 - undefined reference to _gmpn_invert_limb
>
> For this one, the file being compiled is tests/t-bswap.c, which
> doesn't actually use mpn_invert_limb as fas as I can see. So this is a
> linker error.
>
> Perhaps to fix it we can put:
>
> #if defined (invert_limb)
> #define mpn_invert_limb __MPN(invert_limb)
> #endif
>
> on line 2526 of gmp-impl.h? Should that work?
This is due to an invalid ABI , ie longlong , test script has been changed
back to none , this should work :)
Jason Moxham
> On 1 June 2010 14:20, Jason Moxham <ja...@njkfrudils.plus.com> wrote:
> > On Tuesday 01 June 2010 00:16:06 Bill Hart wrote:
> >> So here's a summary of the remaining bugs that we can actually fix
> >> (i.e. ones that aren't due to incorrectly set up machines or bugs in
> >> gcc and excluding duplicates):
> >>
> >> * gcc55 - undefined reference to _gmpn_invert_limb
> >>
> >> * cicero - t-dc_bdiv_q
> >> inv_divappr_q.c:45: GNU MP assertion failed: dn >= 6
> >>
> >> * t-dc_bdiv_q
> >> /bin/sh: line 4: 10641 Segmentation fault (probably a tuning issue
> >> - tuning code broken)
> >>
> >> * rosemary
> >> redefinition of ‘__gmpn_divrem_hensel_qr_1 (will need access to be
> >> able to fix this)
>
> So if we can get access to rosemary, (Minh?) we can see what is the
> cause of this, and I think it will be time for another RC.
>
this was only in make tune , so it's not the end of the world , I assume this
was with the normal ABI ? , can you(Minh) put the build log up? Thanks
> >> * bsd.math
> >> Invalid configuration `longlong-apple-darwin10.3.0
> >
> > fixed the test script
> >
> >> * gcc 101
> >> ylwrap: No such file or directory (probably automake --addmissing
> >> will fix this, but we'd need to put ylwrap under version control?)
> >
> > ylwrap is in rc1, we can still add it to the svn though , otherwise we
> > will need to --add-missing every time we make dist , however for the bsd
> > error I dont know what is going on here , there appear to be similar
> > errors reported on the web but it doesn't look like any help , I assume
> > ylwrap got unpacked properly and the system didn't run out of disk quota
> > or some such?
>
> OK, so this one looks like a BSD related bug to do with autotools. I
> would recommend creating a ticket, adding it to the list of "Known
> Problems" on the website and move on. I don't think it is worth
> spending the time screwing around with this at this point. No sense in
> holding up the majority of users for a handful.
>
> Having said that, it might be interesting to see if GMP suffers from
> the same problem on this machine, and if not, try to determine why.
>
I'll add ylwrap to svn in a mo , try mpir-2.0.0 which didn't use ylwrap , that
may nail it down easier.
Jason Moxham
cd tune
make clean
make tune
ie not using -j etc , We have had problems before with parallel build for make
tune , they tend to come and go , I suspect some part of Makefile is incorrect
, but it is very difficult to track down
parallel builds for yasm fails sometimes , but only on cygwin
Thanks
Jason
On Tuesday 01 June 2010 18:38:55 you wrote:
> Hi Jason,
>
> On Tue, Jun 1, 2010 at 11:47 PM, Jason Moxham <ja...@njkfrudils.plus.com>
> wrote:
>
> <SNIP>
>
> > this was only in make tune , so it's not the end of the world , I assume
> > this was with the normal ABI ? , can you(Minh) put the build log up?
> > Thanks
>
> You can find the configure, build, check, and tune logs of MPIR r2989 at
>
> http://sage.math.washington.edu/home/mvngu/doc/mpir/r2989/
>
> These logs were generated on the machine rosemary.math.
Bill Hart
We should be testing the tarball of course, not svn, which is not
quite the same. But I presume we were doing that for the last rc.
Bill.
On 1 June 2010 21:25, Minh Nguyen <nguye...@gmail.com> wrote:
> Hi Jason,
>
> On Wed, Jun 2, 2010 at 4:39 AM, Jason Moxham <ja...@njkfrudils.plus.com> wrote:
>> can you build make tune with just
>> cd tune
>> make clean
>> make tune
>>
>> ie not using -j etc , We have had problems before with parallel build for make
>> tune , they tend to come and go ,
>
> Retrying, I first checked out test_stuff and made the following
> commenting in mpirtest:
>
> CPUS=1
> COMP="gcc"
> #if [ -f /proc/cpuinfo ] ; then
> # CPUS=$(cat /proc/cpuinfo | grep -ce ^processor)
> #fi
>
> In all the test I ran on the reported machines, I did this and also
> commented out any part of mpirtest that set the number of CPUs to
> greater than 1. I used a script to run these in batch mode: check out
> trunk, configure, build, check, tune, run test suite. The test suite
> would fail if I don't set the number of CPUs to one. Anyway, after
> editing mpirtest as above, I set make to not use more than one thread
> and then proceeded to build. All this is on rosemary.math. In
> particular, after checking out test_stuff and edited mpirtest as
> above, I used the following script to check out trunk, configure,
> build, check, tune, run test suite:
>
> #!/usr/bin/env bash
>
> # no parallel build
> export MAKE='make'
> CHECKOUT_LOG='checkout.log'
> CONFIG_LOG='configure.log'
> MPIR='mpir'
> MPIR_ROOT=
> MPIR_SVN='http://boxen.math.washington.edu/svn/mpir/mpir'
> REVISION=
>
> # Get the current snapshot of MPIR
> echo 'Check out MPIR trunk...'
> svn checkout $MPIR_SVN/trunk $MPIR 2>&1 | tee -a $CHECKOUT_LOG
> #echo 'Check out test scripts...'
> #svn checkout $MPIR_SVN/branches/test_stuff test_stuff 2>&1 | tee -a
> checkout.log
> REVISION=`tail -1 $CHECKOUT_LOG | awk '{split($4, array, "."); print array[1]}'`
> echo $REVISION > $CHECKOUT_LOG
> mv $MPIR $MPIR"-r"$REVISION
>
> # Get tuning parameters
> BUILD_LOG='build-r'$REVISION'.log'
> CHECK_LOG='check-r'$REVISION'.log'
> MPIR_ROOT=$MPIR'-r'$REVISION
> MPIR_TUNE=$MPIR_ROOT'-tune'
> TUNE_LOG='tune-r'$REVISION'.log'
> cp -rf $MPIR_ROOT $MPIR_TUNE
> cd $MPIR_TUNE
> ./configure 2>&1 | tee -a ../$CONFIG_LOG
> ./config.guess 2>&1 | tee -a ../$BUILD_LOG
> make 2>&1 | tee -a ../$BUILD_LOG
> make check 2>&1 | tee -a ../$CHECK_LOG
> cd tune
> make tune 2>&1 | tee -a ../../$TUNE_LOG
> # ./tuneup -f 100000000 2>&1 | tee -a ../$TUNE_LOG
> cd ../..
>
> # Run the MPIR test suite
> MPIR_TEST=$MPIR_ROOT'-test'
> MPIR_TEST_ROOT='test_stuff'
> TEST_LOG='test-r'$REVISION'.log'
> cp -rf $MPIR_ROOT $MPIR_TEST
> cp -rf $MPIR_TEST_ROOT $MPIR_TEST_ROOT'-r'$REVISION
> cd $MPIR_TEST_ROOT'-r'$REVISION
> ./mpirtest ../$MPIR_TEST 2>&1 | tee -a ../$TEST_LOG
> cd ..
>
>
> All of the above steps went fine on rosemary.math now that used only
> one thread for building, tuning, and running the test suite. The
> configure, build, check, tune, and test logs are up at
>
> http://sage.math.washington.edu/home/mvngu/doc/mpir/r2989/
>
> I think I should make a point of building and running the test suite
> with only one thread from now on.
Jason Moxham
> This is great. If I am not mistaken, we are basically ready for an rc2
> right?
>
> We should be testing the tarball of course, not svn, which is not
> quite the same. But I presume we were doing that for the last rc.
>
svn runs make check for yasm , whereas tarball does not , plus of course if
make dist has missed any files.
Jason Moxham
> Hi Jason,
>
> > cd tune
> > make clean
> > make tune
> >
> > ie not using -j etc , We have had problems before with parallel build for
> > make tune , they tend to come and go ,
>
I think it should really build properly with a parallel build , the tools all
support it and it is the future , plus when I test things I want it to be
fast( for the nightly? builds it doesn't matter , noone is waiting for them to
finish) . If nfs is not working to well then the time stamps can make the
build go bad , eg on t2.math , so build on the local scratch disk. Otherwise
it should all work . make tune fails sometimes on a few machines (make speed
passes) , it looks like the makefile has some dependency or something mixed up.
Jason