wbhart/mpir

Multiple Precision Integers and Rationals

mpir's Issues

fft versions of mpn_mulmod_bnm1/p1 for gmp-ecm

GMP-ECM would like to use mpn_mulmod_bnm1/p1 tuned to use our FFT, etc. We agreed that the next version of MPIR after 2.6.0 would have these, with an interface the same as that of GMP. Our understanding is that the next GMP release after 5.1.0 will have these functions.

Bug in --enable-alloca support

Anton Mosunov reports:

I am having a difficulty installing mpir 2.6.0 on my system. I configure it with

./configure --prefix=/home/grads/asmosuno/local/ ABI=64 --enable-cxx --enable-gmpcompat --enable-alloca=alloca --enable-assert

and after "make", during "make check" the following tests fail:

PASS: t-fat
/bin/sh: line 1:  3537 Aborted                 "$tst" > t-gcdext.log-t 2>&1
FAIL: t-gcdext
PASS: t-get_d
PASS: t-hgcd
PASS: t-instrument
/bin/sh: line 1:  3662 Aborted                 "$tst" > t-inv_div_q.log-t 2>&1
FAIL: t-inv_div_q
/bin/sh: line 1:  3693 Aborted                 "$tst" > t-inv_div_qr.log-t 2>&1
FAIL: t-inv_div_qr
/bin/sh: line 1:  3724 Aborted                 "$tst" > t-inv_div_qr_n.log-t 2>&1
FAIL: t-inv_div_qr_n
/bin/sh: line 1:  3758 Aborted                 "$tst" > t-inv_divappr_q.log-t 2>&1
FAIL: t-inv_divappr_q
/bin/sh: line 1:  3792 Aborted                 "$tst" > t-inv_divappr_q_n.log-t 2>&1
FAIL: t-inv_divappr_q_n
/bin/sh: line 1:  3825 Aborted                 "$tst" > t-invert.log-t 2>&1
FAIL: t-invert
PASS: t-iord_u

When I remove "--enable-alloca=alloca" flag, all the tests get passed successfully. The same problem persists when I use "malloc-reentrant" instead of "alloca".

Here's an information on the one of the processors (other 63 are the same):

-bash-4.1$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 46
model name      : Intel(R) Xeon(R) CPU           X7560  @ 2.27GHz
stepping        : 6
cpu MHz         : 2261.137
cache size      : 24576 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 x2apic popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4522.27
clflush size    : 64
cache_alignment : 64
address sizes   : 44 bits physical, 48 bits virtual
power management:

Infinite recursion in mpn_copyi, mpn_copyd

Adam Markiewicz reports....

a compiler error about endless recursion that comes from two files:
mpn\generic\copyd.c
and
mpn\generic\copyi.c

They are rather simple and the problem comes from the fact that the macros used in the bodies use the same name of the functions in their definitions. The conclusion: The warning from the compiler is real. Such definition indeed causes endless recursion.

The solution for that I've found in different headers.
mpn_copyi() and mpn_copyd() have their optimized ASM versions.
What is missing in those headers in my opinion is preprocessor check:

if !HAVE_NATIVE_mpn_copyi

and

if !HAVE_NATIVE_mpn_copyd

