upgrade to MPIR-3.0.0

[vdelecroix]

New upstream version

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

This new version requires ​yasm for assembler code.

[vdelecroix]

New commits:

​f68bc8e

upgrade mpir to 3-0-0

[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).

[vdelecroix]

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?

[dimpase]

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).

[jpflori]

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.

[jpflori]

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

[vdelecroix]

Replying to jpflori:

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

Nope. Would better be a dependency ticket.

[vdelecroix]

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.

[jpflori]

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.

[jpflori]

Seems to work fine for me.

[dimpase]

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

[jpflori]

Good to go in?

[fbissey]

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.

[tscrim]

Is that a positive review?

[jpflori]

I would say so!

[fbissey]

And of we go....

[vbraun]

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.

[fbissey]

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

[fbissey]

​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.

[jpflori]

I'd say the assembler is yasm.

[jpflori]

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

[vbraun]

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...

[vbraun]

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.

[jpflori]

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?

[jpflori]

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

[jpflori]

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...

[jpflori]

One could argue that wheezy has LTS till may 2018:

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

[dimpase]

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?

[jpflori]

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

[dimpase]

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...

[jpflori]

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.

[jpflori]

It would be nice to get this into Sage 8.0.

[fbissey]

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

[jpflori]

-bash-4.3$ uname -m
00F84C0C4C00

[fbissey]

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

[dimpase]

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?

[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.

[dimpase]

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.

[fbissey]

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

[vbraun]

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

[jpflori]

Debian 7 again :/

[fbissey]

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.

[jpflori]

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 :/

[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...

[vbraun]

PS:

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

[fbissey]

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.

[fbissey]

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).

[jdemeyer]

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...

[jpflori]

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).

[jpflori]

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.

[jpflori]

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.

[fbissey]

Once again to the bots.

[vbraun]

[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.

[jpflori]

@francois: push the button again?

[mmezzarobba]

+# 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...

[mmezzarobba]

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

[jdemeyer]

This ticket caused a significant performance regression: #23327

[tscrim]

Replying to jdemeyer:

This ticket caused a significant performance regression: #23327

This is not fixed by #23146?