#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: |
Description (last modified by )
Change History (75)
comment:1 Changed 5 years ago by
- Description modified (diff)
comment:2 Changed 5 years ago by
- Branch set to public/22493
- Commit set to f68bc8ea0bcfc6d9ed6c72bbeb94e08aff527739
comment:3 Changed 5 years ago by
- Keywords days84 added
comment:4 follow-up: ↓ 5 Changed 5 years ago by
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: ↓ 6 Changed 5 years ago by
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 onarando
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
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
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: ↓ 9 Changed 5 years ago by
@vincent: do you plan on modifying this ticket to include yasm?
comment:9 in reply to: ↑ 8 Changed 5 years ago by
Replying to jpflori:
@vincent: do you plan on modifying this ticket to include yasm?
Nope. Would better be a dependency ticket.
comment:11 Changed 5 years ago by
- Commit changed from f68bc8ea0bcfc6d9ed6c72bbeb94e08aff527739 to 16058efed507d1c8137c8500f87730b0c56d9fee
comment:12 Changed 5 years ago by
- Cc jdemeyer vbraun fbissey added
- Status changed from new to needs_review
comment:13 Changed 5 years ago by
Seems to work fine for me.
comment:14 Changed 5 years ago by
this and #22748 seem to work on clang/FreeBSD.
comment:15 Changed 5 years ago by
Good to go in?
comment:16 Changed 5 years ago by
Yes.
comment:17 Changed 5 years ago by
- Commit changed from 16058efed507d1c8137c8500f87730b0c56d9fee to c39a193b70b7d0e32f690b307dcccf3c123374d1
comment:18 Changed 5 years ago by
Is that a positive review?
comment:19 Changed 5 years ago by
I would say so!
comment:20 Changed 5 years ago by
- 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
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
- Status changed from positive_review to needs_work
comment:23 Changed 5 years ago by
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
comment:24 Changed 5 years ago by
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
I'd say the assembler is yasm.
comment:26 Changed 5 years ago by
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
- Status changed from needs_work to needs_info
comment:28 Changed 5 years ago by
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
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.
comment:30 Changed 5 years ago by
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
Cannot reproduce this on an unstable debian with the exact same command lines.
comment:32 Changed 5 years ago by
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
One could argue that wheezy has LTS till may 2018:
comment:34 Changed 5 years ago by
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: ↓ 36 ↓ 58 Changed 5 years ago by
Nope, some assembly files are compiled with yasm, others with as...
comment:36 in reply to: ↑ 35 Changed 5 years ago by
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
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
- Commit changed from c39a193b70b7d0e32f690b307dcccf3c123374d1 to 9573e155b79a719db84d0ea2d2842abb7885d84e
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.
|
comment:39 Changed 5 years ago by
- Status changed from needs_info to needs_review
comment:40 Changed 5 years ago by
- Commit changed from 9573e155b79a719db84d0ea2d2842abb7885d84e to cb8a3f7beeb1fd57d9a7ce3180bffad7f78867cf
Branch pushed to git repo; I updated commit sha1. New commits:
cb8a3f7 | Echo comment when skipping yasm check.
|
comment:41 Changed 5 years ago by
- Commit changed from cb8a3f7beeb1fd57d9a7ce3180bffad7f78867cf to aa0b222388e27db40c9da7e5a91da4f08401c854
Branch pushed to git repo; I updated commit sha1. New commits:
aa0b222 | This should work and be useful on non-linux systems.
|
comment:42 Changed 5 years ago by
It would be nice to get this into Sage 8.0.
comment:43 Changed 5 years ago by
- 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
-bash-4.3$ uname -m 00F84C0C4C00
comment:45 Changed 5 years ago by
Should have known you'd have access to one of those too.
comment:46 Changed 5 years ago by
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: ↓ 48 Changed 5 years ago by
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
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
I just finished building mpir
on linux+clang without a hitch either.
comment:50 Changed 5 years ago by
- 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
Debian 7 again :/
comment:52 Changed 5 years ago by
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
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: ↓ 56 ↓ 60 Changed 5 years ago by
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
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
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
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
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
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
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
- Commit changed from aa0b222388e27db40c9da7e5a91da4f08401c854 to fea0baea54a96d7ae74193295f3fb8620cf0d83e
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.
|
comment:62 Changed 5 years ago by
Argh, I merged unrelated stuff.
comment:63 Changed 5 years ago by
- Commit changed from fea0baea54a96d7ae74193295f3fb8620cf0d83e to c9eaefcc84a3f4473b30d93d697d684135d69d6c
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.
|
comment:64 Changed 5 years ago by
- Status changed from needs_work to needs_review
comment:65 Changed 5 years ago by
- Status changed from needs_review to positive_review
Once again to the bots.
comment:66 Changed 5 years ago by
- 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
- Commit changed from c9eaefcc84a3f4473b30d93d697d684135d69d6c to 01c90970e9fe648a9374cd02be24c3d6d8da3dab
Branch pushed to git repo; I updated commit sha1. New commits:
01c9097 | Remove broken spaces.
|
comment:68 Changed 5 years ago by
- Status changed from needs_work to needs_review
comment:69 Changed 5 years ago by
@francois: push the button again?
comment:70 Changed 5 years ago by
- 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
- Branch changed from public/22493 to 01c90970e9fe648a9374cd02be24c3d6d8da3dab
- Resolution set to fixed
- Status changed from positive_review to closed
comment:72 follow-up: ↓ 73 Changed 5 years ago by
- 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
comment:74 follow-up: ↓ 75 Changed 5 years ago by
This ticket caused a significant performance regression: #23327
New commits:
upgrade mpir to 3-0-0