respectively (remember to close it with #endif)

Problems with @GOT on Mac OS 10.4/5

JP Flori wrote that some Sage users are still having trouble with @got on Max OS, e.g.

https://groups.google.com/forum/#!msg/sage-devel/R43tQAKI8gA/8uyBkY67Tu4J

Compiler warning under g++ 4.8

Mike Stillman reported the following warning message when compiling under g++, 4.8.

---

include/gmpxx.h:671:28: warning: conversion to ‘int’ from ‘long unsigned int’ may alter its value [-Wconversion]
#define __GMP_ULI_LIMBS (1 + (8 * sizeof (mpir_ui) - 1) / GMP_NUMB_BITS)

Retune for all platforms after new division code added

There is new basecase and divide-and-conquer division code which means we need to retune on all platforms.

M4 behaving badly wrt underquoting

JP Flori reports:

Some versions of m4 behave badly and underquoting can lead to wrong (empty) expansion.

Here is the command we use to modify the asm files [in Sage]:

find mpn -name '*.asm' -exec sed -i 's/define(\(OPERATION[^,]*\),/define(\`\1'"'"',/' {} \;

Fix --without-fft option

Currently, compiling with the --without-fft option may not work as expected. It should not only stop the FFT being called at runtime, but stop it being built.

use __INTEL_COMPILER instead of INTEL_COMPILER in longlong.inc files

Brian Gladman writes:

I found an issue with the predefined symbol we use to detect the Intel compiler - we use INTEL_COMPILER but on Windows, at least, the two possible defines are __INTEL_COMPILER and __ICL. As far as I can tell the equivalent defines on Unix/Linux are __INTEL_COMPILER and __ICC. So I don't believe that INTEL_COMPILER is correct on either platform.

I have changed the INTEL_COMPILER define in all Windows specific files to __INTEL_COMPILER and ensured that the __ICL define is used where appropriate.

But I have NOT updated any Unix/Linux specific files since the defines need to be checked out by an Intel compiler user on Unix/Linux.

MPIR on ARM with raring binutils is broken

Julien Puydt reported that MPIR on ARM with raring binutils is broken.

See http://trac.sagemath.org/sage_trac/ticket/14450

Julien writes:

I have checked on the MPIR svn&git trees that mpn/arm/udiv.asm still uses [ ... ] instead of [...] and hence won't compile with ubuntu raring's binutils.

stdint detection is broken

Some linbox issues arose due to stdint detection in MPIR:

http://trac.sagemath.org/sage_trac/ticket/13137

Marc Glisse writes:

mpir.h could define a macro _MPIR_H_HAVE_STDINT that mpirxx.h would check. As an alternative, since mpir.h already defines __GMP_BITS_PER_UINTMAX, mpirxx.h could test that. But in any case the stdint detection magic should not be duplicated in several files.

fft/fft_negacyclic.c is misspelled

The filename fft/fft_negacyclic.c is misspelled. This requires autoconf/automake after being fixed.

Update cpuid and build system for new Intel and AMD processors

Many new Intel and AMD processors have been released since MPIR 2.6.0 came out. We need to support these. This also includes choosing the best assembly files to use on those architectures.

Stack fault in stat.exe

Gisle Vanem reported the following stack fault and potential workaround:

I've built stat.exe (from tests/rand/stat.c etc.) and got a stack-fault
as the program enters main(). A small fix for me was to declare the locals 'fvec' and 'zvec' as static. A diff:

--- Git-latest/tests/rand/stat.c       2013-12-08 10:39:18 +0000
+++ tests/rand/stat.c  2014-01-21 13:18:07 +0000
@@ -225,8 +225,8 @@
    "                maximum value when converting real numbers to integers\n" \
    "";

-  mpf_t fvec[FVECSIZ];
-  mpz_t zvec[FVECSIZ];
+  static mpf_t fvec[FVECSIZ];
+  static mpz_t zvec[FVECSIZ];
  unsigned long int f, n, vecentries;
  char *filen;
  FILE *fp;

---

Or adding '-stack:5000000' to the link stage works too.

From MSDN I read the _chk_stk function is by default called when the local variables exceeds 4K bytes. But the MSVC compiler doesn't warn me! Disassembling stat.obj
reveals this:

_main:
push ebp
mov ebp,esp
mov eax,0x002abb98
call j^__chkstk

Believe it or not, but EAX=0x002abb98 = 2.8 MByte!!
I've build with option '-Gs'. See here:
http://support.microsoft.com/kb/100775

Incorrect linking of object files with Visual Studio 2008

Adam Markiewicz reports:

The link command of mpirxx in DLL version is wrong, as it simply copies the same object files as used for mpir.

His setup is MPIR 2.6.0 for Windows XP 32-bit 'penryn' with Visual Studio 2008.

make tune (MULMOD_TAB) segfaults on mark (sparc64)

Make tune segfaults when running the fft tuning code on a sparc64 architecture (skynet/mark). This is probably a general bug in the fft tuning code as it happens elsewhere too.

MPIR issue with Sun Studio and --enable-cxx

Sage reports a problem with Sun Studio and --enable-cxx.

See http://trac.sagemath.org/ticket/7849

There is a patch for the problem.

Dual license MPIR with GPL v2+ if possible

Apparently GMP is intending to dual license an upcoming release. We cannot simply do the same. We need to replay our patches over the new GMP files.

There's around 170 files currently licensed LGPL v3+ in MPIR. Each will have to be examined very carefully to ensure it can be derived from the newer GMP files before dual licensing is done.

Tuning code overhaul

It's hard to be convinced that the tuning code is actually producing meaningful values. The code is somewhat spaghettified and needs cleaning up. It also doesn't seem to work at all on some platforms (ia64 I think).

Problem with core machine with 32 bit OS

A Sage user reported this:

https://groups.google.com/d/topic/sage-devel/9hpOtZYu8kI/discussion

It's a problem with a core machine (64 bit) with a 32 bit OS.

Slow (highly) unbalanced multiplication when using FFT

Fredrik Johansson writes:

There seems to be a pretty serious tuning issue with (highly)
unbalanced multiplication in mpir-2.6.0:

380000 x 1400 bits takes 155 us
390000 x 1400 bits takes 895 us

This is with

model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz

and

gmp-mparam.h -> mpn/x86_64/nehalem/westmere/gmp-mparam.h

I'm trying to understand what's going on in mpn_mul.
MUL_KARATSUBA_THRESHOLD is 64 (= 1024 bits), which means it should be
moving on in both cases to

if (ABOVE_THRESHOLD (un + vn, 2*MUL_FFT_FULL_THRESHOLD))
{
mpn_mul_fft_main (prodp, up, un, vp, vn);

MUL_FFT_FULL_THRESHOLD is 3008 (= 192512) bits, so it seems to be
entering the FFT in both cases and there must be a tuning issue in the
FFT.

The condition for entering the FFT code seems wrong in the first place, though.

Shouldn't it first check if the smallest operand size (vn) is in
range of any of the available Karatsuba/Tooms, and use FFT only when
the smallest operand is roughly FFT sized?

I peeked at the current GMP mpn_mul and it does not try using FFT
multiplication if BELOW_THRESHOLD(3 * vn, MUL_FFT_THRESHOLD)... this
sounds more sensible.

make tune (MULMOD_TAB) segfaults on sextus (netburst)

When running make tune on a netburst architecture (sextus), the FFT tuning code segfaults. This is probably a general bug in the tuning code as it happens on other architectures.

.o files containing no symbols on MinGW64

Dan Grayson writes:

Under mingw64 (harbored by cygwin) yasm creates *.o files with no
useful external symbols in them, and pari doesn't like that. (I'm
porting Macaulay2.)

    freedom$ pwd
    /home/dan/src/M2/1.6/M2/BUILD/dan/builds.tmp/mingw/libraries/mpir/build/mpir-2.6.0/mpn
    freedom$ fgrep "configure --prefix" ../config.log
      $ ./configure
--prefix=/home/dan/src/M2/1.6/M2/BUILD/dan/builds.tmp/mingw/libraries/final
--enable-gmpcompat --enable-cxx --disable-shared
--build=i686-pc-cygwin --host=x86_64-w64-mingw32
--cache-file=/dev/null
    freedom$ for i in *.as ; do (i=`basename $i .as`.o ; set -x ;
/usr/x86_64-w64-mingw32/bin/nm $i ); done
    + /usr/x86_64-w64-mingw32/bin/nm add_err1_n.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm add_err2_n.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm addmul_2.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm divexact_1.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm divexact_by3c.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm divexact_byfobm1.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm divrem_2.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm divrem_euclidean_qr_1.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm divrem_euclidean_qr_2.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm modexact_1c_odd.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm mul_2.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm mulmid_basecase.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm sub_err1_n.o
    0000000000000000 t .text
    0000000000000000 t symlink
    + /usr/x86_64-w64-mingw32/bin/nm sub_err2_n.o
    0000000000000000 t .text
    0000000000000000 t symlink


And here's what it looks like when it assembles one of them:

    make divexact_1.lo divexact_1.o
    /bin/sh ../libtool --mode=compile --tag=CC ../strip_fPIC.sh
../yasm/yasm -I .. -f x64  -o divexact_1.lo `test -f 'divexact_1.as'
|| echo './'`divexact_1.as
    libtool: compile:  ../strip_fPIC.sh ../yasm/yasm -I .. -f x64
divexact_1.as -o divexact_1.o
    ../yasm/yasm -I .. -f x64 divexact_1.as -o divexact_1.o
    divexact_1.as:1: warning: ignoring unrecognized character `!'
    divexact_1.as:1: warning: ignoring unrecognized character `<'
    divexact_1.as:1: warning: ignoring unrecognized character `>'
    divexact_1.as:1: warning: ignoring unrecognized character `M-^?'
    divexact_1.as:1: warning: ignoring unrecognized character `M-~'
    divexact_1.as:1: warning: ignoring unrecognized character `.'
    make: Nothing to be done for `divexact_1.o'.

The unrecognized characters don't occur in the file.

Generic build option for Sage

Jeroen Demeyer wrote:

I would like to a configuration option to build a "generic"
binary meaning one which would run on any CPU of a given architecture
(e.g. x86_64). It could still use assembly code, but only instructions
which exist on every CPU of a given architecture.

New assembly superoptimiser

We need to write a new assembly superoptimiser so we can continue to superoptimise assembly code for new architectures as the come out. For example, I have heard that the new Haswell chips can sustain 1 cycle multiplies!

Update mpirbench

The mpirbench program (see the website) has not been updated in a long time. After the recent division code changes it would be great to see how we are doing compared to MPIR 2.6.0 and GMP 5.1.3.

ICC build problem

Jeff Gilchrist reports:

On my Linux system
there is both GCC and ICC installed. I can build MPIR with ICC. But
if I pick ./configure CC=gcc then configure will work but I get an
error compiling, it seems that it is picking up some ICC files:

In file included from modules/parsers/gas/gas-parse.c:36:
/opt/sharcnet/intel/12.1.3/icc/include/math.h:27:3: error: #error
"This Intel <math.h> is for use with only the Intel compilers!"
make[4]: *** [gas-parse.o] Error 1
make[4]: Leaving directory `/orc_lfs/scratch/jeffg/mpir-2.6.0/yasm'

I don't have this issue with GMP 5.0.5, it will let me do ./configure
CC=gcc just fine and complete a make and make check. Sometimes I need
to compile with GCC for other software that I can't get to compile
with ICC.

libspeed needs updating

We have not been keeping libspeed up-to-date, so not all mpn functions can be timed using it. The code has become spaghettified and needs cleaning up and perhaps documenting.

Have tuning for MUL_FFT_FULL_THRESHOLD use new FFT tuning parameters

Currently tuning has to be done twice to get the correct MUL_FFT_FULL_THRESHOLD after the FFT tuning parameters have changed.

Pretty much the entire tuning framework needs a serious overhaul.

Support sandybridge on OSX

Oleksandr Motsak supplied the following patch to support sandybridge on OSX:

configure.in:

   # 32bit apple darwin doesn't like our PIC format asm code
    case $host in
+        sandybridge-apple-darwin* |
     core2-apple-darwin* | penryn-apple-darwin*)
