Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#22493 closed enhancement (fixed)

upgrade to MPIR-3.0.0

Reported by: vdelecroix Owned by:
Priority: major Milestone: sage-7.6
Component: packages: standard Keywords: days84
Cc: mkoeppe, jdemeyer, vbraun, fbissey Merged in:
Authors: Vincent Delecroix, Jean-Pierre Flori Reviewers: François Bissey, Dima Pasechnik
Report Upstream: N/A Work issues:
Branch: 01c9097 (Commits, GitHub, GitLab) Commit:
Dependencies: #22748 Stopgaps:

Status badges

Description (last modified by vdelecroix)

New upstream version

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

This new version requires yasm for assembler code.

Change History (75)

comment:1 Changed 5 years ago by vdelecroix

  • Description modified (diff)

comment:2 Changed 5 years ago by vdelecroix

  • Branch set to public/22493
  • Commit set to f68bc8ea0bcfc6d9ed6c72bbeb94e08aff527739

New commits:

f68bc8eupgrade mpir to 3-0-0

comment:3 Changed 5 years ago by vdelecroix

  • Keywords days84 added

comment:4 follow-up: Changed 5 years ago by 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).

comment:5 in reply to: ↑ 4 ; follow-up: Changed 5 years ago by 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?

comment:6 in reply to: ↑ 5 Changed 5 years ago by 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).

comment:7 Changed 5 years ago by 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.

comment:8 follow-up: Changed 5 years ago by jpflori

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

comment:9 in reply to: ↑ 8 Changed 5 years ago by vdelecroix

Replying to jpflori:

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

Nope. Would better be a dependency ticket.

comment:10 Changed 5 years ago by vdelecroix

  • Dependencies set to #22748

See #22748 for yasm

comment:11 Changed 5 years ago by git

  • Commit changed from f68bc8ea0bcfc6d9ed6c72bbeb94e08aff527739 to 16058efed507d1c8137c8500f87730b0c56d9fee

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

8d16afbMerge remote-tracking branch 'trac/develop' into mpir300
4d723dcAdd yasm as a standard package.
0f365fcMerge branch 'yasm130' into mpir300
16058efAdd build time yasm dependency to mpir.

comment:12 Changed 5 years ago by jpflori

  • Authors changed from Vincent Delecroix to Vincent Delecroix, Jean-Pierre Flori
  • Cc jdemeyer vbraun fbissey added
  • Status changed from new to needs_review

New commits:

8d16afbMerge remote-tracking branch 'trac/develop' into mpir300
4d723dcAdd yasm as a standard package.
0f365fcMerge branch 'yasm130' into mpir300
16058efAdd build time yasm dependency to mpir.

comment:13 Changed 5 years ago by jpflori

Seems to work fine for me.

comment:14 Changed 5 years ago by dimpase

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

comment:15 Changed 5 years ago by jpflori

Good to go in?

comment:16 Changed 5 years ago by fbissey

Yes.

comment:17 Changed 5 years ago by git

  • Commit changed from 16058efed507d1c8137c8500f87730b0c56d9fee to c39a193b70b7d0e32f690b307dcccf3c123374d1

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

3057c79Add configure check for yasm
6377eaeupgrade mpir to 3-0-0
c39a193Add build time yasm dependency to mpir.

comment:18 Changed 5 years ago by tscrim

Is that a positive review?

comment:19 Changed 5 years ago by jpflori

I would say so!

comment:20 Changed 5 years ago by fbissey

  • Reviewers set to François Bissey
  • Status changed from needs_review to positive_review

And of we go....

comment:21 Changed 5 years ago by 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.

comment:22 Changed 5 years ago by vbraun

  • Status changed from positive_review to needs_work

comment:23 Changed 5 years ago by 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
Last edited 5 years ago by fbissey (previous) (diff)

comment:24 Changed 5 years ago by 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.

comment:25 Changed 5 years ago by jpflori

I'd say the assembler is yasm.

comment:26 Changed 5 years ago by jpflori

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

comment:27 Changed 5 years ago by jpflori

  • Status changed from needs_work to needs_info

comment:28 Changed 5 years ago by 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...

comment:29 Changed 5 years ago by 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

which does not use yasm.

Version 0, edited 5 years ago by vbraun (next)

comment:30 Changed 5 years ago by 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?

comment:31 Changed 5 years ago by jpflori

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

comment:32 Changed 5 years ago by jpflori

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

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

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

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

comment:33 Changed 5 years ago by jpflori

One could argue that wheezy has LTS till may 2018:

comment:34 Changed 5 years ago by 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?

comment:35 follow-ups: Changed 5 years ago by jpflori

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

comment:36 in reply to: ↑ 35 Changed 5 years ago by 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...

comment:37 Changed 5 years ago by 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.

comment:38 Changed 5 years ago by git

  • Commit changed from c39a193b70b7d0e32f690b307dcccf3c123374d1 to 9573e155b79a719db84d0ea2d2842abb7885d84e

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

