v5.0.1, Mac, 32-bit: gmp_snprintf problem for (high) multi-limb integers

[John McDermott]

Dear all at gmplib.org,

we have come across a problem with gmp_snprintf in GMP 5.0.1 compiled on an Apple Mac in 32-bit mode. We encountered the problem in a complex situation but hope the following reproduces it in a simple way. The bottom line may be that it is a problem with the Mac gcc but it is not one that 'make check' picks up.

The compiler on this platform is

$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)
Copyright (C) 2007 Free Software Foundation, Inc.

Here is how we can reproduce this problem:

Download gmp-5.0.1.tar.bz2 from gmplib.org to the Core 2 Duo Mac, which is running Snow Leopard, Mac OS X 10.6.

Unpack GMP, change to the unpacked directory and then

$ ./configure --prefix=`pwd`/../gmpbuild ABI=32

(The config.guess result is 'core2-apple-darwin10.6.0'. We can supply the config.log if that will help.)

$ make

$ make check > ../check_log 2>&1

(We can supply this check_log if you like - all tests were PASSED.)

$ make install

Now we 'cd ..' and do

$ gcc -m32 test_gmp_snprintf.c -o test -lm gmpbuild/lib/libgmp.a -I gmpbuild/include

where the file test_gmp_snprintf.c contains

========= 8< ==========

#include <string.h>
#include <gmp.h>

int main(int argc, char*** argv)

{
 mp_limb_t x[1000];
 mp_size_t len_x;
 char buf[1000],
   str[1000]="111738634087016687677581080419779823937672962105281999064930026947977838341505382863502660652163271927890657789545865354105698690880491419382732505129685548945886493976382779091529311779061982182942409366242406420035526825355893426176";
 int i, len_str;

 puts (str);
 len_str = strlen(str);
 for (i=0;i<len_str;i++)
   str[i]-=48;
 len_x = mpn_set_str (x, (unsigned char*)str, len_str, 10);
 gmp_snprintf( buf, sizeof(buf), "%Ni", x, len_x);
 puts (buf);
 len_x = mpn_set_str (x, (unsigned char*)str, len_str, 10);
 gmp_snprintf( buf, sizeof(buf), "%Nx", x, len_x);
 puts (buf);
}

========= 8< ==========

Then execute and the result is

$ ./test
111738634087016687677581080419779823937672962105281999064930026947977838341505382863502660652163271927890657789545865354105698690880491419382732505129685548945886493976382779091529311779061982182942409366242406420035526825355893426176
111689451555805615414032818107981588794837871839722050040099065348997101234912634684766012785309874979540706551779765719722457408924701210498595751866628200302005682091843398734765152170243365003626340219745662478491402987710451697664
47f8f6d82a7cf5ae4cc763bb288c1277b721afcd304e75b6c6636bc575bc7d5d225a9a52a28a41141fafae04f4b5a1ca28f317a443995b0d87c5b2bdbe2a99794f472f86e3036a9fbc434ca40622d0ab25034c0000c29e365b8c551241fbde4800

So the second number looks different. (But the hex version seems ok - see below.)

We have built the same GMP on this platform with ABI=64 and then compiled and run the same test program in 64-bit mode and the result is

$ ./test
111738634087016687677581080419779823937672962105281999064930026947977838341505382863502660652163271927890657789545865354105698690880491419382732505129685548945886493976382779091529311779061982182942409366242406420035526825355893426176
111738634087016687677581080419779823937672962105281999064930026947977838341505382863502660652163271927890657789545865354105698690880491419382732505129685548945886493976382779091529311779061982182942409366242406420035526825355893426176
47f8f6d82a7cf5ae4cc763bb288c1277b721afcd304e75b6c6636bc575bc7d5d225a9a52a28a41141fafae04f4b5a1ca28f317a443995b0d87c5b2bdbe2a99794f472f86e3036a9fbc434ca40622d0ab25034c0000c29e365b8c551241fbde4800

which is fine. Note the hex number is the same as in the 32-bit case.

Experiments seem to show this issue turns up around the stage when the numbers involved are getting as big as 22 limbs or so.

This problem does not appear on other platforms we have tried, with various default gcc versions. It does not happen (as above) on the same platform in 64-bit mode. The problem is also not apparent with GMP 4.3.2 on this or other platforms.

There is also no problem on a linux system on which we have installed gcc 4.2.1, with GMP 5.0.1, so this seems not to be a gcc 4.2.1 issue. We know of course that this Apple version of gcc is a custom version.

Note that we _can_ reproduce this on other Macs with the same gcc/XCode and with GMP 5.0.1 and 32-bit mode, so it is not machine-specific, at least.


Best wishes,
John

--
John McDermott
Scientific Officer
Centre for Interdisciplinary Research in Computational Algebra
School of Computer Science
University of St Andrews
North Haugh, St Andrews, Fife
KY16 9SX
SCOTLAND

(Room 330, Mathematical Institute)

tel +44 1334 463813
mob +44 7941 507531

The University of St Andrews is committed to sustainable practices and the preservation of the environment.
Please do not print this email unless absolutely necessary.

The University of St Andrews is a charity registered in Scotland : No SC01353