path="x86/applenopic/core2 x86/applenopic" ;;
        prescott-apple-darwin* | pentium4-apple-darwin*)
path="x86/applenopic" ;;
        pentium3-apple-darwin* | pentium2-apple-darwin*)
path="x86/applenopic" ;;
        i686-apple-darwin* | pentiumpro-apple-darwin*)
path="x86/applenopic" ;;
        core-apple-darwin*)
path="x86/applenopic" ;;
        *)                                                      ;;
    esac

bug on OSX with FSF GCC and Cygwin on XP with zn_poly test suite built against MPIR 2.6.0

According to Sage http://trac.sagemath.org/ticket/13947 there's a consistent bug when building zn_poly against MPIR-2.6.0.

Commented assembly code

Much of our assembly code is not commented. Thus it takes an extended effort to read it. It should contain readable comments explaining what it is doing and why.

Test failure -- t-assign

Thakur Gautam wrote the following:

I am attempting to build MPIR with c++ support.

My build environment -
OS - Win8 Pro (64bit)
CPU - i7 3740QM (config chose sandybridge)
compiler - GCC 4.7.2 - mingw-w64 in msys

Source was download straight from github and is the latest dev version.
I made the builds in the same directory as source.

Configure was passed only ./configure --enable-cxx ABI=64

