pari gives incorrect results with GMP 4.2.4

[vinc17@…]

On my Mac OS X 10.4.11 (PowerPC), pari gives incorrect results with GMP 4.2.4 (i.e. with the gmp variant):

prunille:~> gp
Reading GPRC: /Users/vinc17/.gprc ...Done.

                  GP/PARI CALCULATOR Version 2.3.4 (released)
          PowerPC running darwin (PPC/GMP-4.2.4 kernel) 32-bit version
       compiled: Mar  9 2009, gcc-4.0.1 (Apple Computer, Inc. build 5367)
                (readline v6.0 enabled, extended help available)

                     Copyright (C) 2000-2006 The PARI Group

PARI/GP is free software, covered by the GNU General Public License, and 
comes WITHOUT ANY WARRANTY WHATSOEVER.

Type ? for help, \q to quit.
Type ?12 for how to get moral (and possibly technical) support.

parisize = 4000000, primelimit = 500000
? 17.
%1 = 1.000000000000000002257486487 E72

Can anyone reproduce this problem?

If you have the same problem, do not use the gmp variant of pari.

Note: I've reported the bug to both GMP and PARI developers. I hope that PARI developers will be able to give a simple testcase.

[vinc17@…]

Also note that I've built a universal version (ppc ppc64).

[vinc17@…]

I've got a reply from Bill Allombert (one of the PARI developer/maintainer). PARI requires

sizeof(mp_limb_t)==sizeof(long)==sizeof(long*)

so, it is not compatible with GMP built with ABI=mode32. There are several solutions:

• Do not use mode32 in the gmp port. This is annoying because the problem is not in GMP. However this may break some other software (provided by MacPorts or not). PARI is one of them and will not be fixed. MPFR is affected too (in the printf functions with length modifier M), but I'll apply a patch. Moreover, though ABI=mode32 is faster than ABI=32, the user can use ABI=64 instead of ABI=mode32.

• Never build pari against GMP for the ppc architecture.

• Have a gmp variant to choose between ABI=32 and ABI=mode32, but this is rather dangerous (because if for some reason, the ABI is changed, programs based on GMP may more or less silently fail to work, such as giving incorrect results instead of a clear error).

• Use a private version of GMP (statically linked?) for pari.

[vinc17@…]

Adding the maintainer of the gmp port to Cc.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

If mode32 already causes issues with two ports (pari and mpfr), then my initial reaction would be to abandon it for ABI=32.

What is even worse, the error, at least in the case of pari, only showed up because of erronous results.
I suspect that most projects based on gmp didn't do any testing on a PowerPC G5 processor, so ABI=32 seems a safer choice.

[vinc17@…]

The bug in MPFR is now fixed in MacPorts (note that MPFR wasn't assuming that a limb fitted in a long, it was just a confusion between a limb and a pointer to a limb). However there may be problems with other software than PARI. Unfortunately this is difficult to know, because such problems can arise under some conditions only (e.g. when some data become large enough to have some kind of overflow if a limb is stored in an unsigned long) and one may just get incorrect results, thus the error may not necessarily be detected. I don't know if many programs need to convert a limb into an explicit C native type or use a *_ui function (such as mpz_set_ui) on a limb.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

mode32 was removed in r47978.
I think this is probably the safer choice.

Does this fix pari?

[vinc17@…]

I confirm that the change fixes the problem in pari.

[(none)]

Milestone Port Bugs deleted