upgrade to MPIR-3.0.0

[Vincent Delecroix]

New upstream version

​http://mpir.org/mpir-3.0.0.tar.bz2

This new version requires ​yasm for assembler code.

[Vincent Delecroix]

New commits:

​f68bc8e

upgrade mpir to 3-0-0

[Dima Pasechnik]

I suppose the documentation should mention dependence on yasm. (The version on the yasm's website appears to be 1.3, same as on a couple of Linux machines I checked, so that's matter of doing apt-get install yasm or something like this. Although on arando buildbot it's 1.2, not 1.3, and so something would have to be done to such older systems).

[Vincent Delecroix]

Replying to dimpase:

I suppose the documentation should mention dependence on yasm. (The version on the yasm's website appears to be 1.3, same as on a couple of Linux machines I checked, so that's matter of doing apt-get install yasm or something like this. Although on arando buildbot it's 1.2, not 1.3, and so something would have to be done to such older systems).

Dima, do we need yasm 1.3 to compile MPIR 3.0.0? Building MPIR on arando would fail?

[Dima Pasechnik]

Replying to vdelecroix:

do we need yasm 1.3 to compile MPIR 3.0.0? Building MPIR on arando would fail?

Bull writes in no uncertain terms that you need the latest version of yasm. As 1.2 is almost 6 years old, I imagine that on new CPUs there could be problems, as the code for the CPU won't compile.

arando has old CPU, more that 6 years old in fact, and I just checked that there MPIR compiles and passes all its checks (with system's gcc 6.2 and yasm 1.2).

[Jean-Pierre Flori]

We decided to remove the inlcuded yasm form mpir sources. That was the only sane thing to do... so Sage needs to ship it separately or we make it a build dependency.

[Jean-Pierre Flori]

@vincent: do you plan on modifying this ticket to include yasm?

[Vincent Delecroix]

Replying to jpflori:

@vincent: do you plan on modifying this ticket to include yasm?

Nope. Would better be a dependency ticket.

[Vincent Delecroix]

See #22748 for yasm

[git]

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

​8d16afb	Merge remote-tracking branch 'trac/develop' into mpir300
​4d723dc	Add yasm as a standard package.
​0f365fc	Merge branch 'yasm130' into mpir300
​16058ef	Add build time yasm dependency to mpir.

[Jean-Pierre Flori]

New commits:

​8d16afb	Merge remote-tracking branch 'trac/develop' into mpir300
​4d723dc	Add yasm as a standard package.
​0f365fc	Merge branch 'yasm130' into mpir300
​16058ef	Add build time yasm dependency to mpir.

[Jean-Pierre Flori]

Seems to work fine for me.

[Dima Pasechnik]

this and #22748 seem to work on clang/FreeBSD.

[Jean-Pierre Flori]

Good to go in?

[François Bissey]

Yes.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​3057c79	Add configure check for yasm
​6377eae	upgrade mpir to 3-0-0
​c39a193	Add build time yasm dependency to mpir.

[Travis Scrimshaw]

Is that a positive review?

[Jean-Pierre Flori]

I would say so!

[François Bissey]

And of we go....

[Volker Braun]

On Debian 7 64-bit: ​http://build.sagedev.org/#/builders/80/builds/1/steps/5/logs/stdio

[mpir-3.0.0] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c nextprime.c  -fPIC -DPIC -o .libs/nextprime.o
[mpir-3.0.0] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c nextprime.c -o nextprime.o >/dev/null 2>&1
[mpir-3.0.0] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c primesieve.c -o primesieve.o >/dev/null 2>&1
[mpir-3.0.0] /bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.  -D__GMP_WITHIN_GMP   -m64 -O2 -march=corei7-avx -mtune=corei7-avx  -g  -c -o version.lo version.c
[mpir-3.0.0] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c version.c  -fPIC -DPIC -o .libs/version.o
[mpir-3.0.0] /bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.  -D__GMP_WITHIN_GMP   -m64 -O2 -march=corei7-avx -mtune=corei7-avx  -g  -c -o tal-reent.lo tal-reent.c
[mpir-3.0.0] make[6]: *** No rule to make target `mpn/addmul_1.lo', needed by `libmpir.la'.
[mpir-3.0.0] make[6]: *** No rule to make target `mpn/mul_basecase.lo', needed by `libmpir.la'.
[mpir-3.0.0] make[6]: *** No rule to make target `mpn/sqr_basecase.lo', needed by `libmpir.la'.
[mpir-3.0.0] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c version.c -o version.o >/dev/null 2>&1
[mpir-3.0.0] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c tal-reent.c  -fPIC -DPIC -o .libs/tal-reent.o
[mpir-3.0.0] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c tal-reent.c -o tal-reent.o >/dev/null 2>&1
[mpir-3.0.0] /bin/bash ./libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I.  -D__GMP_WITHIN_GMP   -m64 -O2 -march=corei7-avx -mtune=corei7-avx  -g  -c -o cxx/dummy.lo cxx/dummy.cc
[mpir-3.0.0] libtool: compile:  g++ -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c cxx/dummy.cc  -fPIC -DPIC -o cxx/.libs/dummy.o
[mpir-3.0.0] libtool: compile:  g++ -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c cxx/dummy.cc -o cxx/dummy.o >/dev/null 2>&1
[mpir-3.0.0] make[6]: Target `all-am' not remade because of errors.
[mpir-3.0.0] make[6]: Leaving directory `/home/buildbot/slave/sage_git/build/local/var/tmp/sage/build/mpir-3.0.0/src'
[mpir-3.0.0] make[5]: *** [all-recursive] Error 1
[mpir-3.0.0] make[5]: Leaving directory `/home/buildbot/slave/sage_git/build/local/var/tmp/sage/build/mpir-3.0.0/src'
[mpir-3.0.0] make[4]: *** [all] Error 2
[mpir-3.0.0] make[4]: Leaving directory `/home/buildbot/slave/sage_git/build/local/var/tmp/sage/build/mpir-3.0.0/src'
[mpir-3.0.0] Error building MPIR.

[François Bissey]

Hum

[mpir-3.0.0] libtool: compile:  ../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -I.. -DOPERATION_addmul_1 -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -I. -I.. addmul_1.asm  -fPIC -DPIC -o .libs/addmul_1.o
[mpir-3.0.0] m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_addmul_1 -DPIC addmul_1.asm >tmp-addmul_1.s
[mpir-3.0.0]  gcc -c -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -I.. -DOPERATION_addmul_1 -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -I. -I.. tmp-addmul_1.s -fPIC -DPIC -o .libs/addmul_1.o
[mpir-3.0.0] libtool: compile:  ../strip_fPIC.sh /home/buildbot/slave/sage_git/build/local/bin/yasm -I .. -f elf64 submul_1.as  -fPIC -DPIC -o .libs/submul_1.o
[mpir-3.0.0] /home/buildbot/slave/sage_git/build/local/bin/yasm -I .. -f elf64 submul_1.as -D PIC -o .libs/submul_1.o
[mpir-3.0.0] libtool: compile:  ../strip_fPIC.sh /home/buildbot/slave/sage_git/build/local/bin/yasm -I .. -f elf64 submul_1.as -o submul_1.o >/dev/null 2>&1
[mpir-3.0.0] tmp-addmul_1.s: Assembler messages:
[mpir-3.0.0] tmp-addmul_1.s:152: Error: no such instruction: `adox (%rdi),%r9'
[mpir-3.0.0] tmp-addmul_1.s:154: Error: no such instruction: `adox %rcx,%rax'
[mpir-3.0.0] tmp-addmul_1.s:166: Error: no such instruction: `adox -8(%rdi),%r10'
[mpir-3.0.0] tmp-addmul_1.s:167: Error: no such instruction: `adcx %r8,%r9'
[mpir-3.0.0] tmp-addmul_1.s:171: Error: no such instruction: `adox (%rdi),%r9'
[mpir-3.0.0] tmp-addmul_1.s:174: Error: no such instruction: `adcx %rax,%r10'
[mpir-3.0.0] tmp-addmul_1.s:176: Error: no such instruction: `adcx %r8,%r9'
[mpir-3.0.0] tmp-addmul_1.s:177: Error: no such instruction: `adox 8(%rdi),%r10'
[mpir-3.0.0] tmp-addmul_1.s:181: Error: no such instruction: `adcx %rax,%r10'
[mpir-3.0.0] tmp-addmul_1.s:182: Error: no such instruction: `adox 16(%rdi),%r9'
[mpir-3.0.0] tmp-addmul_1.s:185: Error: no such instruction: `adox 24(%rdi),%r10'
[mpir-3.0.0] tmp-addmul_1.s:186: Error: no such instruction: `adcx %r8,%r9'
[mpir-3.0.0] tmp-addmul_1.s:189: Error: no such instruction: `adcx %rax,%r10'
[mpir-3.0.0] tmp-addmul_1.s:190: Error: no such instruction: `adox 32(%rdi),%r9'
[mpir-3.0.0] tmp-addmul_1.s:193: Error: no such instruction: `adox 40(%rdi),%r10'
[mpir-3.0.0] tmp-addmul_1.s:194: Error: no such instruction: `adcx %r8,%r9'
[mpir-3.0.0] tmp-addmul_1.s:196: Error: no such instruction: `adox 48(%rdi),%r9'
[mpir-3.0.0] tmp-addmul_1.s:200: Error: no such instruction: `adcx %rax,%r10'
[mpir-3.0.0] make[6]: *** [addmul_1.lo] Error 1

[François Bissey]

​http://stackoverflow.com/questions/29747508/what-is-the-difference-between-the-adc-and-adcx-instructions-on-ia32-ia64 I'd say we have a misdetection of the hardware or the assmebler used by gcc doesn't support those instructions.

[Jean-Pierre Flori]

I'd say the assembler is yasm.

[Jean-Pierre Flori]

Can't seem to get any info from the (terrible) buildbot pages... Seems like a wrong arch choice by MPIR configure script.

[Volker Braun]

The error message is from as, not yasm:

$ strings local/bin/yasm  | grep such
$ strings /usr/bin/as  | grep such
no such architecture modifier: `%s'
broadcast is needed for operand of such type
no such architecture: `%s'
no such instruction: `%s'

Unless yasm calls as somewhere under the hood, though I don't think thats the case...

[Volker Braun]

I.e. the error comes from

gcc -c -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -I.. -DOPERATION_addmul_1 -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -I. -I.. tmp-addmul_1.s -fPIC -DPIC -o .libs/addmul_1.o

which does not use yasm.

[Jean-Pierre Flori]

Ok, that's right. MPIR uses yasm or not based on the file extension.

Maybe the error is just because as on debian 7 is just too old?

[Jean-Pierre Flori]

Cannot reproduce this on an unstable debian with the exact same command lines.

[Jean-Pierre Flori]

I would say as is indeed too old. The problematic file is:

• ​https://github.com/wbhart/mpir/blob/master/mpn/x86_64/skylake/avx/addmul_1.asm

using adcx/adox instructions. These were added in a post july 2012 as release:

• ​https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=e2e1fcde622f2f6cedfd7fb6615aa6e136f21dec

And debian wheezy ships binutils 2.22 which is pre-2012:

• ​https://ftp.gnu.org/gnu/binutils/

So can we ignore this very outdated OS? It's a Debian old stable, so quite very old...

[Jean-Pierre Flori]

One could argue that wheezy has LTS till may 2018:

• ​https://www.debian.org/releases/wheezy/

[Dima Pasechnik]

How would the version of binutils matter? Isn't the asm code meant to be compiled with an up to date yasm installed by Sage?

[Jean-Pierre Flori]

Nope, some assembly files are compiled with yasm, others with as...

[Dima Pasechnik]

Replying to jpflori:

Nope, some assembly files are compiled with yasm, others with as...

OK, so we either have to tell the users to upgrade binutils to something meaningful, or ship our own gas...

[Jean-Pierre Flori]

Not so many users whould use a pre-2012 gas... We can also forbid the use of assembly when gas is too old. That's the best solution I have in mind to please the patchbot running Debian 7.

[git]

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

​f68bc8e	upgrade mpir to 3-0-0
​8d16afb	Merge remote-tracking branch 'trac/develop' into mpir300
​0f365fc	Merge branch 'yasm130' into mpir300
​16058ef	Add build time yasm dependency to mpir.
​357103a	Merge branch 'public/22493' of git://trac.sagemath.org/sage into mpir300
​8ddc2f1	MPIR 3.0.0 does not build yasm anymore.
​8205366	But MPIR always looks for it even on archs where it is not used.
​9573e15	Check GNU as version when building MPIR.

[git]

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

​cb8a3f7

Echo comment when skipping yasm check.

[git]

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

​aa0b222

This should work and be useful on non-linux systems.

[Jean-Pierre Flori]

It would be nice to get this into Sage 8.0.

[François Bissey]

OK, sorry for the delay. It looks OK to me. It will work on all the systems we officially support.

For the records if you are in that kind of trivia uname -m is not portable (but is OK across the platform we support so no need to change). For bonus points, can you tell me what kind of system I am testing here

[xcat1-c][/]> uname -m
00F6B2734C00

[Jean-Pierre Flori]

-bash-4.3$ uname -m
00F84C0C4C00

[François Bissey]

Should have known you'd have access to one of those too.

[Dima Pasechnik]

On FreeBSD with clang this does not work, as it misidentifies the compiler as gcc and then trips over itself. Does it work with clang on OSX?

[François Bissey]

I haven't tried yet I must say. Can you post a log so I can see how it trips itself? It'll probably be quicker for me to try on linux+clang actually.

[Dima Pasechnik]

Replying to fbissey:

I haven't tried yet I must say. Can you post a log so I can see how it trips itself? It'll probably be quicker for me to try on linux+clang actually.

it actually works on FreeBSD/clang, sorry for noise. I used wrong C++ compiler, with clang++-devel it works like a charm.

[François Bissey]

I just finished building mpir on linux+clang without a hitch either.

[Volker Braun]

now fails with

[mpir-3.0.0] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c version.c  -fPIC -DPIC -o .libs/version.o
[mpir-3.0.0] make[6]: *** No rule to make target `mpn/addmul_1.lo', needed by `libmpir.la'.
[mpir-3.0.0] make[6]: *** No rule to make target `mpn/mul_basecase.lo', needed by `libmpir.la'.
[mpir-3.0.0] make[6]: *** No rule to make target `mpn/sqr_basecase.lo', needed by `libmpir.la'.
[mpir-3.0.0] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c tal-reent.c  -fPIC -DPIC -o .libs/tal-reent.o
[mpir-3.0.0] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c version.c -o version.o >/dev/null 2>&1
[mpir-3.0.0] /bin/bash ./libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I.  -D__GMP_WITHIN_GMP   -m64 -O2 -march=corei7-avx -mtune=corei7-avx  -g  -c -o cxx/dummy.lo cxx/dummy.cc
[mpir-3.0.0] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c tal-reent.c -o tal-reent.o >/dev/null 2>&1
[mpir-3.0.0] libtool: compile:  g++ -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c cxx/dummy.cc  -fPIC -DPIC -o cxx/.libs/dummy.o
[mpir-3.0.0] libtool: compile:  g++ -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP -m64 -O2 -march=corei7-avx -mtune=corei7-avx -g -c cxx/dummy.cc -o cxx/dummy.o >/dev/null 2>&1
[mpir-3.0.0] make[6]: Target `all-am' not remade because of errors.
[mpir-3.0.0] make[6]: Leaving directory `/home/buildbot/slave/sage_git/build/local/var/tmp/sage/build/mpir-3.0.0/src'
[mpir-3.0.0] make[5]: *** [all-recursive] Error 1
[mpir-3.0.0] make[5]: Leaving directory `/home/buildbot/slave/sage_git/build/local/var/tmp/sage/build/mpir-3.0.0/src'
[mpir-3.0.0] make[4]: *** [all] Error 2
[mpir-3.0.0] make[4]: Leaving directory `/home/buildbot/slave/sage_git/build/local/var/tmp/sage/build/mpir-3.0.0/src'
[mpir-3.0.0] Error building MPIR.

on Debian 7. ​http://build.sagedev.org/#/builders/80/builds/5/steps/5/logs/stdio

[Jean-Pierre Flori]

Debian 7 again :/

[François Bissey]

Looks like the fix didn't work

[mpir-3.0.0] tmp-addmul_1.s: Assembler messages:
[mpir-3.0.0] tmp-addmul_1.s:152: Error: no such instruction: `adox (%rdi),%r9'
[mpir-3.0.0] tmp-addmul_1.s:154: Error: no such instruction: `adox %rcx,%rax'
[mpir-3.0.0] tmp-addmul_1.s:166: Error: no such instruction: `adox -8(%rdi),%r10'
[mpir-3.0.0] tmp-addmul_1.s:167: Error: no such instruction: `adcx %r8,%r9'
[mpir-3.0.0] tmp-addmul_1.s:171: Error: no such instruction: `adox (%rdi),%r9'
[mpir-3.0.0] tmp-addmul_1.s:174: Error: no such instruction: `adcx %rax,%r10'
[mpir-3.0.0] tmp-addmul_1.s:176: Error: no such instruction: `adcx %r8,%r9'
[mpir-3.0.0] tmp-addmul_1.s:177: Error: no such instruction: `adox 8(%rdi),%r10'
[mpir-3.0.0] tmp-addmul_1.s:181: Error: no such instruction: `adcx %rax,%r10'
[mpir-3.0.0] tmp-addmul_1.s:182: Error: no such instruction: `adox 16(%rdi),%r9'
[mpir-3.0.0] tmp-addmul_1.s:185: Error: no such instruction: `adox 24(%rdi),%r10'
[mpir-3.0.0] tmp-addmul_1.s:186: Error: no such instruction: `adcx %r8,%r9'
[mpir-3.0.0] tmp-addmul_1.s:189: Error: no such instruction: `adcx %rax,%r10'
[mpir-3.0.0] tmp-addmul_1.s:190: Error: no such instruction: `adox 32(%rdi),%r9'
[mpir-3.0.0] tmp-addmul_1.s:193: Error: no such instruction: `adox 40(%rdi),%r10'
[mpir-3.0.0] tmp-addmul_1.s:194: Error: no such instruction: `adcx %r8,%r9'
[mpir-3.0.0] tmp-addmul_1.s:196: Error: no such instruction: `adox 48(%rdi),%r9'
[mpir-3.0.0] tmp-addmul_1.s:200: Error: no such instruction: `adcx %rax,%r10'
[mpir-3.0.0] /bin/bash ../libtool --mode=compile --tag=CC ../strip_fPIC.sh /home/buildbot/slave/sage_git/build/local/bin/yasm -I .. -f elf64  -o lshift.lo `test -f 'lshift.as' || echo './'`lshift.as
[mpir-3.0.0] make[6]: *** [addmul_1.lo] Error 1

back to the drawing board.

[Jean-Pierre Flori]

Hum, I did not actually test on a debian 7 seven, I just looked at what GNU as version is provided there and thought I ound the issue. So several possibilities:

• I'm stupid,
• the check for as version I implemented is wrong,
• the issue is somewhere else.

The easiest way to solve this would be to get access to the machine... I downloaded a bunch of qemu debian 7 images but the pc I mostly work on does not have internet access and these images come wihtout gnu as :/

[Volker Braun]

I think the as version check is correct but "$CC" = GCC is always false unless you really go out of your way to rename gcc...

[Volker Braun]

PS:

buildbot@sagebd07_64s02:~$ as --version | head -1 | awk 'NF>1{print $NF}'
2.22

[François Bissey]

Replying to vbraun:

I think the as version check is correct but "$CC" = GCC is always false unless you really go out of your way to rename gcc...

You are probably right. It is not a correct way to ascertain that CC is gcc, you'd have to look at $CC -v or similar. Considering the only other possibility is clang during toolchain building on OS X and that

Mirage:~ fbissey$ as --version | head -1 | awk 'NF>1{print $NF}'
(clang-802.0.42)

won't be caught by your case statement, I think we can just scrap the $CC=GCC bit.

[François Bissey]

Argh, Now I see why I had started a bit of my answer differently. If you are worried about using clang on linux, which is in the future so far, we'll do it when it become possible. Using an output from configure preferably (I currently output a variable IS_CLANG in sage-env-config and that's much more reliable).

[Jeroen Demeyer]

Replying to jpflori:

Nope, some assembly files are compiled with yasm, others with as...

Are we sure that this is an upstream feature? It seems strange to me...

[Jean-Pierre Flori]

Yes it is. One of the former developer prefered ATT syntax over intel (or the other way around) and that was not very well supported by gas at that time, don't know the current situation. Moreover yasm provides better windows support with stack dark magic unwinding feature.

Files are treated by yasm or gas depending on their extension (as or asm).

[Jean-Pierre Flori]

Replying to vbraun:

I think the as version check is correct but "$CC" = GCC is always false unless you really go out of your way to rename gcc...

Oops!

[git]

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

​7467913	Upgrade to libpng-1.6.28
​61ff918	Merge remote-tracking branch 'trac/u/jdemeyer/upgrade_to_latest_libpng' into libpng1629
​aa28f4c	Bump to libpng 1.6.29.
​be90134	Merge remote-tracking branch 'trac/public/22493' into mpir300
​fea0bae	Remove useless gcc check when looking for old as.

[Jean-Pierre Flori]

Argh, I merged unrelated stuff.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​c9eaefc

Remove useless gcc check when looking for old as.

[François Bissey]

Once again to the bots.

[Volker Braun]

[mpir-3.0.0] ./spkg-install: line 168: as_version: command not found

In bash you can't have a space before the equal sign in assignment...

[git]

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

​01c9097

Remove broken spaces.

[Jean-Pierre Flori]

@francois: push the button again?

[Marc Mezzarobba]

+# Workaround old GNU as version by disabling assembly use.
+if [ "$UNAME" = Linux ] && [ "$CC" = GCC ]; then
+    as_version = `$AS --version | head -1 | awk 'NF>1{print $NF}'`
+    case "$as_version" in
+        1.*|2.1*|2.[0-2]*)
                  ^^^^^^^
+        echo "Disable use of assembly because of GNU as < 2.23."
+        export MPN_PATH=generic
+        ;;
+    esac
+fi

Shouldn't that be 2.2[0-2]*? In other words, aren't you disabling assembly for everyone on Linux/gcc here?

Sage has become significantly slower on my system (judging from a few quick experiments, perhaps 10-15% slower on average, with integer operations 1.5× to 2× slower) somewhere between 7.6.rc2 and 8.0.beta9, and I'm wondering if this isn't the cause of the regression...

[Marc Mezzarobba]

Replying to myself: Indeed, changing 2.[0-2] to 2.2[0-2] solves the issue. Follow-up at #23209.

[Jeroen Demeyer]

This ticket caused a significant performance regression: #23327

[Travis Scrimshaw]

Replying to jdemeyer:

This ticket caused a significant performance regression: #23327

This is not fixed by #23146?