Make completed successfully but make check failed in the CXX directory on t-assign. All other tests passed upto that point.

I have separately built a C only version of MPIR and that cleared all tests.

The t-assign log txt is given below,

:

FAIL: t-assign.exe (exit: 255)

t-assign.cc:127: GNU MP assertion failed: b == 0x1234567812345678

Problems cross-compiling MPIR 2.6.0 from Debian to MinGW-64

JP Flori writes:

I had some troubles cross-compiling MPIR from Debian for MinGW-64 (using the debian provided mingw packages):

• most if not all (.asm, not sure for the others) files in mpn/x86_64w and surely sudirs have DOS file endings and make the compilation fail, running dos2unix solves the issue;
• when configuring MPIR to be cross-compiled, YASM also gets configured to be cross-compiled and so cannot be run on Linux, the solution being to reconfigure YASM after configuring MPIR in the top level directory not to use --host=x86_64-w64-mingw32 (or whatever version of MinGW[-64] you want to use).
  After applying these two fixes, MPIR seems to compile fine (the static lib at least).

Fix format specifiers for size_t and intmax_t

We are currently using incorrect format specifiers for printf and friends when printing size_t and intmax_t's. This causes copious compiler complaints.

gcc63 does not build a 32 bit sparc library

JP Flori writes:

Trying to compile (a 32bits version of) MPIR on a Debian sparc64, I encountered what looks like
http://lists.gnu.org/archive/html/coreutils/2012-10/msg00065.html
reported for GMP.

Lots of messages as follows:
tmp-submul_1.s:279: (Requires v9|v9a|v9b; requested architecture is sparclite.)
tmp-addmul_1.s:306: (Requires v9|v9a|v9b; requested architecture is sparclite.)
tmp-addmul_1.s:307: Error: tmp-submul_1.s:282: Architecture mismatch on "lduw".
Error: Architecture mismatch on "ldx".tmp-addmul_1.s:307: (Requires v9|v9a|v9b; requested architecture is sparclite.)