f68bc8eupgrade mpir to 3-0-0
8d16afbMerge remote-tracking branch 'trac/develop' into mpir300
0f365fcMerge branch 'yasm130' into mpir300
16058efAdd build time yasm dependency to mpir.
357103aMerge branch 'public/22493' of git://trac.sagemath.org/sage into mpir300
8ddc2f1MPIR 3.0.0 does not build yasm anymore.
8205366But MPIR always looks for it even on archs where it is not used.
9573e15Check GNU as version when building MPIR.

comment:39 Changed 5 years ago by jpflori

  • Status changed from needs_info to needs_review

comment:40 Changed 5 years ago by git

  • Commit changed from 9573e155b79a719db84d0ea2d2842abb7885d84e to cb8a3f7beeb1fd57d9a7ce3180bffad7f78867cf

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

cb8a3f7Echo comment when skipping yasm check.

comment:41 Changed 5 years ago by git

  • Commit changed from cb8a3f7beeb1fd57d9a7ce3180bffad7f78867cf to aa0b222388e27db40c9da7e5a91da4f08401c854

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

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

comment:42 Changed 5 years ago by jpflori

It would be nice to get this into Sage 8.0.

comment:43 Changed 5 years ago by fbissey

  • Status changed from needs_review to positive_review

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

comment:44 Changed 5 years ago by jpflori

-bash-4.3$ uname -m
00F84C0C4C00

comment:45 Changed 5 years ago by fbissey

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

comment:46 Changed 5 years ago by 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?

comment:47 follow-up: Changed 5 years ago by 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.

comment:48 in reply to: ↑ 47 Changed 5 years ago by 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.

comment:49 Changed 5 years ago by fbissey

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

comment:50 Changed 5 years ago by vbraun

  • Status changed from positive_review to needs_work

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

comment:51 Changed 5 years ago by jpflori

Debian 7 again :/

comment:52 Changed 5 years ago by 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.

comment:53 Changed 5 years ago by 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 :/

comment:54 follow-ups: Changed 5 years ago by 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...

comment:55 Changed 5 years ago by vbraun

PS:

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

comment:56 in reply to: ↑ 54 Changed 5 years ago by 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.

comment:57 Changed 5 years ago by 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).

comment:58 in reply to: ↑ 35 Changed 5 years ago by 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...

comment:59 Changed 5 years ago by 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).

comment:60 in reply to: ↑ 54 Changed 5 years ago by 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!

comment:61 Changed 5 years ago by git

  • Commit changed from aa0b222388e27db40c9da7e5a91da4f08401c854 to fea0baea54a96d7ae74193295f3fb8620cf0d83e

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

7467913Upgrade to libpng-1.6.28
61ff918Merge remote-tracking branch 'trac/u/jdemeyer/upgrade_to_latest_libpng' into libpng1629
aa28f4cBump to libpng 1.6.29.
be90134Merge remote-tracking branch 'trac/public/22493' into mpir300
fea0baeRemove useless gcc check when looking for old as.

comment:62 Changed 5 years ago by jpflori

Argh, I merged unrelated stuff.

comment:63 Changed 5 years ago by git

  • Commit changed from fea0baea54a96d7ae74193295f3fb8620cf0d83e to c9eaefcc84a3f4473b30d93d697d684135d69d6c

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

c9eaefcRemove useless gcc check when looking for old as.

comment:64 Changed 5 years ago by jpflori

  • Status changed from needs_work to needs_review

comment:65 Changed 5 years ago by fbissey

  • Status changed from needs_review to positive_review

Once again to the bots.

comment:66 Changed 5 years ago by vbraun

  • Status changed from positive_review to needs_work
[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...

comment:67 Changed 5 years ago by git

  • Commit changed from c9eaefcc84a3f4473b30d93d697d684135d69d6c to 01c90970e9fe648a9374cd02be24c3d6d8da3dab

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

01c9097Remove broken spaces.

comment:68 Changed 5 years ago by jpflori

  • Status changed from needs_work to needs_review

comment:69 Changed 5 years ago by jpflori

@francois: push the button again?

comment:70 Changed 5 years ago by dimpase

  • Reviewers changed from François Bissey to François Bissey, Dima Pasechnik
  • Status changed from needs_review to positive_review

comment:71 Changed 5 years ago by vbraun

  • Branch changed from public/22493 to 01c90970e9fe648a9374cd02be24c3d6d8da3dab
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:72 follow-up: Changed 5 years ago by mmezzarobba

  • Commit 01c90970e9fe648a9374cd02be24c3d6d8da3dab deleted
+# 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...

comment:73 in reply to: ↑ 72 Changed 5 years ago by mmezzarobba

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

comment:74 follow-up: Changed 5 years ago by jdemeyer

This ticket caused a significant performance regression: #23327

comment:75 in reply to: ↑ 74 Changed 5 years ago by tscrim

Replying to jdemeyer:

This ticket caused a significant performance regression: #23327

This is not fixed by #23146?

Note: See TracTickets for help on using tickets.