Update to MPIR 2.7.0-alpha12

[jpflori]

MPIR 2.6.0 does not build on Cygwin 64. The next version should fix this problem (and others). Patches from Sage will mostly be integrated.

upstream at: ​http://mpir.org/mpir-2.7.0-alpha12.tar.bz2

[jpflori]

This should surely be renamed to "Update to MPIR 2.6.1" when the official version get released (no idea when...).

[tscrim]

For the record, the current spkg built for me on cygwin64.

[jpflori]

On top of that the current MPIR 2.6.0 fails to properly build on Cygwin when CXX support is not enabled. Therefore it is not possible/easy to build GCC on Cygwin. That is because of a dirty hack in the autotools stuff already present in GMP before MPIR was forked. This is also fixed in the current git version.

[leif]

Otherwise we'd probably have to close it as won't fix. :-)

Current upstream tarball: ​http://mpir.org/mpir-2.7.0-alpha4.tar.bz2

Still needs to be tested on Darwin PowerPC I think. (moufang? Does it still live?)

And probably also Macs with more recent versions of Xcode.

[kcrisman]

So are you saying that JP should make a tarball for this as an alpha? I don't have time to test this on PPC until that exists. Currently trying to built 6.2.beta7, I'll wait until I get a clean build for that platform before I try new things. (Hopefully rpy is the only remaining problem there.)

[leif]

Replying to kcrisman:

So are you saying that JP should make a tarball for this as an alpha?

I think that would be convenient for testing, and there are still some issues on Cygwin* JP knows about.

By the way, note that the latest changes in the alpha4 tarball aren't yet committed on github (it's still at alpha3).

[jpflori]

Replying to kcrisman:

So are you saying that JP should make a tarball for this as an alpha? I don't have time to test this on PPC until that exists. Currently trying to built 6.2.beta7, I'll wait until I get a clean build for that platform before I try new things. (Hopefully rpy is the only remaining problem there.)

I happens I did and almost have an almost completely working out of the box cygwin64 branch. I just have to cherry-pick commits and push them to different branches on trac.

[jpflori]

There are still issues with PPL... See ​https://groups.google.com/forum/?fromgroups=#!topic/mpir-devel/JFDaMAc0YpY

---

New commits:

​a564118	Update MPIR to 2.7.0.alpha4
​5d7a2e9	Remove unnecessary fix for MPIR.

[leif]

A few comments/questions:

• Do we lose the Clang / XCode 5 patch? (I did have other clang patches elsewhere, also just preventing configure to fail for no real reason.)

• Sun compiler patch (probably less important)?

• What is patch ... || continue supposed to achieve? (The if [ $? -ne 0 ] afterwards gets useless.)

• In if uname -a | grep x86_64; then ... any output (stdout and stderr) should get redirected to /dev/null.

Should #16149 be added as a dependency of this ticket, or do you want to deal with that in MPIR's spkg-install? (I'd prefer the former, but am also undecided about the solution to choose on #16149, hence "needs info".)

[leif]

I recall we also had issues with AVX-enabled CPUs on Darwin and (not that) old Apple assemblers not supporting AVX instructions. IIRC Jeroen removed a work-around (with a bunch of other things dealing with proper CFLAGS) from spkg-install a while ago, so this is presumably no longer an issue (just because we meanwhile require some more recent version of Xcode I guess), but I might be wrong.

[jpflori]

Replying to leif:

A few comments/questions:

All (Most?) should be upstream now if I did not screw up a long time ago.

• Do we lose the Clang / XCode 5 patch? (I did have other clang patches elsewhere, also just preventing configure to fail for no real reason.)

Must admit I don't remember about that one.

• Sun compiler patch (probably less important)?

This one is in (IIRC).

• What is patch ... || continue supposed to achieve? (The if [ $? -ne 0 ] afterwards gets useless.)

When there is no patch at all I guess. Not sure naymore.

• In if uname -a | grep x86_64; then ... any output (stdout and stderr) should get redirected to /dev/null.

Maybe!

Should #16149 be added as a dependency of this ticket, or do you want to deal with that in MPIR's spkg-install? (I'd prefer the former, but am also undecided about the solution to choose on #16149, hence "needs info".)

The CXXFLAGS issue should be fixed in MPIR (maybe not alpha4, but in git master).