tmp-submul_1.s:282: (Requires v9|v9a|v9b; requested architecture is sparclite.)
tmp-addmul_1.s:309: Error: Architecture mismatch on "sllx".
tmp-addmul_1.s:309: (Requires v9|v9a|v9b; requested architecture is sparclite.)
tmp-submul_1.s:288: Error: Architecture mismatch on "stw".
tmp-submul_1.s:288: tmp-addmul_1.s:313: (Requires v9|v9a|v9b; requested architecture is sparclite.)Error:
Architecture mismatch on "stw".
tmp-addmul_1.s:313: tmp-submul_1.s:289: (Requires v9|v9a|v9b; requested architecture is sparclite.)Error: Architecture mismatch on "srlx".

The computer is gcc63 from GCC compile farm.

Also note it fails to configure with CFLAGS empty which is a little boring:
checking ABI=32
checking compiler gcc -m32 -O2 -Wa,-xarch=v8plus ... no, gcc-4.3.2 on 64bit is bad , try -O1 or -fno-strict-aliasing for the flags, program does not run
checking compiler gcc -O2 -Wa,-xarch=v8plus ... no, gcc-4.3.2 on 64bit is bad , try -O1 or -fno-strict-aliasing for the flags, program does not run
configure: error: could not find a working compiler, see config.log for details

make tune (MULMOD_TAB) takes forever on ia64

When running make tune, the fft tuning code hangs on ia64. This is likely a general issue with the fft tuning code, not platform specific.

Assertion failure in MPIR FFT

Dan Grayson encountered the following assertion in Macaulay 2, coming from MPIR:

Macaulay2, version 1.5.0.1
with packages: ConwayPolynomials, Elimination, IntegralClosure, LLLBases, PrimaryDecomposition, ReesAlgebra, TangentCone

i1 : version

o1 = HashTable{architecture => x86_64                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     }
               build => x86_64-apple-darwin
               compile node name => thallium.home
               compile time => Apr 22 2013, 11:06:48
               compiler => gcc 4.8.0
               configure arguments =>  '--enable-encap' '--enable-download' '--enable-common-staging-area' 'CC=gcc -m64' 'CXX=g++ -m64' '--build=x86_64-apple-darwin' '--enable-debug' '--disable-optimize' '--prefix=/usr' 'build_alias=x86_64-apple-darwin'
               dumpdata => false
               endianness => dcba
               executable extension => 
               factory version => 3.1.6
               flint version => not present
               frobby version => 0.9.0
               gc version => 7.3 alpha 3
               givaro version => not present
               gmp version => not present
               host => x86_64-apple-darwin
               issue => 10.8
               libfac version => 3.1.6
               linbox version => not present
               M2 name => M2
               M2 suffix => 
               machine => x86_64-MacOS-10.8
               mpfr version => 3.1.2
               mpir version => 2.6.0
               mysql version => not present
               ntl version => 5.5.2
               operating system => MacOS
               operating system release => 10.8
               packages => Style Macaulay2Doc FirstPackage Parsing Classic Browse Benchmark Text SimpleDoc PackageTemplate PrimaryDecomposition FourierMotzkin Dmodules Depth Elimination GenericInitialIdeal IntegralClosure HyperplaneArrangements LexIdeals Markov NoetherNormalization Points ReesAlgebra Regularity SchurRings SymmetricPolynomials SchurFunctors SimplicialComplexes LLLBases TangentCone ChainComplexExtras Schubert2 PushForward LocalRings BoijSoederberg BGG Bruns InvolutiveBases ConwayPolynomials EdgeIdeals FourTiTwo StatePolytope Polyhedra Polymake gfanInterface PieriMaps Normaliz Posets XML OpenMath SCSCP RationalPoints MapleInterface ConvexInterface SRdeformations NumericalAlgebraicGeometry BeginningMacaulay2 FormalGroupLaws Graphics WeylGroups HodgeIntegrals Cyclotomic Binomials Kronecker Nauty ToricVectorBundles ModuleDeformations PHCpack SimplicialDecomposability BooleanGB AdjointIdeal Parametrization Serialization NAGtypes NormalToricVarieties DGAlgebras Graphs GraphicalModels BIBasis KustinMiller Units MonomialMultiplierIdeals NautyGraphs VersalDeformations CharacteristicClasses RandomObjects RandomPlaneCurves RandomSpaceCurves RandomGenus14Curves RandomCanonicalCurves RandomCurves TensorComplexes MonomialAlgebras QthPower EliminationMatrices EllipticIntegrals Triplets
               pari version => 2.5.3
               pointer size => 8
               python version => not present
               readline version => 6.0
               scscp version => not present
               threads => false
               VERSION => 1.5.0.1

