For any Sage people reading this thread: MPIR now uses the same XGCD normalisation as GMP 5.0.1. but *NOT* previous versions (e.g. NOT GMP 5.0.0) and GMP 4.3.2. This is the normalisation Pari requires to operate correctly. It is expected that the XGCD normalisation is now fixed forever and will not change again in MPIR (and if we understand correctly from the GMP list, not in GMP either).
If you find a counterexample to that, please report the inputs you provide to the xgcd function and what GMP and MPIR return and we'll fix it. (We aren't expecting any counterexamples, as we have test code for this and have run hundreds of millions of XGCD's to check.) Bill. On 3 June 2010 18:11, Bill Hart <[email protected]> wrote: > A little bit more detail on the MPIR in Sage thing: > > It looks like MPIR 2.1.0 is slated to be released in Sage 5.0. It's > actually one of the main goals for that release. Woot!! > > http://trac.sagemath.org/sage_trac/milestone/sage-5.0 > > That's only two weeks away, and it takes nearly a week to do the > release *after* all the patches are written. So we need to release a > solid MPIR ASAP so they have time to fix the remaining issues in Sage. > > It looks like someone patched ECM in Sage already. But there are now > Sage doctest failures. In all likelihood these are due to GCD > normalisation, and will require the attention of the people involved > with writing the Sage doctests. I think this will get dealt with when > the Sage 5.0 release process starts. It's a one off job that the Sage > guys know needs to be done now that the GCD normalisation has been > changed back to the original. See the following for more details: > > http://trac.sagemath.org/sage_trac/ticket/8664 > > Note that MPIR 2.0.1. on that ticket is now meant to read 2.1.0. There > will be no MPIR 2.0.1. > > Bill. > > On 3 June 2010 17:43, Bill Hart <[email protected]> wrote: >> On 3 June 2010 15:00, Jason Moxham <[email protected]> wrote: >>> On Thursday 03 June 2010 04:58:30 Jason Moxham wrote: >>>> On Wednesday 02 June 2010 17:45:26 Jason Moxham wrote: >>>> > Looks good , there are only 2 or 3 real errors >>>> > >>>> > your cleo and iras errors are because you need to get icc in your path , >>>> > you will hit 1 real error then , but we can easily fix that. >>>> >>>> I fixed it by just deleting the assert , we very rarely have them in asm >>>> anyway , and that fixed the problem until we hit the next little error >>>> >>>> >>>> ../.libs/libmpir.so -Wl,--rpath -Wl,/usr/local/lib >>>> icc: command line remark #10010: option '-c99' is deprecated and will be >>>> removed in a future release. See '-help deprecated' >>>> icc: command line remark #10010: option '-c99' is deprecated and will be >>>> removed in a future release. See '-help deprecated' >>>> /home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/.libs/libmpir.so: undefined >>>> reference to `__gmpn_invert_limb' >>>> icc -c99 -o .libs/t-bswap t-bswap.o ./.libs/libtests.a >>>> /home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/.libs/libmpir.so >>>> ../.libs/libmpir.so -Wl,--rpath -Wl,/usr/local/lib >>>> make[4]: *** [t-count_zeros] Error 1 >>>> make[4]: *** Waiting for unfinished jobs.... >>>> icc: command line remark #10010: option '-c99' is deprecated and will be >>>> removed in a future release. See '-help deprecated' >>>> t-constants.o: In function `main': >>>> /home/jasonmoxham/sourcecode/mpir-2.1.0/./tests/t-constants.c:(.text+0x4b2) >>>>: undefined reference to `__gmpn_invert_limb' >>>> /home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/.libs/libmpir.so: undefined >>>> reference to `__gmpn_invert_limb' >>>> make[4]: *** [t-constants] Error 1 >>>> make[4]: *** [t-gmpmax] Error 1 >>>> /home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/.libs/libmpir.so: undefined >>>> reference to `__gmpn_invert_limb' >>>> make[4]: *** [t-bswap] Error 1 >>>> make[4]: Leaving directory >>>> `/home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/tests' >>>> make[3]: *** [check-am] Error 2 >>>> make[3]: Leaving directory >>>> `/home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/tests' >>>> make[2]: *** [check-recursive] Error 1 >>>> make[2]: Leaving directory >>>> `/home/jasonmoxham/sourcecode/mpir-2.1.0/cleo/tests' >>>> make[1]: *** [check-recursive] Error 1 >>>> make[1]: Leaving directory `/home/jasonmoxham/sourcecode/mpir-2.1.0/cleo' >>>> make: *** [check] Error 2 >>>> cleo >>>> >>>> PASSED CC=gcc CXX=g++ configure= >>>> PASSED CC=gcc CXX=g++ configure= --enable-cxx --enable-gmpcompat >>>> PASSED CC=gcc CXX=g++ configure= --enable-cxx --enable-gmpcompat --enable- >>>> assert --enable-alloca=debug >>>> PASSED CC=gcc CXX=g++ configure= --enable-cxx --enable-gmpcompat --enable- >>>> assert --enable-alloca=debug --build=none-unknown-linux-gnu >>>> PASSED CC=cc CXX=c++ configure= >>>> PASSED CC=cc CXX=c++ configure= --enable-cxx --enable-gmpcompat >>>> PASSED CC=cc CXX=c++ configure= --enable-cxx --enable-gmpcompat >>>> --enable-assert --enable-alloca=debug >>>> PASSED CC=cc CXX=c++ configure= --enable-cxx --enable-gmpcompat >>>> --enable-assert --enable-alloca=debug --build=none-unknown-linux-gnu >>>> PASSED CC=icc CXX=g++ configure= >>>> PASSED CC=icc CXX=g++ configure= --enable-cxx --enable-gmpcompat >>>> PASSED CC=icc CXX=g++ configure= --enable-cxx --enable-gmpcompat --enable- >>>> assert --enable-alloca=debug >>>> FAILED CC=icc CXX=g++ configure= --enable-cxx --enable-gmpcompat --enable- >>>> assert --enable-alloca=debug --build=none-unknown-linux-gnu >>>> >>>> This looks easy to fix , I'll do it tomorrow >>>> Jason >>> >>> This is caused by LONGLONG_STANDALONE not being defined ANYWHERE???? which >>> makes invert_limb depend on udiv_qrnnd_preinv which depends on invert_limb >>> which depends on ..... >> >> LONGLONG_STANDALONE shouldn't be defined anywhere. The longlong.h file >> used to be maintained as a standalone file, but has not been for many >> years. This define is left over from the days when it used to be used >> that way. >> >>> >>> As this is just to run some more tests and not a production mpir lib , I >>> suggest we forget about it for now (plus it's only on icc not gcc) >>> >>> I've run the full mpirtests on my K8 and atom both with 64 and 32bit OSes as >>> described before with no errors , and also on mark.skynet (although the test >>> script burped at the end , but as the run took a full day , I debug the test >>> script later) >>> >>> Are there any outstanding tests? >>> I assume building sage with it went OK? >> >> The last I heard about sage was the ecm issue. I don't know if they've >> updated ECM yet or not. It's not an upstream issue, as ECM have fixed >> this in a more recent release. >> >>> >>> Jason >>> >>> >>> >>>> >>>> > for lena and flavius gcc34 doesn't have a g++ >>>> > >>>> > gcc54 has a broken c++ >>>> > >>>> > gcc42 has a broken c++ and there is no way to get a timer for tuning >>>> > (same for cato) >>>> > >>>> > fulvia gcc4.5.0 is not installed right >>>> > >>>> > fulvia cc , 1 real error , suns assembler is old , we should force it to >>>> > use yasm is all cases , I see if I can do it (I have to remove my brain >>>> > first , to get in the autotools mood) , but it may have to wait for next >>>> > release. >>>> > >>>> > bsd.math we dont support fat builds on a mac (PIC code is different) and >>>> > they arn't needed that much >>>> > >>>> > gcc101 is a bsd system and I think we dont support fat builds (same as >>>> > above?) so possibly a real error >>>> > >>>> > rest of the machines use gcc-4.3.2 which is broken >>>> > >>>> > I have updated the test script to reflect some of changes , but there are >>>> > a lot of broken systems , so we will still get some errors from these. >>>> > >>>> > Jason >>>> > >>>> > On Wednesday 02 June 2010 16:47:22 Minh Nguyen wrote: >>>> > > Hi folks, >>>> > > >>>> > > Build and test results for MPIR 2.1.0-rc2 on the build farm are >>>> > > available at >>>> > > >>>> > > http://wiki.sagemath.org/mpir/BuildFarm/mpir-2.1.0#MPIR2.1.0-rc2 >>>> > > >>>> > > Each build was done using one thread, i.e. first exporting >>>> > > >>>> > > $ export MAKE='make' >>>> > > >>>> > > The test suite was ran using one CPU. On some machines, doing a >>>> > > parallel build would result in a failure to tune, i.e. doing >>>> > > >>>> > > $ make tune >>>> > > >>>> > > after a parallel build would fail. So for each reported machine, I >>>> > > only used one thread/CPU for build, check, tune, and test suite. >>>> > > >>>> > > -- >>>> > > Regards >>>> > > Minh Van Nguyen >>> >>> -- >>> 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. >>> >>> >> > -- 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.