[jpflori]

Replying to leif:

I recall we also had issues with AVX-enabled CPUs on Darwin and (not that) old Apple assemblers not supporting AVX instructions. IIRC Jeroen removed a work-around (with a bunch of other things dealing with proper CFLAGS) from spkg-install a while ago, so this is presumably no longer an issue (just because we meanwhile require some more recent version of Xcode I guess), but I might be wrong.

I don't now. We surely added thing for apple ocmpiler/assembler/linker but couldn't promise it was AVX related.

[leif]

Replying to jpflori:

Replying to leif:

Should #16149 be added as a dependency of this ticket, or do you want to deal with that in MPIR's spkg-install? (I'd prefer the former, but am also undecided about the solution to choose on #16149, hence "needs info".)

The CXXFLAGS issue should be fixed in MPIR (maybe not alpha4, but in git master).

No, a slightly different one (but with the same effect). AC_PROG_CXX in MPIR is now correctly called after CXXFLAGS have been saved, and MPIR now behaves correctly (I'd say). But Sage sets (and exports) CXXFLAGS to the empty string, so MPIR doesn't touch them (again assuming they were intentionally set), such that we end up with missing flags (unless the user had really set them, or CFLAGS, to something meaningful).

[jpflori]

I see. Thanks for the explanation.

[leif]

P.S.: In spkg-install, we could do (almost) the same with CXXFLAGS as we do with CFLAGS. In the first "dry" configure run, we already unset them, so we could grep MPIR's from the Makefile and at least prepend those settings to our effective CXXFLAGS for the second, real configurerun.

(So far, we didn't touch CXXFLAGS at all, which I'd consider a small deficiency or inconsistency anyway.)

[leif]

[Slight correction to my previous post.]

[leif]

Replying to jpflori:

• What is patch ... || continue supposed to achieve? (The if [ $? -ne 0 ] afterwards gets useless.)

When there is no patch at all I guess.

Ah, thought of something like that. But it should be

for foo in bar*; do
    [ -r "$foo" ] || continue   # ignore non-readable / non-existent files
    process "$foo"
    if [ $? -ne 0 ]; then
        # processing $foo failed, err out
        ...
    fi
done

[jpflori]

Sure, I messed up :(

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​113a8dd	Merge remote-tracking branch 'trac/develop' into ticket/15015
​da483e1	Correct MPIR spkg-install scripts for non-exisiting patches.

[jdemeyer]

All patches from Sage seem to be integrated upstream, good! The changes here look fine, the main part of reviewing will be checking that it actually works. I will upgrade this to the latest MPIR alpha and report back.

[jpflori]

I'm not sure the problem with ppl is fixed in the latest alpha... Some hints to fix it must lurk on flint-devel.

[jpflori]

See ​https://groups.google.com/d/msg/mpir-devel/JFDaMAc0YpY/h774pq9wN2EJ And IIRC it does not only happens on Cygwin(64) but also on more usual systems.

[jdemeyer]

In spkg-install, I also changed

echo "Checking what CFLAGS MPIR would use if they were empty..."
(unset CFLAGS CPPFLAGS CXXFLAGS && ./configure $MPIR_CONFIGURE) &>configure-empty.log

to

echo "Configuring MPIR with empty CFLAGS to determine the defaults:"
(unset CFLAGS CPPFLAGS CXXFLAGS && ./configure $MPIR_CONFIGURE)

I think it's better to display the first configure run, in case it needs to be debugged or just to show the user that Sage isn't stuck.

---

New commits:

​1607b8f	Merge remote-tracking branch 'origin/develop' into ticket/15015
​7725122	Cosmetic changes

[jdemeyer]

On Linux x86_64, g++ (Gentoo 4.6.4 p1.2, pie-0.5.2) 4.6.4, while compiling the Sage library:

gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/usr/local/src/sage-config/local/include -I/usr/local/src/sage-config/local/include/csage -I/usr/local/src/sage-config/src -I/usr/local/src/sage-config/src/sage/ext -I/usr/local/src/sage-config/local/include/python2.7 -c build/cythonized/sage/libs/ppl.cpp -o build/temp.linux-x86_64-2.7/build/cythonized/sage/libs/ppl.o -fno-strict-aliasing -w
In file included from build/cythonized/sage/libs/ppl.cpp:352:0:
../local/include/gmpxx.h:1548:3: error: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(intmax_t)’ cannot be overloaded
../local/include/gmpxx.h:1539:3: error: with ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long int)’
../local/include/gmpxx.h:1552:3: error: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(uintmax_t)’ cannot be overloaded
../local/include/gmpxx.h:1540:3: error: with ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long unsigned int)’
../local/include/gmpxx.h:1615:16: error: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::operator=(intmax_t)’ cannot be overloaded
../local/include/gmpxx.h:1604:16: error: with ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::operator=(long int)’
../local/include/gmpxx.h:1619:16: error: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::operator=(uintmax_t)’ cannot be overloaded
../local/include/gmpxx.h:1606:16: error: with ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::operator=(long unsigned int)’
error: command 'gcc' failed with exit status 1