o1 : HashTable

i2 : sqrt 2p3000000
mulmod_2expp1_basecase.c:51: GNU MP assertion failed: !((xp) + (n) > (yp) && (yp) + (n) > (xp))

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x1903 of process 5959]
0x00007fff91e34212 in __pthread_kill () from i386:x86-64
(gdb) where
#0  0x00007fff91e34212 in __pthread_kill () from i386:x86-64
#1  0x00007fff8fbd5b54 in pthread_kill () from i386:x86-64
#2  0x00007fff8fc19dce in abort () from i386:x86-64
#3  0x0000000100a20ea0 in __gmp_assert_fail (filename=<optimized out>, linenum=<optimized out>, 
    expr=0x100b08158 "!((xp) + (n) > (yp) && (yp) + (n) > (xp))") at assert.c:49
#4  0x0000000100a4a430 in __gmpn_mulmod_2expp1_basecase (xp=0x10fe4e848, yp=<optimized out>, zp=<optimized out>, c=<optimized out>, b=<optimized out>, 
    tp=0x10fe538a8) at mulmod_2expp1_basecase.c:51
#5  0x0000000100a2b659 in __mpir_fft_mulmod_2expp1 (r1=0x107fdf180, i1=0x107fd66d0, i2=0x107fd38b0, r_limbs=1472, depth=5, w=92) at mulmod_2expp1.c:125
#6  0x0000000100a49e5d in __gmpn_mulmod_Bexpp1 (r=0x107fdf180, i1=<optimized out>, i2=<optimized out>, limbs=1472, tt=<optimized out>) at mulmod_bexpp1.c:74
#7  0x0000000100a2bef7 in __gmpn_mulmod_Bexpp1_fft (op=0x107fdf180, pl=1472, n=<optimized out>, nl=<optimized out>, m=<optimized out>, ml=1465)
    at mulmod_2expp1.c:238
#8  0x0000000100a63b37 in __gmpn_inv_div_qr_n (qp=0x107ffbfc0, np=0x107ff3560, dp=<optimized out>, dn=1465, inv=<optimized out>) at inv_div_qr_n.c:89
#9  0x0000000100a632fb in __gmpn_inv_div_qr (qp=0x107ffbfc0, np=0x107ff6328, nn=<optimized out>, dp=0x101fde8e0, dn=1465, dinv=<optimized out>)
    at inv_div_qr.c:181
#10 0x0000000100a52d25 in __gmpn_tdiv_qr (qp=<optimized out>, rp=0x107ff91e0, qxn=<optimized out>, np=<optimized out>, nn=2930, dp=<optimized out>, 
    dn=<optimized out>) at tdiv_qr.c:144
#11 0x0000000100a4db70 in mpn_intdivrem (qp=0x101fd8d50, np=0x10fbde8a8, nn=2930, dp=<optimized out>, dn=1465, qxn=0) at sqrtrem.c:96
#12 0x0000000100a4e043 in mpn_dc_sqrtrem (sp=0x101fd8d50, np=0x10fbdbae0, n=2930) at sqrtrem.c:259
#13 0x0000000100a4e00b in mpn_dc_sqrtrem (sp=0x101fd31c0, np=0x10fbd03c0, n=5860) at sqrtrem.c:256
#14 0x0000000100a4e00b in mpn_dc_sqrtrem (sp=0x101fc7aa8, np=0x10fbb9590, n=11719) at sqrtrem.c:256
#15 0x0000000100a4e00b in mpn_dc_sqrtrem (sp=0x101fb0c70, np=0x10fb8b920, n=23438) at sqrtrem.c:256
#16 0x0000000100a4e00b in mpn_dc_sqrtrem (sp=0x101f83000, np=0x10fb30040, n=46876) at sqrtrem.c:256
#17 0x0000000100a4e92e in __gmpn_sqrtrem (sp=0x101f83000, rp=0x10fb30040, np=0x11010b000, nn=<optimized out>) at sqrtrem.c:353
#18 0x0000000100690df3 in mpfr_sqrt (r=0x10349fb70, u=0x10349fd50, rnd_mode=MPFR_RNDN) at sqrt.c:141
#19 0x0000000100029895 in gmp_sqrt (x=0x10349fd50) at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/gmp.d:1033
#20 0x00000001000eb47b in sqrt_1 (a=0x110087a30) at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/actors3.d:1075
#21 0x00000001000a63cc in evaluate_eval (c=0x10349fdb0) at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/evaluate.d:1270
#22 0x00000001000a9148 in evaluate_evalexcept (c=0x10349fdb0) at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/evaluate.d:1404
#23 0x00000001001c87c5 in readeval4 (file=0x110075bc0, printout=1 '\001', dictionary=0x10346b210, returnLastvalue=0 '\000', 
    stopIfBreakReturnContinue=0 '\000', returnIfError=0 '\000') at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/interp.d:176
