GMP-ECM using obsolete asm syntax on mips architecture

[Etn40ff]

According to GCC 4.4 release notes:

"""
The MIPS port no longer recognizes the h asm constraint. It was necessary to remove this constraint in order to avoid generating unpredictable code sequences.
One of the main uses of the h constraint was to extract the high part of a multiplication on 64-bit targets. For example:

    asm ("dmultu\t%1,%2" : "=h" (result) : "r" (x), "r" (y));

You can now achieve the same effect using 128-bit types:

    typedef unsigned int uint128_t __attribute__((mode(TI)));
    result = ((uint128_t) x * y) >> 64;

The second sequence is better in many ways. For example, if x and y are constants, the compiler can perform the multiplication at compile time. If x and y are not constants, the compiler can schedule the runtime multiplication better than it can schedule an asm statement.
"""

Unfortunately the latest version of GMP-ECM still uses this construction making it impossible to build on mips:

...
In file included from sp.h:90:0,
                 from sp.c:23:
sp.c: In function 'sp_spp':
longlong.h:936:3: error: impossible constraint in 'asm'
   __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
   ^
sp.h:425:3: note: in expansion of macro 'umul_ppmm'
   umul_ppmm (u, v, x, y);
   ^
longlong.h:936:3: error: impossible constraint in 'asm'
   __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
   ^
sp.h:406:3: note: in expansion of macro 'umul_ppmm'
   umul_ppmm (q2, tmp, q1, di);
   ^
longlong.h:936:3: error: impossible constraint in 'asm'
   __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
   ^
sp.h:407:3: note: in expansion of macro 'umul_ppmm'
   umul_ppmm (dqh, dql, q2, d);
   ^
longlong.h:936:3: error: impossible constraint in 'asm'
   __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
   ^
sp.h:434:3: note: in expansion of macro 'umul_ppmm'
   umul_ppmm (u, v, x, x);
   ^
longlong.h:936:3: error: impossible constraint in 'asm'
   __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
   ^
sp.h:406:3: note: in expansion of macro 'umul_ppmm'
   umul_ppmm (q2, tmp, q1, di);
   ^
longlong.h:936:3: error: impossible constraint in 'asm'
   __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
   ^
sp.h:407:3: note: in expansion of macro 'umul_ppmm'
   umul_ppmm (dqh, dql, q2, d);
   ^
longlong.h:936:3: error: impossible constraint in 'asm'
   __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
   ^
sp.h:434:3: note: in expansion of macro 'umul_ppmm'
   umul_ppmm (u, v, x, x);
   ^
longlong.h:936:3: error: impossible constraint in 'asm'
   __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
   ^
sp.h:406:3: note: in expansion of macro 'umul_ppmm'
   umul_ppmm (q2, tmp, q1, di);
   ^
longlong.h:936:3: error: impossible constraint in 'asm'
   __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
   ^
sp.h:407:3: note: in expansion of macro 'umul_ppmm'
   umul_ppmm (dqh, dql, q2, d);
   ^
...

CC: @zimmermann6 @dimpase

Component: packages: standard

Keywords: GMP-ECM

Reviewer: Dima Pasechnik

Issue created by migration from https://trac.sagemath.org/ticket/17749

[jdemeyer]

comment:1

This should be reported upstream...

[Etn40ff]

comment:3

It turns out GMP-ECM is not the only package with issues:
ntl has exactly the same issue with h constraints while tachyon will completely refuse to build:

Found local metadata for tachyon-0.98.9.p5
Found local sources at /tmp/sage/upstream/tachyon-0.98.9.tar.bz2
Checksum: 9866dc93e129115994708efa6e7ca16e20d58237 vs 9866dc93e129115994708efa6e7ca16e20d58237
tachyon-0.98.9.p5
====================================================
Setting up build directory for tachyon-0.98.9.p5
Finished set up
****************************************************
Host system:
Linux strabo-build 3.16.5-gentoo #2 SMP Sat Jan 17 18:40:56 EST 2015 mips GNU/Linux
****************************************************
C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=/tmp/sage/local/bin/gcc
COLLECT_LTO_WRAPPER=/tmp/sage/local/libexec/gcc/mipsel-unknown-linux-gnu/4.9.2/lto-wrapper
Target: mipsel-unknown-linux-gnu
Configured with: ../src/configure --prefix=/tmp/sage/local --with-local-prefix=/tmp/sage/local --with-gmp=/tmp/sage/local --with-mpfr=/tmp/sage/local --with-mpc=/tmp/sage/local --with-system-zlib --disable-multilib --disable-nls --enable-languages=c,c++,fortran --disable-libitm  
Thread model: posix
gcc version 4.9.2 (GCC) 
****************************************************
Error: Sorry, your platform isn't supported by Tachyon and/or Sage. Exiting...

real    0m0.138s
user    0m0.123s
sys     0m0.014s
************************************************************************
Error installing package tachyon-0.98.9.p5
************************************************************************
Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the relevant part of the log file
  /tmp/sage/logs/pkgs/tachyon-0.98.9.p5.log
Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/tmp/sage/local/var/tmp/sage/build/tachyon-0.98.9.p5 and type 'make' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
  (cd '/tmp/sage/local/var/tmp/sage/build/tachyon-0.98.9.p5' && '/tmp/sage/sage' --sh)
When you are done debugging, you can type "exit" to leave the subshell.
************************************************************************

is it worth reporting these upstream or should just give up on having sage running on a ci20?

[jdemeyer]

comment:4

Replying to @Etn40ff:

is it worth reporting these upstream

If you care enough: of course.

For Tachyon, you should check first that the statement "your platform isn't supported by Tachyon" is actually true.

[zimmermann6]

comment:5

as for GMP-ECM, line 90 of sp.h includes longlong.h, which was copied from GMP.
The h asm constraint is in longlong.h, there is no such constraint in GMP-ECM itself.

I've looked at GMP 6.0.0: longlong.h contains a different umul_ppmm code for GCC >= 4.4.

A workaround would be to replace the longlong.h file in GMP-ECM by the one from GMP 6.0.0.
Please can you confirm it solves the problem?

Paul

[zimmermann6]

comment:6

the longlong.h from GMP 6.0.0 does not work as is. It needed a few changes. I've done them in the GMP-ECM svn repository. Please try this version. You might also discuss my changes.

Paul

[zimmermann6]

comment:7

see http://lists.gforge.inria.fr/pipermail/ecm-discuss/2015-July/004300.html

[Etn40ff]

comment:8

I am glad to see this moving in the right direction. Unfortunately I am not able to take part to the effort because my mips machine is out of commission.

[zimmermann6]

comment:9

see also Debian bug #793012. Fixed upstream in revision 2735.

Paul Zimmermann

[zimmermann6]

comment:10

this issue should be fixed by updating to GMP-ECM 7.0 (see #20385).

[mkoeppe]

comment:11

Outdated, should be closed

[dimpase]

Reviewer: Dima Pasechnik