[jpflori]

Yup that is the problem I was mentioning.

[jpflori]

Could you try with the attached patch? If it works, I'll forward it to Bill.

[jpflori]

Groumpf, thepatch is reversed. Take the .2 one.

[jpflori]

Strange I don't have problems, even without my latest patch, on a machine where I seem to remember I used to have problems.

[jdemeyer]

Works for me...

[jpflori]

In fact I also need the patch, but not to build PPL anymore, but some ppl related file within the Sage library.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​6957f17	Merge remote-tracking branch 'origin/develop' into ticket/15015
​aca71cb	Upgrade to mpir-2.7.0-alpha12

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​67babeb

Fix doctests due to changed xgcd results

[jdemeyer]

This now builds and passes all doctests on 64-bit for me.

Test please!

[jdemeyer]

William: this changes one doctest in src/sage/tests/book_stein_modform.py

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​8c7fbbd

Re-enable "not tested" test from #4357

[jdemeyer]

Unrelated to this ticket, I have re-enabled a doctest in book_stein_modform.py which was fixed in #4357.

[jpflori]

For info, I agree that we should output the first configure run on screen. Some users already complained that MPIR compilation was stuck because of the long time it can take on some systems and nothing was getting printed on screen.

[jpflori]

Works fine for me (except for numerical noise I also get with the previous MPIR, and that is surely ppc64 specific).

Would you consider adding a spkg-src script?

[jpflori]

This works perfectly fine for me (though I did not test Cygwin, but that's a low level priority and can be fixed later in case it is needed).

The current tarball is the upstream one and includes windows stuff we used to delete. Apart from that, I would positively review the ticket, even without a proper spkg-src script.

[jdemeyer]

Upstream has indicated that they consider the changed output of mpz_gcdext() a bug.

Therefore, I think it is premature to upgrade now.

[jpflori]

Oh yeah, I read about that one...

[jdemeyer]

Because of the precedent at #17169, I would simply use the upstream tarball and not add a spkg-src script.

[jpflori]

I don't really agree... If we keep on like that Sage will grow huge. Hard disks are cheap but internet connections aren't always, e.g. I get a poor bandwith between my office and boxen. Let's discuss this on sage-devel.

[jpflori]

​https://groups.google.com/forum/#!topic/sage-devel/a9yIdaqNHKU

[jpflori]

The gcdext change in MPIR was to be expected (at least the gcdext(1,1) example Jeroen found) and I personally don't think it's a bug. I'm not sure what Bill will think though.

At the very least it makes MPIR consistent with GMP.

[jpflori]

(And ok for not shipping any spkg-src script.)

[jpflori]

The only thing really annoying me right now is the name of the tarball. When we update to another alpha or the final version it will be a pain, so we should still repackage the upstream tarball to change the dir name wihtin it (rather than renaming the tarball).

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​aefe0eb

Upgrade to MPIR 2.7.0-alpha12

[jdemeyer]

New commits:

​aefe0eb

Upgrade to MPIR 2.7.0-alpha12

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​3d583af	Merge remote-tracking branch 'origin/develop' into ticket/15015
​d97c066	Rename source directory

[jpflori]

Looks fine.

I had a vague souvenir we had trouble with dashes in version numbers but it does not seem to be the case anymore. Maybe we could also switch back to verbatim version numbers for Singular 4-0-1.

[jpflori]

Got two files with failing doctests but cannot reproduce these failures:

• src/sage/modular/modform/ambient.py
• src/sage/graphs/genus.pyx