#24 0x00000001001c9c9b in readeval3 (file=0x110075bc0, printout=1 '\001', dc=0x110075c10, returnLastvalue=0 '\000', stopIfBreakReturnContinue=0 '\000', 
    returnIfError=0 '\000') at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/interp.d:270
#25 0x00000001001ca936 in loadprint (filename=0x1028703f0, dc=0x110075c10, returnIfError=0 '\000')
    at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/interp.d:341
#26 0x00000001001cba10 in commandInterpreter_2 (e=0x101ec8d70) at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/interp.d:458
#27 0x00000001000a63cc in evaluate_eval (c=0x10346b630) at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/evaluate.d:1270
#28 0x00000001000a6ee2 in evaluate_eval (c=0x10346b690) at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/evaluate.d:1302
#29 0x00000001000a8851 in evaluate_eval (c=0x1100723f0) at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/evaluate.d:1380
#30 0x00000001000a9148 in evaluate_evalexcept (c=0x1100723f0) at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/evaluate.d:1404
#31 0x00000001001c87c5 in readeval4 (file=0x10296d440, printout=0 '\000', dictionary=0x10295fb10, returnLastvalue=0 '\000', 
    stopIfBreakReturnContinue=0 '\000', returnIfError=0 '\000') at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/interp.d:176
#32 0x00000001001c9c9b in readeval3 (file=0x10296d440, printout=0 '\000', dc=0x10296d300, returnLastvalue=0 '\000', stopIfBreakReturnContinue=0 '\000', 
    returnIfError=0 '\000') at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/interp.d:270
#33 0x00000001001c9da4 in readeval (file=0x10296d440, returnLastvalue=0 '\000', returnIfError=0 '\000')
    at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/interp.d:280
#34 0x00000001001ccbfe in interp_process () at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/interp.d:594
#35 0x000000010001877c in interpFunc (vargs2=0x102927f90) at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/d/M2lib.c:551
#36 0x000000010037283a in ThreadTask::run (this=<error reading variable: Could not find the frame base for "ThreadTask::run(SupervisorThread*)".>, 
    thread=<error reading variable: Could not find the frame base for "ThreadTask::run(SupervisorThread*)".>)
    at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/system/supervisor.cpp:358
#37 0x0000000100372bb5 in SupervisorThread::threadEntryPoint (
    this=<error reading variable: Could not find the frame base for "SupervisorThread::threadEntryPoint()".>)
    at /Users/dan/src/M2/github/Macaulay2-M2-clone/M2/BUILD/dan/../../Macaulay2/system/supervisor.cpp:415
#38 0x0000000100372c38 in ?? ()
(gdb) 

t-scan crashes under GCC 4.8.0

Dan Grayson reports:

The t-scan test crashes, in mpir 2.6.0, under mac os x, with gcc 4.8.0.

/bin/sh: line 1: 73249 Segmentation fault: 11 "$tst" > t-scan.log-t 2>&1
FAIL: t-scan

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/encap/gcc-trunk/libexec/gcc/x86_64-apple-darwin12.0.0/4.8.0/lto-wrapper
Target: x86_64-apple-darwin12.0.0
Configured with: ../trunk/configure --prefix=/usr/local/encap/gcc-trunk --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120805 (experimental) (GCC)

Add Windows build instructions to doc/mpir.texi

Currently the instructions for building with MSVC and in other ways on Windows are either undocumented or in text files. This should be carefully documented in the main pdf.

mpz_next_likely_prime_p

Case Van Horsen wrote the following:

A user of gmpy2 reported that gmpy2.next_prime() returned composite
values quite frequently. For example:

gmpy2.next_prime(2357_7069-1)==2357_7069
True

I believe this is caused by the following line in next_likely_prime.c:

if (mpz_miller_rabin (p, 2, rnd))

The Miller-Rabin test is only repeated twice. IIRC, 25 repeats used to
be the default.

Problems building with clang on OSX

Sage (via JP Flori) reported that MPIR does not build with clang on OSX. See http://trac.sagemath.org/sage_trac/ticket/13137#comment:23

Check [email protected]

This email address has not been checked since J. Moxham passed away. If we can obtain access there may be bug reports at that email address.

The website should be updated accordingly.

Support Cygwin 64

Since the last release (2.6.0) of MPIR, Cygwin 64 has been released and MPIR does not build with it.

Note Cygwin 64 does not use the same conventions for C integer sizes as MSVC, but uses Linux conventions. It does however use the Windows calling conventions.

Remove mpn/generic/dc_divappr_q_n.c

Remove mpn/generic/dc_divappr_q_n.c. This file is not used by the new division code in mpir and can be removed (probably).

Exclude clang from gcc-4.3.2 configure test

Oleksandr Motsak supplied the following patch to support clang in the gcc-4.3.2 configure test:

acinclude.m4:

GMP_PROG_CC_WORKS_PART_MAIN([$1], [gcc-4.3.2 on 64bit is bad , try -O1
or -fno-strict-aliasing for the flags],
[/* The following aborts with gcc-4.3.2 on a 64bit system which is an
unusable compiler */
-+#if defined(__GNUC__) && !defined(__INTEL_COMPILER)  && !defined(__clang__)
int __attribute__((noinline))

Proper tuning code for mpn_mulmod_Bexpp1

Currently we do not have tuning code for mpn_mulmod_Bexpp1 in mpn/generic/mulmod_bexpp1.c. This should be added.

Problems with MPIR 2.6.0 for Windows XP 32-bit 'penryn' with Visual Studio 2008

Adam Markiewicz writes:

I was trying to build MPIR for the configuration as described in the mail topic.
Unluckily so far I've failed to build static .lib. Some linking errors with I/O part of C++. I've seen similar description in some forum, without any solution so far.
But I've managed to produce working .dll with the corrections that I think could be applied to the general MPIR source code.

As VS projects from build.vc10 are not working with VS2008, I switched to the scripts from win directory.
As far as I see in the scripts' comments this was the part under Jason responsibility and I've seen the terrible information on forum.
I don't know how much of his ideas are well known and how deep should I describe them. It took me some time to analyze it, so I'll try to mark some key points.

Missing symbol ___gmpn_preinv_mod_1

In win/make.bat you may find that Jason for some reason was unsure about some ASM code and decided to regenerate it from C. You may find a paragraph below:
:: dont know what the asm version have so delete them
del preinv_divrem_1.obj preinv_mod_1.obj divrem_1.obj mod_1.obj divrem_euclidean_qr_1.obj > nul 2>&1

However, earlier, with the python script (call %python% ..\build.vc10\mpir_config.py 1), several configuration files were prepared, that specified what ASM versions were available and some constants had been specified in the generated headers (cfg.h)

The problems that I've discovered and (hopefully) corrected:
FIles:
mpn\x86w\p3\mod_1.asm
and
mpn\x86w\p6\mod_1.asm
(the same content)

Name '___gmpn_preinv_mod_1' is defined as 'global', but missing below in 'export'.
I think this was done by mistake. When python script prepares the headers it takes into account all 'global' names. I see no reason then why any 'global' should not exist as 'export' otherwise it is not consistent and not verified anywhere later against 'export'. I added the line
export ___gmpn_preinv_mod_1
in both files.

However, ASM files are being manually removed for some reason in make.bat (don't know why, nor why those).
For that reason make.bat patches the result of the python script written in config.h. You may find a paragraph in make.bat:
:: we delete asm files below for these symbols
echo #undef HAVE_NATIVE_mpn_mod_1c >> ..\config.h
echo #undef HAVE_NATIVE_mpn_divrem_1c >> ..\config.h
echo #define USE_PREINV_DIVREM_1 1 >> ..\config.h

I added there another line, which was missing:
echo #undef HAVE_NATIVE_mpn_preinv_mod_1 >> ..\config.h

(For some reason Jason decided to remove the ASM versions, remember?)
Having that defined prevents the compiler from using the C version of the function, so eventually we have none (ASM had been manually removed).

make.bat check failed on winxp/vs2008/mpir-2.6.0

redplait reports:

I try to build mpir-2.6.0 on windows xp 32bit with yasm-1.2.0 and vs2008 and got following message during make.bat check:
t-likely_prime_p.c
mpir.lib(pprime_p.obj) : error LNK2019: unresolved external symbol ___gmpn_preinv_mod_1 referenced in function ___gmpz_probab_prime_p
t-likely_prime_p.exe : fatal error LNK1120: 1 unresolved externals
ERROR

my config.params.bat:
(set LIBTYPE=lib)
(set FLAGS=/Ox /Ot /D "NDEBUG" /D "HAVE_CONFIG_H" /nologo /D "_MBCS" /GS-)
(set FLAGS1=/Oi /D "_LIB" /D "PIC" /MT)
(set MPNPATH=x86w x86w\p6 x86w\p6\mmx x86w\p6\p3mmx)
(set ABI=32)

Support full GMP 5.1 interface

We are behind in ensuring we fully support the public interface of GMP 5.1. This needs to be done, along with changing the GMP_VERSION etc in gmp.h.

The only exceptions to this are secure crypto functions which will remain exclusive to GMP.