Re: Problem with gmp_randinit_set
Ciao,
Il Dom, 19 Febbraio 2017 9:21 am, Niels Möller ha scritto:
> But shifting, as you suggest, might be simpler, using
>
> 2 B^623 = 20023 (mod p)
A possible generalization follows:
#include
#include
#include
#include
#define GSIZE (19937 / GMP_NUMB_BITS)
#define GSHIFT (19937 % GMP_NUMB_BITS)
#define SIZE (GSIZE + 1)
#define K 20023
/* B^312 mod p */
#define B312MODP ((mp_limb_t) K << (GMP_NUMB_BITS-GSHIFT))
#define USE_NIELS_SHORTCUT (((mp_limb_t) K >> GSHIFT) == 0)
/* Reduces r modulo p in place, result is SIZE limbs (non-canonical
representation). */
static void
reduce (mp_ptr rp, mp_size_t n)
{
mp_limb_t cy, hi;
assert (n > GSIZE);
assert (GSHIFT != 0); /* 19937 is prime */
if (USE_NIELS_SHORTCUT)
{
if (n == SIZE)
return;
while (n >= 2*SIZE)
{
rp[n - SIZE] = mpn_addmul_1 (rp + n - 2*SIZE,
rp + n - SIZE, SIZE, B312MODP);
n -= GSIZE;
}
cy = mpn_addmul_1 (rp, rp + SIZE, n - SIZE, B312MODP);
if (n < 2*SIZE - 1)
cy = mpn_add_1 (rp + n - SIZE, rp + n - SIZE, 2*SIZE - n - 1, cy);
hi = rp[GSIZE];
rp[GSIZE] = cy + (hi & (((mp_limb_t)1 << GSHIFT) - 1))
+ mpn_add_1 (rp, rp, SIZE - 1, (hi >> GSHIFT) * K);
}
else
{
while (n >= 2 * GSIZE)
{
hi = mpn_rshift (rp + n - GSIZE, rp + n - GSIZE, GSIZE, GSHIFT);
cy = mpn_addmul_1 (rp + n - 2*GSIZE, rp + n - GSIZE, GSIZE, K);
rp[n - GSIZE] = cy + (hi >> (GMP_NUMB_BITS - GSHIFT));
n -= GSIZE - 1;
}
hi = mpn_rshift (rp + GSIZE, rp + GSIZE, n - GSIZE, GSHIFT);
cy = mpn_addmul_1 (rp, rp + GSIZE, n - GSIZE, K);
cy = mpn_add_1 (rp + n - GSIZE, rp + n - GSIZE, 2*GSIZE - n, cy);
rp[GSIZE] = cy + (hi >> (GMP_NUMB_BITS - GSHIFT));
}
}
int
main (int argc, char **argv)
{
mpz_t p, x, r, ref;
int i;
gmp_randstate_t rands;
mpz_inits (p, x, r, ref, NULL);
gmp_randinit_default (rands);
mpz_setbit (p, 19937);
mpz_sub_ui (p, p, K);
for (i = 0; i < 64000; i++)
{
mpz_urandomb (x, rands, 16);
mpz_rrandomb (x, rands, mpz_get_ui (x) + 2);
mpz_tdiv_r (ref, x, p);
mpz_set (r, x);
reduce (mpz_limbs_modify (r, mpz_size (r)), mpz_size(r));
mpz_limbs_finish (r, SIZE);
if (!mpz_congruent_p (r, ref, p))
{
gmp_printf ("Failed (%i) for size %d: %Zx\n"
" got: %Zx\n"
" exp: %Zx\n",
i, mpz_size (x), x, r, ref);
exit (1);
}
}
mpz_clears (p, x, r, ref, NULL);
gmp_randclear(rands);
}
Best regards,
m
--
http://bodrato.it/
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Bug Upon Make Check
Ciao, Il Dom, 19 Marzo 2017 6:41 pm, David Hadaller ha scritto: > 1 of 58 tests failed With test? You are not giving any information... > make[4]: Leaving directory '/home/david/Downloads/gmp-4.3.2/tests/mpz' ... anyway, the last release is GMP-6.1.2, please try that. Have a nice GMP experience :-) m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Problem with gmp_randinit_set
Ciao, Il Ven, 3 Marzo 2017 3:10 am, Pedro Gimeno ha scritto: > Marco Bodrato wrote, On 2017-03-02 21:37: > Just one comment. You're switching algorithms for the top half. Wouldn't > it be easier to change the key (the k[] array) instead? That might also > produce less correlation in the upper half, not sure. Obviously a y = f(x), z = f^-1(x), implies y = f(f(z)). If f(x) is a "random" permutation, f(f(x)) is less random; cycles with even order split in shorter cycles. You are right. I was lazy. But of course we do not need to use the same function for randseed, and for the legacy_randseed, as I did in my code. I vote for decryption in the main library, I like use of sum to detect the end of the loop :-) > Thanks for looking into this. Best regards, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mpz_powm_ui () for 5.1.2
Ciao, Il 2017-03-08 02:17 shen lixing ha scritto: I installed MinGW, then 'mingw-get install mingw32-gmp' , got the gmp 5.1.2 properly. The last release of the library is 6.1.2 . unsigned long long c = 10307e7 - 1; // change c,start point mpz_set_ui(b,c); mpz_mul_ui(b,b,c); mpz_powm_ui(d,a,c-1,b ); Look carefully at the documentation of the three mpz*_ui functions you use. They take an _unsigned long_ as their _ui argument. You pass an _unsigned long long_ variable, the compiler implicitly casts. Does "mingw32" means unsigned long is a 32-bit type? You should use an mpz variable to store values exceeding 2^32... Regards, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: fat_init violates host ABI on Win64
Ciao, Il Mer, 26 Aprile 2017 12:25 pm, Nicolas Hake ha scritto: > Torbjörn Granlund wrote: >> Where do we (unconditionally) rely on variable-length arrays? > > mpn/generic/sqrlo_basecase.c line 153, where SQRLO_BASECASE_ALLOC is a > non-constant expression by ultimately referencing CPUVEC_THRESHOLD if > fat.h is included. You are right, we should define a costant SQRLO_DC_THRESHOLD_LIMIT not only for the TUNE builds, but for FAT too... For sqrlo_basecase a patch like the following should work. diff -r 021277dcb21f gmp-impl.h --- a/gmp-impl.hTue Apr 18 23:47:55 2017 +0200 +++ b/gmp-impl.hWed Apr 26 18:27:38 2017 +0200 @@ -5018,7 +5018,6 @@ #undef MUL_TOOM33_THRESHOLD_LIMIT #undef MULLO_BASECASE_THRESHOLD_LIMIT #undef SQRLO_BASECASE_THRESHOLD_LIMIT -#undef SQRLO_DC_THRESHOLD_LIMIT #undef SQR_TOOM3_THRESHOLD_LIMIT #define SQR_TOOM2_MAX_GENERIC 200 #define MUL_TOOM22_THRESHOLD_LIMIT 700 @@ -5032,12 +5031,16 @@ #define SQR_TOOM8_THRESHOLD_LIMIT 1200 #define MULLO_BASECASE_THRESHOLD_LIMIT 200 #define SQRLO_BASECASE_THRESHOLD_LIMIT 200 -#define SQRLO_DC_THRESHOLD_LIMIT400 #define GET_STR_THRESHOLD_LIMIT 150 #define FAC_DSC_THRESHOLD_LIMIT2048 #endif /* TUNE_PROGRAM_BUILD */ +#if TUNE_PROGRAM_BUILD || WANT_FAT_BINARY +#undef SQRLO_DC_THRESHOLD_LIMIT +#define SQRLO_DC_THRESHOLD_LIMIT400 +#endif + #if defined (__cplusplus) } #endif Regards, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Likely GMP bug
Ciao, Il Sab, 26 Maggio 2018 11:01 pm, Niels Möller ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: > shift, that is interpreted as the odd value 2^32+1. This number has the > factorization 641 * 6700417, and if v happens to be a multiple of one of > And we have potential miscpumputatino also on 64-bit, if we jump into > the code with ulimb = 2^63, and v has a common factor with 2^64+1 = > 274177 * 67280421310721. > Is it possible to construct some examples with v a multiple of 641, and > input U such that ulimb = 2^31 after reduction? if limbs are unsigned long, and _ui functions can be used... factor = 641; /* A factor of GMP_NUMB_MAX + 2 */ vlimb = factor * (GMP_NUMB_MAX / factor - 1); ASSERT (vlimb > CNST_LIMB (1) << 31); mpz_set_ui (U, vlimb); mpz_mul_ui (U, U, somerandomdata); mpz_add_ui (U, U, CNST_LIMB (1) << 31); /* Try also sub_ui, because of MODEXACT */ > Yes. gcd (V, kV + 2^32) = gcd (V, 2^32) = 1. Not sure I see the > connection to the bug, though. I confused 32 with 31... Ĝis, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Likely GMP bug
Ciao, Il Mer, 30 Maggio 2018 10:20 am, Niels Möller ha scritto: > "Marco Bodrato" writes: > Thinking about micro optimizations... Consider >> count_trailing_zeros (c, ulimb); >> ulimb = (ulimb >> 1) >> c; > vs >> count_trailing_zeros (c, ulimb); >> ulimb >>= (c + 1); > I wonder if maybe it's preferable to always use the first variant? Both You are saying that my patch https://gmplib.org/repo/gmp/rev/e4849ae7c974 was not an emergency workaround, but a cleverly subtle optimization? Well, I have to admit that I was not aware... but thanks :-) > first variant, the first shift can be issued in parallel with ctz, If we could hint to the compiler... HINT (c >= 0 && c + 1 < ) then they should be equivalent. The optimiser of the compiler can choose the best one for the target environment :-) If we define c as unsigned, we do not need other hints, the compiler has enough information to understand that ulimb>>(c+1) can be implemented as (ulimb>>1)>>c for all non-undefined cases. The vice-versa is not as easy. Maybe, of course, that current compilers does not take care of this possible optimisation... Ĝis, m -- http://bodrato.it/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Likely GMP bug
Ciao,
Il Lun, 28 Maggio 2018 10:00 pm, Niels Möller ha scritto:
> I'd suggest the below (complete file, I think that's more readable
The code is clean.
You removed all gotos...
> The last part of the function requires vlimb odd, but tolerates
> arbitrary u, including 0.
... the effect is that in many cases (if U don't need reduction modulo V)
the trailing zeros of U are removed twice.
> This would be a candidate gcd_11 or gcd_11_odd.
Maybe, if we keep both parts in the same function, some code replication
can be good?
Is something like the following too redundant?
mp_limb_t
mpn_gcd_1 (mp_srcptr up, mp_size_t size, mp_limb_t vlimb)
{
mp_limb_t ulimb;
unsigned long zero_bits, u_low_zero_bits;
int c;
ASSERT (size >= 1);
ASSERT (vlimb != 0);
ASSERT_MPN_NONZERO_P (up, size);
ulimb = up[0];
/* Need vlimb odd for modexact, want it odd to get common zeros. */
count_trailing_zeros (zero_bits, vlimb);
vlimb >>= zero_bits;
if (size > 1)
{
/* Must get common zeros before the mod reduction. If ulimb==0 then
vlimb already gives the common zeros. */
if (ulimb != 0)
{
count_trailing_zeros (u_low_zero_bits, ulimb);
zero_bits = MIN (zero_bits, u_low_zero_bits);
}
ulimb = MPN_MOD_OR_MODEXACT_1_ODD (up, size, vlimb);
if (ulimb == 0)
return vlimb << zero_bits;
/* Note that if ulimb == GMP_LIMB_HIGHBIT, c+1 is an invalid shift
count. */
count_trailing_zeros (c, ulimb);
ulimb = (ulimb >> 1) >> c;
}
else
{
/* size==1, so up[0]!=0 */
count_trailing_zeros (u_low_zero_bits, ulimb);
ulimb >>= u_low_zero_bits;
zero_bits = MIN (zero_bits, u_low_zero_bits);
/* make u bigger */
if (vlimb > ulimb)
MP_LIMB_T_SWAP (ulimb, vlimb);
/* if u is much bigger than v, reduce using a division rather than
chipping away at it bit-by-bit */
if ((ulimb >> 16) > vlimb)
{
ulimb %= vlimb;
if (ulimb == 0)
return vlimb << zero_bits;
count_trailing_zeros (c, ulimb);
ulimb >>= (c + 1);
{
else
ulimb >>= 1;
}
ASSERT (vlimb & 1);
/* Represent the odd numbers ulimb and vlimb without the redundant
least significant one bit. This reduction in size by one bit
ensures that the high bit of t, below, is set if and only if
vlimb > ulimb. And in addition, t != GMP_LIMB_HIGHBIT. */
vlimb >>= 1;
while (ulimb != vlimb)
{
...
Ĝis,
m
--
http://bodrato.it/
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Likely GMP bug
Ciao, Il Sab, 26 Maggio 2018 11:01 pm, Niels Möller ha scritto: > Is it possible to construct some examples with v a multiple of 641, and > input U such that ulimb = 2^31 after reduction? It was hard, but we got it: https://gmplib.org/repo/gmp/rev/1f8a8fefb5c2 The bug is triggered not only for 32-bit limbs, but also for other sizes. On any machine, if the undefined behaviour is not the one we hope, ./configure --disable-assembly && make make check TESTS= && tests/mpz/t-gcd_ui should fail. It does, with ABI=64 on shell. Of course I also healed the bug, to avoid too many red lines in the next "GMP testing status": https://gmplib.org/repo/gmp/rev/e4849ae7c974 . This is just a workaround, waiting for a code reorganisation by someone who knows better than me the various algorithm alternatives. Ĝis, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions
Ciao, Il Mer, 27 Dicembre 2017 6:10 pm, Marc Glisse ha scritto: > On Wed, 27 Dec 2017, Niels Möller wrote: >> And below, a patch to delete all mention of COUNT_LEADING_ZEROS_0, >> except for tune/many.pl, which I'm not familiar with. What do you think? > It seems a bit sad to drop this information, in case we want to use it in > the future, or if we want to share the file longlong.h with other > projects. I fully agree. > As far as I understand, the issue was an inconsistency between using gcc's > __builtin_clz (instead of some intrinsic or inline asm for the CLZ > instruction) and still defining the macro COUNT_LEADING_ZEROS_0 to 32. I > am not sure that warrants removing all COUNT_LEADING_ZEROS_0 everywhere. I understood the issue as you describe, and again I fully agree. Ĝis, m -- http://bodrato.it/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Asserts considered harmful (or GMP spills its sensitive information)
Ciao, Il Lun, 31 Dicembre 2018 7:03 pm, Jeffrey Walton ha scritto: [...skipping opinions...] > Here's a small example of triggering an assert using the Nettle > library. This absolutely is NOT a "small example", it requires to build two entire libraries! Anyway we analysed it, see below. > ARM A-32 does not work at the moment due to GMP build errors. Can we suggest you to read the GMP manual on how to build the library? GMP works fine on many ARM configurations we test and there are lots of projects out there (eg. many GNU/Linux distributions) that builds GMP for different ARM processors. > In the case below Nettle is using benign data and not maliciously > crafted data. I'm sorry, but your analysis was incorrect. I agree, Nettle is not using "maliciously crafted data", but I do not agree when you say that it "is using benign data". With your build options, Nettle calls the GMP function mpn_sec_powm with an invalid parameter: ebn = 0. Because of an error in the Nettle library you built, GMP receives "non benign data". To avoid further memory corruptions, GMP aborts. Thanks to this behaviour of GMP, you was able to catch the incorrect built of the library using it. ;-) Using mpn_sec_powm with an exponent of zero bits is obviously a nonsense, and in general the documentation of GMP clearly says that arguments of size zero are not supported. On GMP side, we can only specify even more explicitly in the documentation of that function the need for non-zero sized arguments. Ĝis, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Asserts considered harmful (or GMP spills its sensitive information)
Ciao, I'm not sending to oss-security... They does not seem to be interested. Il Gio, 3 Gennaio 2019 9:42 pm, Jeffrey Walton ha scritto: > On Thu, Jan 3, 2019 at 2:55 PM Marco Bodrato > wrote: >> This absolutely is NOT a "small example", it requires to build two >> entire libraries! > Well, if you can let us know how to reduce it further then we would be > delighted to hear it. I did, and I sent my analysis elsewhere. Unfortunately, the topic here is not "delighting users" :-D It is GMP bugs! And since your not "small" example does not show a GMP bug (a behaviour of the library in contrast with the one expected reading documentation), it would be off topic here. > I thought it did a good job because it did not muck with your system, You fired a bug for the wrong library... The job could be done better, don't you agree? :-D >> Can we suggest you to read the GMP manual on how to build the library? >> GMP works fine on many ARM configurations we test and there are lots of > Here's what I witness on a BananaPi and a couple of other boards. Can [...] > bananapi:~$ ./test-gmp.sh What's "./test-gmp.sh"? It is not a script we provide. If that script does not work, please report the failure to the author of that script. :-) I'd suggest: $ ./configure && make && make check Then please read https://gmplib.org/manual/Installing-GMP.html if you need more options. >> On GMP side, we can only specify even more explicitly in the >> documentation of that function the need for non-zero sized arguments. > Returning a failure from mpn_sec_powm would be a most welcomed > improvement. Functions in the mpn_ layer are low-level functions. If a developer decide to use those functions, she/he have the responsibility to correctly use them. Otherwise, the developers can decide to use the mpz_ layer or even more complex wrappers. Wish-lists of "welcomed improvements" is off topic on this list. On GMP side, the bug report is closed. Ĝis, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: ISO C forbids an empty translation unit again
Ciao, Il Lun, 2 Settembre 2019 11:48 pm, Dennis Clarke ha scritto: > This one pops up now and again if I go with LLVM/Clang on FreeBSD and > with really strict CFLAGS. So in a few files I had to drop in a silly > typedef. Adding silly lines in the code is not a priority for this project :-D By the way, a patch was added to the main repository: https://gmplib.org/repo/gmp/rev/04bc88ce93f9 Ĝis, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: ISO C forbids an empty translation unit again
Ciao,
Il Lun, 2 Settembre 2019 11:48 pm, Dennis Clarke ha scritto:
> t-get_str.c +69:30: error: format specifies type 'void *' but the
> argument has type 'const char *' [-Werror,-Wformat-pedantic]
>printf (" want %p\n", want);
>~~ ^~~~
>%s
> I know that is silly pedantic so I tossed in a (void *) cast and life
> goes onwards.
Silly, you are right. But serendipity spots a true oversight :-)
The line is inside the branch
if (str != ret)
So, the correct line is
printf (" want %p\n", str);
or, to be pedantic,
printf (" want %p\n", (void *) str);
Corrected this too:
https://gmplib.org/repo/gmp/rev/6137ad9f35b7
Ĝis,
m
--
http://bodrato.it/papers/
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang
Ciao, Il Ven, 8 Novembre 2019 4:59 pm, Niels Möller ha scritto: > Hans Åberg writes: > >> How about memory allocations? — There is info here, suggesting >> uninitialized memory access in the test suite: Our priority is to avoid bugs in the library. So that we usually pay more attention to the library code than to the code "in the test suite". ;-D > That issue was fixed by Marco a month and a half ago, see > https://gmplib.org/repo/gmp/rev/0688aef1f7e3. There probably were some > mention of the problem on gmp lists at the time, Of course: https://gmplib.org/list-archives/gmp-bugs/2019-September/004625.html > Seems unrelated to the stack alignment issue, though. Completely unrelated. Ĝis, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Compiling for ARMv8-A Using GCC 7.2.0 - Assertion error in gen-fac
Ciao, Il Ven, 6 Dicembre 2019 3:55 pm, Torbjörn Granlund ha scritto: > ni...@lysator.liu.se (Niels Möller) writes: > > > From my understanding this might be a difference in how GCC 7.2.0 > > handles unsigned longs vs GCC 4.8.5. > > Can you file a gcc bug? These constants are defined as > The first thing to try might be gcc 7.4, which was the final gcc 7 > release. There is also a 7.5 version, released Nov 14, 2019: https://gcc.gnu.org/gcc-7/ Ĝis, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: efficiency bug in mpz_powm_ui?
Ciao, Il 2020-02-29 11:54 paul zimmermann ha scritto: it seems that mpz_powm_ui is highly inefficient when BASE^EXP has about the same size as MOD, in which case it could first compute BASE^EXP exactly, then perform only one reduction: You are right, mpz_powm_ui does not implement an algorithm that is optimal for every possible use-case. But I'd not consider this a bug :-) mpz_ui_pow_ui (x, 2, e); mpz_mod (r1, x, y); I'm not sure that mpz_ui_pow_ui (x, 2, e) is the more efficient way to obtain a value x with only the bit e set to 1 :-) But of course, in this context, the following _mod dominates asymptotically. mpz_set_ui (x, 2); mpz_powm_ui (r2, x, e, y); Thanks to a recent change, this function should be faster now, when base is 2: https://gmplib.org/repo/gmp/rev/63e53ddfd210 Even if there is not jet any special code for the special case "BASE^EXP has about the same size as MOD". Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: assertion failure in snprntffuns.c:79 for i686-w64-mingw32
Ciao,
Il Ven, 10 Gennaio 2020 5:04 pm, Vincent Lefevre ha scritto:
> On 2020-01-10 16:27:31 +0100, Marco Bodrato wrote:
>> Can you please try with the development version?
> I get the following error:
> gmp_vsnprintf return value wrong
... because there was an error in the process of cross-compilation...
> Is there a way to tell GMP's configure that vsnprintf is missing,
> so that HAVE_VSNPRINTF is not defined?
Configure should check for it, but checking is not possible for
cross-compilations. Should we add an option for this case?
It would be nice if the autotools give support for an optional "emulation
environment", for a better configuration and an easier testing process...
> BTW, I still notice in printf/vasprintf.c:
>
> ret = vsnprintf (d->buf + d->size, space, fmt, ap);
> if (ret == -1)
> {
> ASSERT (strlen (d->buf + d->size) == space-1);
> ret = space-1;
> }
I'll look into that.
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Upstream patch to remove abort() that occur during memory overflow
Ciao,
Il 2020-09-03 19:22 ni...@lysator.liu.se ha scritto:
Mustafa Mohamad writes:
Currently GMP aborts which sends SIGBART and forcibly aborts Julia or
any linked program. With the above patch, GMP will instead throw a
__GMP_ALLOC_OVERFLOW_FUNC
Instead of forcibly aborting
Hi, I understand aborting may be undesirable, but can you provide a bit
more context. How do you handle the callback on overflow? If you
longjmp
out, how do you arrange so that your mpz variables are in a consistent
state?
I believe that a "safe" mpz type, is anyway difficult to obtain. We may
say that if the result is outside of the range supported by mpz, the
behavior is undefined.
Try the following code on a Linux or BSD system.
int
main (int argc, char *argv[])
{
unsigned long b, e;
mpz_t p;
mpz_init (p);
b = 1;
b <<= 24;
e = ~0UL / 24 + 1;
mpz_ui_pow_ui (p, b, e);
gmp_printf ("%lu ^ %lu = %Zd", b, e, p);
mpz_clear (p);
return 0;
}
With ABI=64 I get:
16777216 ^ 768614336404564651 = 256
With ABI=32 I get:
16777216 ^ 178956971 = 256
Not a signal, nor an abort, simply an incorrect result :-)
Anyway this patch might be a way to give a little bit more control to
the programs using the library...
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: GMP bug (?) - unable to build for ARM64 with assembly enabled
Il 2020-10-14 21:28 t...@gmplib.org ha scritto: Andreas Buff writes: Latest snapshot is from may though There is one made every day. Look for a filename starting with gmp-6.2.0-202010... Then please follow up here! Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: gmp 6.2.0 documentation bug
Ciao,
Il 2020-09-29 16:09 TonyMcC ha scritto:
I think there is a word (a function name?) missing from the
documentation for gmp 6.2.0. In gmp.texi, at line 2541 it reads:
"it's probably best to call to get a starting point and iterate from
there."
Should there be a function name after "call"?
The complete sentence is:
Functions like @code{mpz_fac_ui}, @code{mpz_fib_ui} and
@code{mpz_bin_uiui}
are designed for calculating isolated values. If a range of values is
wanted
it's probably best to call to get a starting point and iterate from
there.
Maybe we can simply remove "to call".
The documentation of mpz_fib_ui correctly suggests the function to call:
mpz_fib2_ui.
Speaking about mpz_fac_ui and mpz_bin_uiui, it shouldn't be necessary to
suggest how to get the starting point.
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: overflow in mpz type with a simple mpz_add_ui
Ciao,
Il 2020-09-21 18:16 t...@gmplib.org ha scritto:
overflow. The overflow detection flags some false positives, which is
by design.
But maybe we could avoid the false positive at least for the following
example:
#include
#include "gmp.h"
int main (void)
{
mpz_t z;
mpz_init (z);
mpz_setbit (z, 0xffdf);
printf ("OK\n");
mpz_sub_ui (z, z, 123);
printf ("OK\n");
return 0;
}
We can avoid it simply moving the REALLOC after the branch.
This may save some allocations in many cases.
The proposed patch follows:
diff -r b851f9336a86 mpz/aors_ui.h
--- a/mpz/aors_ui.h Thu Sep 17 12:00:00 2020 +0200
+++ b/mpz/aors_ui.h Mon Sep 21 18:36:33 2020 +0200
@@ -86,21 +86,26 @@
abs_usize = ABS (usize);
- /* If not space for W (and possible carry), increase space. */
- wp = MPZ_REALLOC (w, abs_usize + 1);
-
- /* These must be after realloc (U may be the same as W). */
- up = PTR (u);
-
if (usize VARIATION_CMP 0)
{
mp_limb_t cy;
+
+ /* If not space for W (and possible carry), increase space. */
+ wp = MPZ_REALLOC (w, abs_usize + 1);
+ /* These must be after realloc (U may be the same as W). */
+ up = PTR (u);
+
cy = mpn_add_1 (wp, up, abs_usize, (mp_limb_t) vval);
wp[abs_usize] = cy;
wsize = VARIATION_NEG (abs_usize + cy);
}
else
{
+ /* If not space for W, increase space. */
+ wp = MPZ_REALLOC (w, abs_usize);
+ /* These must be after realloc (U may be the same as W). */
+ up = PTR (u);
+
/* The signs are different. Need exact comparison to determine
which operand to subtract from which. */
if (abs_usize == 1 && up[0] < vval)
Ĝis,
m
--
http://bodrato.it/papers/
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mini-gmp.h FILE test update from gmp.h
Ciao, Il 2020-09-16 14:35 Vincent Lefevre ha scritto: In mini-gmp/mini-gmp.h, concerning FILE tests: /* This long list taken from gmp.h. */ but the list in GMP 6.2.0 and the current repository is not up-to-date. I re-synced the lists, thanks! Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Make check fails on samsung S8 (2)
Ciao Luc, Il Gio, 3 Dicembre 2020 5:03 pm, Luc Sanselme ha scritto: > I ran make check on termux on my phone and It's OK now. Great, thank you! Then, also the new release GMP-6.2.1 should be OK. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 6.2.0 build failure on x86_64 Skylake PC - FIX
Il 2020-06-08 21:52 Marc Glisse ha scritto: [handle *-*-msys exactly the same as *-*-mingw* in configure.ac] configfsf.guess does mention a triple *-pc-msys, so I guess it makes sense to handle it (or replace it with something we already handle). I don't really know in what ways it differs from mingw, probably not that much as far as GMP is concerned. To build and test a static library, this seems enough. A test with ./configure --enable-cxx&& check& check-mini-gmp worked smoothly. I notice in a generated file: aclocal.m4: *-*-mingw* ) # actually msys Should automake also be taught about the msys triple? You are right. If I understand it correctly, automake does not know how to build shared libraries under *-pc-msys. So that ./configure --enable-shared --disable-static outputs checking if libtool supports shared libraries... no checking whether to build shared libraries... no and then make check fails. But msys and mingw are somehow different wrt shared libraries... ./configure --build=$(./config.guess|sed 's/-msys/-mingw64/') --enable-shared builds a library that passes "make check-mini-gmp" but the Makefiles are not able to build the tests for "make check"... It would be nice to know if there are other libraries using the autotools that build a shared dll under msys... Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: with strict C99 the tests/mpz/convert.c needs #include
Ciao, Il 2020-11-08 00:45 Dennis Clarke ha scritto: However the tests blow up due to : convert.c:143:11: error: implicit declaration of function 'strcasecmp' is invalid in C99 That file will be changed in the next release. Please look if the applied patch fits your needs. https://gmplib.org/repo/gmp-6.2/rev/ad3ca09cfa38 Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Make check fails on samsung S8 (2)
Ciao Marc, Il 2020-08-22 19:39 Marc Glisse ha scritto: Ah, on your OS nl_langinfo is defined inline as a static function in langinfo.h, so the hack used in the test of redefining the function cannot work. I guess we are supposed to add some configure check that nl_langinfo can be redefined... although for just one platform we could add a simple #if like we already do for mingw, so the test is skipped. Are you suggesting something like the following? diff -r 3328dc92960a tests/misc/t-locale.c --- a/tests/misc/t-locale.c Sun Oct 25 22:14:38 2020 +0100 +++ b/tests/misc/t-locale.c Thu Oct 29 02:43:25 2020 +0100 @@ -57,7 +57,7 @@ #endif /* Replace the libc nl_langinfo with one we can manipulate. */ -#if HAVE_NL_LANGINFO +#if HAVE_NL_LANGINFO && ! defined __TERMUX__ char * nl_langinfo (nl_item n) #if defined __cplusplus && defined __GLIBC__ Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: COFF_TYPE on x86_64
Ciao Jeremy, Il 2020-10-02 20:45 Jeremy Drake ha scritto: Looking at the ld code, it only generated the thunk in the import library if it thought the symbol was a function. Checking the output of gcc -S showed that it added ".def func; .scl 2; .type 32; .endef" to functions, and inserting that into the assembly functions caused ld to generate the thunks, which solved the crash. When I started to investigate how to integrate generating that in the GMP build system, I came across existing code that did exactly that, but only on 32-bit x86 not x86_64. The patch I sent copied the necessary parts of that to the x86_64 path. Can you test if the latest available snapshot is working in your environment? You can download it at: https://gmplib.org/download/snapshot/gmp-6.2/gmp-6.2.0-20201101220635.tar.zst Do you know if this might be needed also for mingw running on ARM cpus? Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Make check fails on samsung S8 (2)
Ciao Luc, Il 2020-10-29 08:39 Marc Glisse ha scritto: I think so, yes. Maybe Luc can confirm if that works? Could you try if the latest available snapshot is working in your environment? You can download it at: https://gmplib.org/download/snapshot/gmp-6.2/gmp-6.2.0-20201101220635.tar.zst Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 6.2.0 build failure on x86_64 Skylake PC - FIX
Ciao Ralph, Il 2020-05-30 21:12 tsurzin ha scritto: The PC is running Msys2 under Windows 10 and without change GMP failed to build. Can you test if the latest available snapshot is working in your environment? You can download it at: https://gmplib.org/download/snapshot/gmp-6.2/gmp-6.2.0-20201101220635.tar.zst With very limited understanding of the Gnu-tools I was unable to make a shared (.dll) version although Msys2 provides a generic one. I'm not sure it will work (I don't have Windows, and it seems hard to make Msys2 work under wine), but you can try what happen with: configure --enable-shared --disable-static Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: possible miscompilation on macOS Catalina 10.15.6
Ciao, Il 2020-10-29 20:02 Niels Möller ha scritto: Paul Koning writes: There is another possibility: GMP might be doing something undefined, where previous compilers did "what we want" while some recent new ones do something different. So you have to forgive GMP developers of not being thrilled at spending our spare time investigating, in particular if it's a proprietary compiler with known bugs in recent history. In particular because we are speaking about a "report" that does not tell us which compiler. We can only guess :-) Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: GMP Problem with % under C++
Ciao, Il 2020-11-05 22:27 Niels Möller ha scritto: I think this is the same result you get with a plain (64-bit) long. The / and % operators in C++ produce a quotient rounded towards 0, so (f(1) - b) / DECKSIZE == 0, and the corresponding remainder is negative. I'm not that familiar with perl, but I guess it uses the mathematically more sane definition of always rounding the quotient towards -infinity, Every language has its own definition :-) https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: A message bug. At least Version 6.2.0
Ciao,
Il 2020-12-22 15:55 Guillermo Monguia ha scritto:
In mini-gmp.c function mpz_export, when calling gmp_die("mpz_import:
...") instead of gmp_die("mpz_export: ...")
Corrected, thanks!
https://gmplib.org/repo/gmp/rev/6fed56750f6f
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Upstream patch to remove abort() that occur during memory overflow
Il 2020-09-13 11:38 t...@gmplib.org ha scritto:
Marco Bodrato writes:
With ABI=64 I get:
16777216 ^ 768614336404564651 = 256
With ABI=32 I get:
16777216 ^ 178956971 = 256
Not a signal, nor an abort, simply an incorrect result :-)
That's undesirable.
I thought we cought overflows also in this difficult a^b case by
(indirectly means of allocation errors).
Yet another...
$ cat provo.c
#include
#include "gmp.h"
int
main ()
{
unsigned long b, e;
mpz_t p;
mpz_t bz;
mpz_init (p);
mpz_init (bz);
b = 24 * GMP_NUMB_BITS;
mpz_setbit (bz, b);
e = ~0UL / 24 + 1;
mpz_pow_ui (p, bz, e);
gmp_printf ("(2 ^ %lu) ^ %lu = %Zd\n", b, e, p);
mpz_clear (bz);
mpz_clear (p);
}
$ gcc provo.c -lgmp -o provo&& ./provo
(2 ^ 1536) ^ 768614336404564651 =
13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084096
And here is a possible patch (for the 6.2 branch):
$ hg diff mpz
diff -r e1fd9db13b47 mpz/n_pow_ui.c
--- a/mpz/n_pow_ui.cTue Dec 22 23:49:51 2020 +0100
+++ b/mpz/n_pow_ui.cSat Jun 12 15:24:36 2021 +0200
@@ -206,11 +206,33 @@
/* Strip low zero limbs from b. */
rtwos_limbs = 0;
+#if 1
for (blimb = *bp; blimb == 0; blimb = *++bp)
{
rtwos_limbs += e;
+ if (UNLIKELY (rtwos_limbs < e))
+ {
+ fprintf (stderr, "gmp: overflow in mpz type\n");
+ abort ();
+ }
bsize--; ASSERT (bsize >= 1);
}
+#else
+ blimb = *bp;
+ if (blimb == 0)
+{
+ do
+ ++rtwos_limbs;
+ while ((blimb = *++bp) == 0);
+ bsize -= rtwos_limbs; ASSERT (bsize >= 1);
+ umul_ppmm (ovfl, rtwos_limbs, e, rtwos_limbs);
+ if (ovfl)
+ {
+ fprintf (stderr, "gmp: overflow in mpz type\n");
+ abort ();
+ }
+}
+#endif
TRACE (printf ("trailing zero rtwos_limbs=%ld\n", rtwos_limbs));
/* Strip low zero bits from b. */
As you can see, I tried two different patches. One adds a (well
predicted?) branch in the (on average O(1)) loop. The other uses a
multiplication.
But we should probably consider to add a piece of code, at the beginning
of the function, estimating the total size of the result, to avoid so
many spurious checks...
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
t-scan from GMP-4.3.2 [was: t-lucnum_ui segfaults]
Ciao,
Il 2021-02-28 20:41 Paul Dufresne ha scritto:
PASS: t-lucnum_ui
t-lucnum_ui does not segfault, it passes.
/bin/bash : ligne 4 : 116921 Erreur de segmentation (core dumped)
${dir}$tst
FAIL: t-scan
t-scan triggers the error.
make[2] : on quitte le répertoire
« /home/paul/gpc2/gcc-4.6.4/gmp-4.3.2/tests »
If you really want to use that 10 years old release, you may try this
9.5 years old patch (to the test, not to the library):
https://gmplib.org/repo/gmp/rev/966737bd91ed
# HG changeset patch
# User Torbjorn Granlund
# Date 1318259187 -7200
# Node ID 966737bd91ed4cd158ca9730167f70db47442fc1
# Parent 27913f466a23776215bd9341866e10a50cf61c01
(check_ref): Fix loop end bound.
diff -r 27913f466a23 -r 966737bd91ed tests/mpz/t-scan.c
--- a/tests/mpz/t-scan.cMon Oct 10 12:06:39 2011 +0200
+++ b/tests/mpz/t-scan.cMon Oct 10 17:06:27 2011 +0200
@@ -79,7 +79,7 @@
for (isize = 0; isize <= size; isize++)
{
- for (oindex = 0; oindex <= numberof (offset);
oindex++)
+ for (oindex = 0; oindex < numberof (offset);
oindex++)
{
o = offset[oindex];
if ((int) isize*GMP_NUMB_BITS < -o)
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Rounding error
Ciao, Il 2021-08-25 05:54 Frank Heckenbach ha scritto: mpf_get_str seems to round incorrectly sometimes. In this test program, the digits around 809 are "...244594553...", so it should round to "...244595", but it outputs "...244594". Here, your report says that you expected a "rounded" result, but you get a truncated one. Il 2021-08-27 07:36 Frank Heckenbach ha scritto: Actually, what I wanted is truncation, not rounding. But AFAICS Here, you say that you actually want truncation. there is no string conversion function with truncation (correct?), From the manual I read a general claim about functions using mpf: "Final results are always truncated to the destination variable’s precision." See https://gmplib.org/manual-6.2.1/Floating_002dpoint-Functions . Do you have an example of the function not working as documented? Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Segmentation fault with mpz_inp_raw on gcc45
Ciao,
Il 2021-09-16 23:27 Torbjörn Granlund ha scritto:
Going from byte count to bit count to limb count is non-trivial without
risking overflow, even if the end result will typically be smaller than
the incoming byte count (assuming we're not using gmp/asl.h with tiny
Yes, but, should we really consider it only a temporary overflow?
Does GMP support mpz numbers with a bit-lenght that overflows?
Perhaps, instead of the change below which triggers an errir in the
allocation statement later in the program flow, we could make an
explicit check of the byte count vs the max supported sizes, and
generate the overflow error locally.
I agree!
We do not define BITCNT_MAX anywhere, do we?
Then, maybe something like the following could do?
--- a/mpz/inp_raw.c Tue Sep 14 19:05:51 2021 +0200
+++ b/mpz/inp_raw.c Fri Sep 17 18:49:14 2021 +0200
@@ -87,9 +87,11 @@
csize = size - 0x8000u - 0x8000u;
abs_csize = ABS (csize);
+ if (abs_csize > ~(mp_bitcnt_t) 0 / 8)
+return 0; /* Bit size overflows */
/* round up to a multiple of limbs */
- abs_xsize = BITS_TO_LIMBS (abs_csize*8);
+ abs_xsize = BITS_TO_LIMBS ((mp_bitcnt_t) abs_csize * 8);
if (abs_xsize != 0)
{
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: GMP 6.2.1 Aborting when running tuneup program in one.cold()
Ciao Simon, Il 2021-10-20 16:09 Simon Sobisch ha scritto: Questions: * Should I care running tuneup at all? The application does some heavy computations with it in the range +-9 (mostly multiply and divide [often by 10] and 9 fits in 63 bits, correct? For that range, on a 64-bits CPU, the native integer types should be enough. The manual, with "extremely large numbers", means much larger bit-sizes. You probably don't need tuneup at all. Moreover, the sources of GMP already contain pre-tuned parameters for many platforms. They are automatically used by the typical ./condigure&& check building process. So that tuning is, in most of the cases, superfluous. * As the output of the tuneup utility is different each time and the docs at https://gmplib.org/manual/Performance-optimization are more spare than for other parts: Should I run it multiple times and then use the average? Some thresholds may have a large range of tolerance, some doesn't. In any case, a collection of parameters needs to be coherent. So my answer is: use the results from a single run. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Segmentation fault with mpz_inp_raw on gcc45
Ciao, Il 2021-09-18 10:07 Torbjörn Granlund ha scritto: I suppose that, in this case, as my fix has problems with nails, this Your fix also aborts, instead of returning 0. might be a better patch. An UNLIKELY(...) might have a place here, though. I commited the patch, adding UNLIKELY to all error branches. I took a very quick lock at other uses of BITS_TO_LIMBS and think we might have one more place where scalar overflow might occur: mpz/import.c. There might be more places. I also changed mpz/import.c but I did not correct this possible overflow. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Fwd: math/gmp FreeBSD 12.2 Ports build failure on sparc64
Il 2021-11-05 15:12 Torbjörn Granlund ha scritto: Alex Dupre writes: tmp-gcd_11.s: Assembler messages: tmp-gcd_11.s:210: Error: Illegal operands tmp-gcd_11.s:211: Error: Illegal operands tmp-gcd_11.s:212: Error: Illegal operands Above, we saw line numbers... root@freebsd12:/usr/ports/math/gmp/work/gmp-6.2.1/mpn # diff tmp-gcd_11.s.noPIC tmp-gcd_11.s 206,209c206,212 < sethi %h44(ctz_table), %o5 < or %o5, %m44(ctz_table), %o5 < sllx%o5, 12, %o5 < or %o5, %l44(ctz_table), %o5 --- 206> rd %pc, %o5 207> sethi %hi(_GLOBAL_OFFSET_TABLE_+4), %g4 208> add %g4, %lo(_GLOBAL_OFFSET_TABLE_+8), %g4 209> add %o5, %g4, %g4 210> sethi %gdop_hix22(ctz_table), %o5 211> xor %o5, %gdop_lox10(ctz_table), %o5 212> ldx [%g4 + %o5], %o5, %gdop(ctz_table) Above I added line numbers (because diff says "c206,212") Which lines cause these syntax errors? It seems they are the lines containing the various %gdop*(ctz_table). What syntax for pic data references is accepted by the assembler on FreeBSD? Unfortunately, I don't know. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
Ciao,
Il 2022-03-13 00:06 Torbjörn Granlund ha scritto:
There is some sort of sick competition between certain compilers to
have
the most warnings for valid C. I don't think we should play their
game,
Incidantally, arithmetic on unsigned types is well-defined. Unlike
that
of signed types.
int
foo (int a, int b)
{
return a + b - 1;
}
$ clank foo.c
warning: signed addition might overflow and yield undefined results
warning: signed subtraction might overflow and yield undefined results
:-D
You are right!
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: unused macro MPN_PTR_SWAP in mini-gmp.c
Ciao Paul,
Il 2022-03-09 02:56 Paul Eggert ha scritto:
In libgmp 6.2.1, mini-gmp.c defines a macro without using it, causing
Thanks for spotting this!
Proposed patch attached.
There is also a different possible way to heal the problem: using it :-D
diff -r a44f487c8d20 mini-gmp/mini-gmp.c
--- a/mini-gmp/mini-gmp.c Fri Mar 11 21:13:20 2022 +0100
+++ b/mini-gmp/mini-gmp.c Thu Mar 17 19:15:51 2022 +0100
@@ -1938,8 +1938,7 @@
mpz_swap (mpz_t u, mpz_t v)
{
MP_SIZE_T_SWAP (u->_mp_size, v->_mp_size);
- MP_SIZE_T_SWAP (u->_mp_alloc, v->_mp_alloc);
- MP_PTR_SWAP (u->_mp_d, v->_mp_d);
+ MPN_PTR_SWAP (u->_mp_d, u->_mp_alloc, v->_mp_d, v->_mp_alloc);
}
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
Ciao, Il 2022-02-03 08:50 ni...@lysator.liu.se ha scritto: George Woltman writes: Minor issue #2 (I should have reported this years ago, sorry): In gmp.h, these lines: mpn_neg (mp_ptr __gmp_rp, mp_srcptr __gmp_up, mp_size_t __gmp_n) [...] *__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK; The last line generates this compiler warning: warning C4146: unary minus operator applied to unsigned type, result still I can only suggest that you disable or ignore that warning. Operations on unsigned types is well defined by the C standard, and gmp depends on practically all possible corner cases to work according to spec. Maybe we can avoid this in the file gmp.h; it is used during the compiling process of any project using the library... What about the following? --- a/gmp-h.in Fri Mar 11 21:13:20 2022 +0100 +++ b/gmp-h.in Sat Mar 12 23:23:09 2022 +0100 @@ -2234,7 +2234,7 @@ ++__gmp_up; ++__gmp_rp; } - *__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK; + *__gmp_rp = (1 + ~ *__gmp_up) & GMP_NUMB_MASK; if (--__gmp_n) /* Higher limbs get complemented. */ mpn_com (++__gmp_rp, ++__gmp_up, __gmp_n); For an optimising compiler, there should not be any difference. "+ ~ *" is a funny sequence of operators :-) Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: unused macro MPN_PTR_SWAP in mini-gmp.c
Ciao Paul, Il 2022-03-18 00:37 Paul Eggert ha scritto: On 3/17/22 11:32, Marco Bodrato wrote: - MP_SIZE_T_SWAP (u->_mp_alloc, v->_mp_alloc); - MP_PTR_SWAP (u->_mp_d, v->_mp_d); + MPN_PTR_SWAP (u->_mp_d, u->_mp_alloc, v->_mp_d, v->_mp_alloc); Thank you, this looks good. Slightly changed and pushed: https://gmplib.org/repo/gmp/rev/2a0dd4a874f1 Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Errors making GMP621 on SCO Openserver 6.
Ciao,
Il 2022-02-02 23:40 Jack Tearle ha scritto:
I hope the only problem is my doing something wrong.
Maybe.
Of course we can not know what you are doing.
We usually suggest to read the manual page
https://gmplib.org/manual/Reporting-Bugs before reporting problems.
I see the following:
==> /tmp/configfsf.log <==
i686-unknown-sysv5SCO_SV6.0.0
==> /tmp/config.guess.log <==
./config.guess: syntax error at line 284: `(' unexpected
Did config.guess really stopped at line 284?
If I read correctly, line 284 should run if the output from configfsf
begins with "mips-".
Too hard to guess.
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Errors making GMP621 on SCO Openserver 6.
Ciao, Il 2022-02-03 23:08 Jack Tearle ha scritto: I deleted /bin/sh, and linked /bin/bash to /bin/sh, and then re-ran the entire installation in a new directory. The results are not quite the same. The .libs directory is now created, but it is empty and assert.o and the rest of the programs listed below still have the Oct 11 2021 date and only exist in the root directory (/tmp/gmp621). I'd suggest to start from a clean source directory. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Errors making GMP621 on SCO Openserver 6.
Ciao, Il 2022-02-04 15:57 Jack Tearle ha scritto: Just to be clear, I purged the directory (rm -r *) and extracted (tar xvf ../gmp621.tar) the published tar file for each run. You mean one of the gmp-6.2.1.tar.* files from https://ftp.gnu.org/gnu/gmp/ or https://gmplib.org/download/gmp/ , great! Il 2022-02-03 23:08 Jack Tearle ha scritto: but it is empty and assert.o and the rest of the programs listed below still have the Oct 11 2021 date and only exist in the root directory Sorry, I do not understand what do you mean with "assert.o [...] still have the Oct 11 2021 date". The published tar files contain a file named assert.c, but no files named assert.o. Moreover the tar files where generated in November 2020. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mpz_gcd_ui(NULL, ...) with small limbs
Ciao, Il Sab, 22 Gennaio 2022 11:40 pm, Marc Glisse ha scritto: > mpz_gcd_ui also contains special code for the case > where op2 (an unsigned long) does not fit in a limb. And that code calls > mpz_gcd without checking if the first argument is NULL. That probably does > not affect any platform, since nails are not supported and I don't see Keeping unused code error-free is not easy, because it is not tested... But I think we should always correct it, when we run into a possible issue. The alternative, IMO, is to remove the unused_and_incorrect code. Yet another 2-limbs array, and dummy allocation are needed, I believe. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mpz_gcd_ui(NULL, ...) with small limbs
Ciao Marc,
Il 2022-02-08 10:05 Marc Glisse ha scritto:
Makes sense to me. I am just not sure if 3 is the right number and if
we are consistent about it. Shouldn't 2 be enough? Or is it to be safe
You are right. 2 should be enough.
I think that if a not realloc-able mpz is used as a target for a
function, it should contain at least one extra limb. But we are not
consistent about this.
If ones try
gmp$ grep MPZ_TMP_INIT -r mpz
many +1 are found...
But specifically for the gcd one can find
gmp$ grep MPZ_TMP_INIT -r mpq/aors.c
MPZ_TMP_INIT (gcd, MIN (op1_den_size, op2_den_size));
I don't think we need to set SIZ(lw) but it looks cleaner and can't be
very expensive.
I agree, not really needed, but it's probably better to always pass a
well defined mpz_t to functions.
diff -r ed0406cf3c70 mpz/gcd_ui.c
--- a/mpz/gcd_ui.c Wed Feb 02 19:16:36 2022 +0100
+++ b/mpz/gcd_ui.c Tue Feb 08 09:30:53 2022 +0100
@@ -41,7 +41,16 @@
if (v > GMP_NUMB_MAX)
{
mpz_t vz;
- mp_limb_t vlimbs[2];
+ mpz_t lw;
+ mp_limb_t vlimbs[2], wlimbs[3];
+
+ if (w == NULL)
+ {
+ PTR(lw) = wlimbs;
+ ALLOC(lw) = 3;
+ SIZ(lw) = 0;
+ w = lw;
+ }
vlimbs[0] = v & GMP_NUMB_MASK;
vlimbs[1] = v >> GMP_NUMB_BITS;
PTR(vz) = vlimbs;
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mpz_gcd_ui(NULL, ...) with small limbs
Ciao Marc,
Il 2022-01-22 23:40 Marc Glisse ha scritto:
the documentation for mpz_gcd_ui(rop, op1, op2) says "If rop is not
NULL, store the result there." and indeed the main code contains two
tests "if (w != NULL)". However, mpz_gcd_ui also contains special code
for the case where op2 (an unsigned long) does not fit in a limb. And
that code calls mpz_gcd without checking if the first argument is
NULL. That probably does not affect any platform, since nails are not
supported and I don't see anything defining __GMP_SHORT_LIMB.
What about the following (untested)?
diff -r ed0406cf3c70 mpz/gcd_ui.c
--- a/mpz/gcd_ui.c Wed Feb 02 19:16:36 2022 +0100
+++ b/mpz/gcd_ui.c Tue Feb 08 09:30:53 2022 +0100
@@ -41,7 +41,16 @@
if (v > GMP_NUMB_MAX)
{
mpz_t vz;
- mp_limb_t vlimbs[2];
+ mpz_t lw;
+ mp_limb_t vlimbs[2], wlimbs[3];
+
+ if (w == NULL)
+ {
+ PTR(lw) = wlimbs;
+ ALLOC(lw) = 3;
+ SIZ(lw) = 0;
+ w = lw;
+ }
vlimbs[0] = v & GMP_NUMB_MASK;
vlimbs[1] = v >> GMP_NUMB_BITS;
PTR(vz) = vlimbs;
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
Ciao, Il Gio, 3 Febbraio 2022 8:50 am, Niels Möller ha scritto: > George Woltman writes: >> I get this compiler warning calling mpz_tstbit: warning C4244: >> 'argument': >> conversion from 'uint64_t' to 'mp_bitcnt_t', possible loss of data >> Yes, I'm creating mpz values with more than 4 billion bits. > > That's kind-of difficult. I agree it would make sense to increase size > of mp_bitcnt_t (perhaps ptrdiff_t would be a reasonable and portable > definition?), but it's going to be an ABI break platforms where that's an > actual change of size. Torbjörn, should this be listed under the things > to fix once we decide to break ABI compatibility? On https://gmplib.org/devel/incompatibility we have the following line: Consider making mp_bitcnt_t a 64-bit integer also on 32-bit hosts. We should consider the windos64 case as well. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
Ciao, Il Gio, 3 Febbraio 2022 8:50 am, Niels Möller ha scritto: > George Woltman writes: >> I get this compiler warning calling mpz_tstbit: warning C4244: >> 'argument': >> conversion from 'uint64_t' to 'mp_bitcnt_t', possible loss of data >> Yes, I'm creating mpz values with more than 4 billion bits. > > That's kind-of difficult. I agree it would make sense to increase size > of mp_bitcnt_t (perhaps ptrdiff_t would be a reasonable and portable > definition?), but it's going to be an ABI break platforms where that's an > actual change of size. Torbjörn, should this be listed under the things > to fix once we decide to break ABI compatibility? On https://gmplib.org/devel/incompatibility we have the following line: Consider making mp_bitcnt_t a 64-bit integer also on 32-bit hosts. We should consider the windos64 case as well. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Can't install on Kali linux
Ciao, I agree with the message by Niels. But I add a comment. Il 2022-04-14 21:59 Adham Khalile Yousef ha scritto: My purpose of install gmp is to be able to"# include " in other C programs on my machine (i.e., same linux, I even tried to give If your purpose is simply to use the library, and you have problems compiling it from source, I'd suggest to install the pre-packaged one, that your linux distribution surely provides. Did you say Kali, and Kali is Debian-based? So something like "apt install libgmp-dev" should do... Ĝis, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Unsigned integer overflow in `toom_eval_pm2.c`
Ciao, 4 set 2023, 15:19 da vinc...@vinc17.net: > On 2023-09-04 09:52:23 +0200, marco.bodr...@tutanota.com wrote: > >> Should the value ~0 be written as ~0U to be correctly assigned to an >> unsigned? >> > > IMHO, this would be better as this would make the signedness of > the types more consistent > Ok, I changed all the neg = (v<0)? ~0:0; into neg = - (unsigned) (v<0): For x86-64, gcc generates exactly the same code: # m.c:2: return v<0?~0:0; movl %edi, %eax sarl $31, %eax # m.c:6: return -(unsigned)(v<0); movl %edi, %eax sarl $31, %eax All but one. Everything started with a question on the line: neg ^= ((k & 1) - 1); Well, now neg before this line contains 0 or 1, so that the line is now neg ^= 1 ^ k & 1; And it is transformed to a mask after that, Changes pushed here: https://gmplib.org/repo/gmp/rev/ef441e461f42 Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Unsigned integer overflow in `toom_eval_pm2.c`
Ciao,
3 set 2023, 22:16 da ni...@lysator.liu.se:
> Andrew Teylu writes:
>
> I see no good reason to involve any signed values here, though. Maybe
> the variable neg, and the return value, should be changed to mp_limb_t,
> or at least unsigned int?
>
Yes, unsigned is the best choice, it used to store a positive or
negative number, but now it actually is a mask: 0 or ~0.
I attach a possible patch.
>> I guess maybe a different question is: what is that code supposed to
>> do? Is the intent to `xor` with `0x` if the `k` is even and
>> `xor` with `0` if the `k` is odd (i.e., it either flips all the bits
>> in the even case or leaves them in the odd case)?
>>
>
> I think intention is to conditionally flip all the bits. And in
> addition, neg should always be either all ones or all zeros.
>
Correct.
Ĝis,
m
diff -r e3cc6f9e9753 gmp-impl.h
--- a/gmp-impl.h Sun Aug 27 20:47:01 2023 +0200
+++ b/gmp-impl.h Mon Sep 04 00:37:06 2023 +0200
@@ -1481,25 +1481,25 @@
__GMP_DECLSPEC void mpn_toom_interpolate_16pts (mp_ptr, mp_ptr, mp_ptr, mp_ptr, mp_ptr, mp_size_t, mp_size_t, int, mp_ptr);
#define mpn_toom_couple_handling __MPN(toom_couple_handling)
-__GMP_DECLSPEC void mpn_toom_couple_handling (mp_ptr, mp_size_t, mp_ptr, int, mp_size_t, int, int);
+__GMP_DECLSPEC void mpn_toom_couple_handling (mp_ptr, mp_size_t, mp_ptr, unsigned, mp_size_t, int, int);
#define mpn_toom_eval_dgr3_pm1 __MPN(toom_eval_dgr3_pm1)
-__GMP_DECLSPEC int mpn_toom_eval_dgr3_pm1 (mp_ptr, mp_ptr, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_dgr3_pm1 (mp_ptr, mp_ptr, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
#define mpn_toom_eval_dgr3_pm2 __MPN(toom_eval_dgr3_pm2)
-__GMP_DECLSPEC int mpn_toom_eval_dgr3_pm2 (mp_ptr, mp_ptr, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_dgr3_pm2 (mp_ptr, mp_ptr, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
#define mpn_toom_eval_pm1 __MPN(toom_eval_pm1)
-__GMP_DECLSPEC int mpn_toom_eval_pm1 (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_pm1 (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
#define mpn_toom_eval_pm2 __MPN(toom_eval_pm2)
-__GMP_DECLSPEC int mpn_toom_eval_pm2 (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_pm2 (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
#define mpn_toom_eval_pm2exp __MPN(toom_eval_pm2exp)
-__GMP_DECLSPEC int mpn_toom_eval_pm2exp (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, unsigned, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_pm2exp (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, unsigned, mp_ptr);
#define mpn_toom_eval_pm2rexp __MPN(toom_eval_pm2rexp)
-__GMP_DECLSPEC int mpn_toom_eval_pm2rexp (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, unsigned, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_pm2rexp (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, unsigned, mp_ptr);
#define mpn_toom22_mul __MPN(toom22_mul)
__GMP_DECLSPEC void mpn_toom22_mul (mp_ptr, mp_srcptr, mp_size_t, mp_srcptr, mp_size_t, mp_ptr);
diff -r e3cc6f9e9753 mpn/generic/toom54_mul.c
--- a/mpn/generic/toom54_mul.c Sun Aug 27 20:47:01 2023 +0200
+++ b/mpn/generic/toom54_mul.c Mon Sep 04 00:37:06 2023 +0200
@@ -61,7 +61,7 @@
mp_srcptr bp, mp_size_t bn, mp_ptr scratch)
{
mp_size_t n, s, t;
- int sign;
+ unsigned sign;
/* decomposition ***/
#define a4 (ap + 4 * n)
diff -r e3cc6f9e9753 mpn/generic/toom63_mul.c
--- a/mpn/generic/toom63_mul.c Sun Aug 27 20:47:01 2023 +0200
+++ b/mpn/generic/toom63_mul.c Mon Sep 04 00:37:06 2023 +0200
@@ -99,7 +99,7 @@
{
mp_size_t n, s, t;
mp_limb_t cy;
- int sign;
+ unsigned sign;
/* decomposition ***/
#define a5 (ap + 5 * n)
diff -r e3cc6f9e9753 mpn/generic/toom6h_mul.c
--- a/mpn/generic/toom6h_mul.c Sun Aug 27 20:47:01 2023 +0200
+++ b/mpn/generic/toom6h_mul.c Mon Sep 04 00:37:06 2023 +0200
@@ -109,7 +109,7 @@
{
mp_size_t n, s, t;
int p, q, half;
- int sign;
+ unsigned sign;
/* decomposition ***/
diff -r e3cc6f9e9753 mpn/generic/toom8h_mul.c
--- a/mpn/generic/toom8h_mul.c Sun Aug 27 20:47:01 2023 +0200
+++ b/mpn/generic/toom8h_mul.c Mon Sep 04 00:37:06 2023 +0200
@@ -119,7 +119,7 @@
{
mp_size_t n, s, t;
int p, q, half;
- int sign;
+ unsigned sign;
/* decomposition ***/
diff -r e3cc6f9e9753 mpn/generic/toom_couple_handling.c
--- a/mpn/generic/toom_couple_handling.c Sun Aug 27 20:47:01 2023 +0200
+++ b/mpn/generic/toom_couple_handling.c Mon Sep 04 00:37:06 2023 +0200
@@ -45,7 +45,7 @@
*/
void
mpn_toom_couple_handling (mp_ptr pp, mp_size_t n, mp_ptr np,
- int
Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c
Ciao, 31 ago 2023, 18:06 da vinc...@vinc17.net: > I don't think that this is sufficient for the test. > The code Brett mentioned is for MOD_1_1P_METHOD = 2. > The code Brett mentioned is mixed, I fear. Looking at mpn/generic/mod_1_1.c,if MOD_1_1P_METHOD == 1, the value[2] in the array is always set and always used; if MOD_1_1P_METHOD == 2, the value[2] is set only if cnt!=0, and it is used only if cnt!=0. There are also some assembler code implementations, each one with its couple of functions. > So, in mpn/generic/mod_1_1.c, I also changed > # define MOD_1_1P_METHOD 1/* need to make sure this is 2 for asm testing > */ > Not enough, MOD_1_1P_METHOD may be defined by gmp-mparam.h One should also check how MOD_1N_TO_MOD_1_1_THRESHOLD interact with the tests. > ASSERT (bmodb[2] != -1); > > But even with that, I don't get any failure. > Actually it is possible to trigger this, if you put it in the wrong place, I mean, outside the branch actually using the value... but it is not interesting. Ĝis, Marco ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c
Ciao,
31 ago 2023, 16:30 da ku...@shaw.ca:
> 1) Edit line 248 mpn/generic/mp_limb_t pre[4]; into:
>
~/src/gmp$ hg diff mpn/generic/
diff -r 3ac5afa36be5 mpn/generic/mod_1.c
--- a/mpn/generic/mod_1.c Wed Nov 02 13:48:37 2022 +0100
+++ b/mpn/generic/mod_1.c Thu Aug 31 16:46:35 2023 +0200
@@ -245,7 +245,7 @@
}
else
{
- mp_limb_t pre[4];
+ mp_limb_t pre[4] = {-1, -1, -1, -1};
mpn_mod_1_1p_cps (pre, b);
return mpn_mod_1_1p (ap, n, b, pre);
}
> 2) Recompile GMP.
>
~/src/gmp$ mkdir testbuild; (cd testbuild/;../configure&) >/dev/null
> 3) Use the mpn_mod_1() function as described on the following page and you
> will now get incorrect results:
>
~/src/gmp$ (cd testbuild/;make TESTS="t-mod_1" check -C tests/mpn; )|tail -n 15
PASS: t-mod_1
Testsuite summary for GNU MP 6.2.99
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
Even the modified library passes the tests.
Sorry, I'm not able to reproduce your bug report, not even with an arbitrarily
modified source code.
~/src/gmp$ hg revert mpn/generic/
sto ripristinando mpn/generic/mod_1.c
I'd say that when the limb you are looking at is not initialized, then a
function not using it is called.
I'd suggest: when reading mpn/generic/mod_1_1.c, pay attention to #if and
#endif .
Ĝis,
Marco
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Unsigned integer overflow in `toom_eval_pm2.c`
Ciao,
4 set 2023, 08:02 da ni...@lysator.liu.se:
> As Vincent suggested, it would be good to document somewhere what the
> convention is (values 0 or ~0).
>
Would a comment "It returns 0 or ~0, depending on the sign of the result"
added to all the mpn_toom_eval_ functions suffice?
> And maybe change to 0 and 1 convention,
>
I see a line
mpn/generic/toom42_mul.c: vm1_neg = mpn_toom_eval_dgr3_pm1 (as1, asm1, ap, n,
s, a0_a2) & 1;
where we actually use 0 or 1, and many lines like
mpn/generic/toom52_mul.c: flags = (enum toom6_flags) (toom6_vm2_neg &
mpn_toom_eval_pm2 (as2, asm2, 4, ap, n, s, a1a3));
where we use the value as a mask: 0 or ~ 0.
>From the value in {0,1} we can get mask = -value, and from the mask in {0, ~0}
>we can get value = mask & 1.
Of course we can switch to a different convention, if someone feels it's
important. I don't.
> since that fits better with assigning it from the return value from
> mpn_sub_n, and it seems generally more consistent with how we handle
>
We never use mpn_sub_n to assign that value.
> boolean values elsewhere. But may need further changes, like to
> abs_sub_add_n, also noted by Vincent.
>
Yes, Vincent is right. New patch.
Should the value ~0 be written as ~0U to be correctly assigned to an unsigned?
Ĝis,
m
diff -r e3cc6f9e9753 gmp-impl.h
--- a/gmp-impl.h Sun Aug 27 20:47:01 2023 +0200
+++ b/gmp-impl.h Mon Sep 04 09:40:02 2023 +0200
@@ -1481,25 +1481,25 @@
__GMP_DECLSPEC void mpn_toom_interpolate_16pts (mp_ptr, mp_ptr, mp_ptr, mp_ptr, mp_ptr, mp_size_t, mp_size_t, int, mp_ptr);
#define mpn_toom_couple_handling __MPN(toom_couple_handling)
-__GMP_DECLSPEC void mpn_toom_couple_handling (mp_ptr, mp_size_t, mp_ptr, int, mp_size_t, int, int);
+__GMP_DECLSPEC void mpn_toom_couple_handling (mp_ptr, mp_size_t, mp_ptr, unsigned, mp_size_t, int, int);
#define mpn_toom_eval_dgr3_pm1 __MPN(toom_eval_dgr3_pm1)
-__GMP_DECLSPEC int mpn_toom_eval_dgr3_pm1 (mp_ptr, mp_ptr, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_dgr3_pm1 (mp_ptr, mp_ptr, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
#define mpn_toom_eval_dgr3_pm2 __MPN(toom_eval_dgr3_pm2)
-__GMP_DECLSPEC int mpn_toom_eval_dgr3_pm2 (mp_ptr, mp_ptr, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_dgr3_pm2 (mp_ptr, mp_ptr, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
#define mpn_toom_eval_pm1 __MPN(toom_eval_pm1)
-__GMP_DECLSPEC int mpn_toom_eval_pm1 (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_pm1 (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
#define mpn_toom_eval_pm2 __MPN(toom_eval_pm2)
-__GMP_DECLSPEC int mpn_toom_eval_pm2 (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_pm2 (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, mp_ptr);
#define mpn_toom_eval_pm2exp __MPN(toom_eval_pm2exp)
-__GMP_DECLSPEC int mpn_toom_eval_pm2exp (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, unsigned, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_pm2exp (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, unsigned, mp_ptr);
#define mpn_toom_eval_pm2rexp __MPN(toom_eval_pm2rexp)
-__GMP_DECLSPEC int mpn_toom_eval_pm2rexp (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, unsigned, mp_ptr);
+__GMP_DECLSPEC unsigned mpn_toom_eval_pm2rexp (mp_ptr, mp_ptr, unsigned, mp_srcptr, mp_size_t, mp_size_t, unsigned, mp_ptr);
#define mpn_toom22_mul __MPN(toom22_mul)
__GMP_DECLSPEC void mpn_toom22_mul (mp_ptr, mp_srcptr, mp_size_t, mp_srcptr, mp_size_t, mp_ptr);
diff -r e3cc6f9e9753 mpn/generic/toom54_mul.c
--- a/mpn/generic/toom54_mul.c Sun Aug 27 20:47:01 2023 +0200
+++ b/mpn/generic/toom54_mul.c Mon Sep 04 09:40:02 2023 +0200
@@ -61,7 +61,7 @@
mp_srcptr bp, mp_size_t bn, mp_ptr scratch)
{
mp_size_t n, s, t;
- int sign;
+ unsigned sign;
/* decomposition ***/
#define a4 (ap + 4 * n)
diff -r e3cc6f9e9753 mpn/generic/toom63_mul.c
--- a/mpn/generic/toom63_mul.c Sun Aug 27 20:47:01 2023 +0200
+++ b/mpn/generic/toom63_mul.c Mon Sep 04 09:40:02 2023 +0200
@@ -37,8 +37,9 @@
#include "gmp-impl.h"
-/* Stores |{ap,n}-{bp,n}| in {rp,n}, returns the sign. */
-static int
+/* Stores |{ap,n}-{bp,n}| in {rp,n}. */
+/* It returns 0 or ~0, depending on the sign of the result. */
+static unsigned
abs_sub_n (mp_ptr rp, mp_srcptr ap, mp_srcptr bp, mp_size_t n)
{
mp_limb_t x, y;
@@ -65,9 +66,10 @@
return 0;
}
-static int
+/* It returns 0 or ~0, depending on the sign of the result rm. */
+static unsigned
abs_sub_add_n (mp_ptr rm, mp_ptr rp, mp_srcptr rs, mp_size_t n) {
- int result;
+ unsigned result;
result = abs_sub_n (rm, rp, rs, n);
ASSERT_NOCARRY(mpn_add_n (rp, rp, rs, n));
return result;
@@ -99,7 +101,7 @@
{
mp_size_t n, s, t;
mp_limb_t cy;
- int sign;
+
Re: Side-channel leakage in the mpz_powm_sec interface
Ciao,
25 ago 2023, 08:11 da ni...@lysator.liu.se:
> Niels Möller writes:
>
>> It's preferable to use the mpn_powm_sec. When using mpz_t, I see no
>> reasonable to avoid leakage of the normalized size (or number of
>> all-zero limbs at the most significant end).
>>
> One possibly unreasonable approach for consideration:
>
> 1. Document that the mpz_t result from mpz_powm_sec always has an alloc
> size >= n, where n is the limb size of the modulo input, and that the
> limb array is zero padded up to n.
>
You write ">= n" and not "=n" because if it was larger we avoid to re-allocate
it, right?
> 2. Ensure that the implementation complies with (1) (probably easy, if
> array is written by a call to mpn_sec_powm).
>
The current implementation uses a buffer, and copies only the relevant
(non-zero) limbs at the end. As usual, this is done to handle reuse of an
operand as the result variable.
> 3. Do the normalization, i.e., assignment of the size field, by
> side-channel silent logic iterating over all n limbs.
>
This sounds not too complex to do. Even if, as usual, C code is prone to
compiler optimizations...
I think this is a good idea.
> However, any application taking advantage of (1) (and thus avoiding
> calling any other mpz functions on the result) could maybe just as well
> use mpn_sec_powm directly?
>
The application does not really need to "take advantage of" the fact that
allocated space may be larger than the strictly-needed space, should it?
But this can heal the allocation problem on the result-side. If the operand to
be passed to mpz_powm_sec is previously handled by some other mpz_ non _sec
function, then its size in memory can be different...
A possible implementation of your 2-3 points (I didn't look at documentation)
could be the following.
Also the if branch could be replaced with silent logic, but I'd rather document
that the function is silent if the base is positive.
Gis,m
--- a/mpz/powm_sec.c Fri Oct 28 16:31:44 2022 +0200
+++ b/mpz/powm_sec.c Fri Aug 25 10:38:35 2023 +0200
@@ -85,7 +85,13 @@
rn = n;
- MPN_NORMALIZE (rp, rn);
+ {
+ int z = ! rp[--rn];
+ mp_size_t cz = z;
+ for (; rn; cz += (z &= ! rp[--rn]) )
+ ;
+ rn = n - cz;
+ }
if ((ep[0] & 1) && SIZ(b) < 0 && rn != 0)
{
@@ -94,9 +100,9 @@
MPN_NORMALIZE (rp, rn);
}
- MPZ_NEWALLOC (r, rn);
+ MPZ_NEWALLOC (r, n);
SIZ(r) = rn;
- MPN_COPY (PTR(r), rp, rn);
+ MPN_COPY (PTR(r), rp, n);
TMP_FREE;
}
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: clang warning about mini-gmp.c when used in Emacs
Ciao, Il Lun, 18 Aprile 2022 9:38 am, Paul Eggert ha scritto: > mini-gmp.c is different from gmp-impl.h, because it's intended to be > used by lots of downstream projects which may use compilers that > gmp-impl.h does not use. This may help to explain why it needs casts > that gmp-impl.h doesn't need. gmp$ ./configure CC="gcc -Wall -Werror" [...] configure: error: could not find a working compiler, see config.log for details Yes, you are right... a too fussy compiler is not considered a working compiler by the "configure" script :-) Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: make check fails; fedora core 37 (x86_64)
Ciao George,
Il 2022-04-08 18:16 George R Goffe ha scritto:
I'm having a bit of trouble building gmp from the source repository
at:. Here's what make check "tells me". I probably did something wrong
but, for the life of me, can't see it. Here's a snip from the full
build (included).
You attached a gzip-ed version of a gzip-ed version of ... what? The
"log" starts with:
which () { ( alias;
eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias
--read-functions --show-tilde --sho
w-dot $@
}
#!/bin/bash -xv
This is not code from GMP, those are not messages from the
configure&& check process...
Did you use some kind of script for the whole process?
Can you help me please?
9114 FAIL: t-bswap
9117 FAIL: t-count_zeros
9120 FAIL: t-modlinv
9122 FAIL: t-popc
9124 FAIL: t-parity
9126 FAIL: t-sub
Almost everything fails. There is probably something wrong in your
building environment or in the building process.
I'd suggest you to start from a released tarball.
You can find the announce of the last release here:
https://gmplib.org/list-archives/gmp-announce/2020-November/49.html
If you can not build it, please ask to the fedora community. They
managed to build the package for the fc36 (x86_64) flavour:
https://fedora.pkgs.org/rawhide/fedora-x86_64/gmp-6.2.1-2.fc36.x86_64.rpm.html
I'm sure it is possible to build it also for the core 37 one...
Then, if you find a bug, please read the following page before writing
again to this list:
https://gmplib.org/manual/Reporting-Bugs
Ĝis,
m
--
http://bodrato.it/papers/
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Reporting a gmp bug
Ciao, Il 2022-10-26 13:40 ni...@lysator.liu.se ha scritto: jy l writes: It seems like in `mpz_nextprime` this line ( https://gmplib.org/repo/gmp/file/tip/mpz/nextprime.c#l204), when `n` is very large, it doesn't restrict the value of `odds_in_composite_sieve` which leads to the `alloca` below crash and might cause more buffer You are right. Thank you very much for the report. I agree the array size odds_in_composite_sieve should have an upper bound here (and if we expect a very large sieve to be useful, it should be allocated with TMP_ALLOC_TYPE, which falls back to heap allocation for large sizes). I'd like to have the time to rewrite that part of the code, but I actually don't. I agree, we probably don't really need a very large array, and the code should work with any size. But the author of the code proposed the 5*nbits size, and this size can be used... I then just applied a patch following your suggestion: use ALLOC instead of SALLOC. I'm afraid I don't understand the comment /* Corresponds to a merit 14 prime_gap, which is rare. */ odds_in_composite_sieve = 5 * nbits; The author of the code was working on large prime gaps (large sequences of composites between two primes). The "merit" is some kind of measure of how much unlikely the size of a prime gap is, so that the likeliness of a gap of 1000 numbers between primes with 1000 digits can be compared with the likeliness of a gap of 900 numbers only, but with much smaller primes. But I do not know the details. I'm sure that one can find them on mersenneforum :-) and I assume that also a shorter array should work very well :-D Ĝis, m -- http://bodrato.it/papers/ ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mini-gmp mpz_powm incorrect result
Ciao,
Il 2022-08-30 10:25 Vincent Lefevre ha scritto:
or even (mn == 0 check just above this code rules out |m| < 1)
mpz_set_ui (r, mpz_cmpabs_ui (m, 1));
I agree with this solution. Will you commit it?
Concerning this second solution, the GMP manual says:
-- Function: int mpz_cmpabs_ui (const mpz_t OP1, unsigned long int
OP2)
Compare the absolute values of OP1 and OP2. Return a positive
value if abs(OP1) > abs(OP2), zero if abs(OP1) = abs(OP2), or a
negative value if abs(OP1) < abs(OP2).
So if the mpz_cmpabs_ui implementation is changed so that it can
return a value larger than 1, you need to make sure to remember to
update the code.
I propose to also add a couple of tests to mini-gmp/tests/t-powm.c , to
keep track of this.
8<--
diff -r b0d6b9f5807e mini-gmp/tests/t-powm.c
--- a/mini-gmp/tests/t-powm.c Sat Aug 20 18:44:17 2022 +0200
+++ b/mini-gmp/tests/t-powm.c Mon Sep 05 19:02:23 2022 +0200
@@ -53,6 +53,31 @@
abort ();
}
}
+
+ if (mpz_cmp_ui (res, 1) <= 0)
+mpz_add_ui (res, res, 9);
+
+ mpz_set_ui (e, 0);
+ /* Test the case m^0 (mod m), expect 1 (m is greater than 1). */
+ mpz_powm (res, res, e, res);
+ if (mpz_cmp_ui (res, 1) != 0)
+{
+ fprintf (stderr, "mpz_powm failed: b=m, e=0; 1 expected,\n");
+ dump ("m", res);
+ dump ("r", res);
+ abort ();
+}
+
+ /* Now res is 1. */
+ /* Test the case 1^0 (mod 1), expect 0. */
+ mpz_powm (res, res, e, res);
+ if (mpz_size (res))
+{
+ fprintf (stderr, "mpz_powm failed: b=1, e=0, m=1; 0
expected,\n");
+ dump ("r", res);
+ abort ();
+}
+
mpz_clear (b);
mpz_clear (e);
mpz_clear (m);
8<--
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mini-gmp mpz_powm incorrect result
Il 2022-09-05 19:04 Marco Bodrato ha scritto: Il 2022-08-30 10:25 Vincent Lefevre ha scritto: or even (mn == 0 check just above this code rules out |m| < 1) mpz_set_ui (r, mpz_cmpabs_ui (m, 1)); I agree with this solution. Will you commit it? I incorrectly removed the "Niels Möller wrote:" line. The question is for Niels, of course. I propose to also add a couple of tests to mini-gmp/tests/t-powm.c , to keep track of this. I'll push the tests just after the correction... Ĝis, m PS: thanks for the report ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mini-gmp mpz_powm incorrect result
Ciao, Il 2022-09-05 21:23 ni...@lysator.liu.se ha scritto: Marco Bodrato writes: I propose to also add a couple of tests to mini-gmp/tests/t-powm.c , to keep track of this. Definitely needed, thanks for looking into that. + if (mpz_cmp_ui (res, 1) <= 0) +mpz_add_ui (res, res, 9); Adding 9 looks very arbitrary? It is arbitrary. It is large enough to not be completely trivial and small enough to be short to write. I added a comment, saying that it is arbitrary :-) Can we test mpz_powm (res, b, e, m), with e set to 0, and first |m| > 1, then m = ±1? To get coverage for various signs and values for b and m. The code handling e=0 is not so complex to deserve a sophisticated test. Anyway, of course the test can be improved. BTW, it seems docs for mpz_powm doesn't say explicitly what 0^0 (mod m) should give? But docs for mpz_*_pow_ui does say that 0^0 yields 1, so for consitency, powm should give 1 mod m, which I think is what the code (with fix) does. Especially for _powm it is a good idea to return [1] for any x^0, regardless of x (i.e. also when x is 0). Otherwise, we should check whether x is 0 or not mod m. We just added the exception that the class [1] is represented by 0 when the modulus m=0. But that's not an exception wrt the above idea. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mini-gmp mpz_gcdext Bézout coefficients do not match documentation
Ciao Niels,
17 feb 2024, 17:53 da ni...@lysator.liu.se:
> Niels Möller writes:
> The documented conditions say that gmp should return the same cofactors
>
The documentation also says "If abs(a) = abs(b), then s = 0, t = sgn(b)."
>
> canonicalization logic at the end wasn't right. Appending a patch with a
> fix + stricter tests.
>
And if I correctly patched and tested your proposed code. with equal numbers I
get t=0, instead of s=0.
> Without the fix, we could make the wrong choice in case
>
> |s'| = |s| = |b| / 2g
>
> Since it's a bit subtle, it would be nice with a review of this code
> before I commit it.
>
Shat about simply changing the test from > to >= ?
/* Arrange so that |s| < |u| / 2g */
mpz_add (s1, s0, s1);
- if (mpz_cmpabs (s0, s1) > 0)
+ if (mpz_cmpabs (s0, s1) >= 0)
{
mpz_swap (s0, s1);
mpz_sub (t0, t0, t1);
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mini-gmp mpz_gcdext Bézout coefficients do not match documentation
Ciao, 17 feb 2024, 19:15 da : > Ciao Niels, > > 17 feb 2024, 17:53 da ni...@lysator.liu.se: > >> Niels Möller writes: >> The documented conditions say that gmp should return the same cofactors >> > > The documentation also says "If abs(a) = abs(b), then s = 0, t = sgn(b)." > Maybe we should also add the test: /* Require that s==0 iff g==abs(b) */ if (!mpz_sgn (s) ^ !mpz_cmpabs (g, b)) goto fail; Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mini-gmp mpz_gcdext Bézout coefficients do not match documentation
Ciao Niels,
17 feb 2024, 21:26 da ni...@lysator.liu.se:
> marco.bodr...@tutanota.com writes:
>
>> Maybe we should also add the test:
>>
>> /* Require that s==0 iff g==abs(b) */
>> if (!mpz_sgn (s) ^ !mpz_cmpabs (g, b))
>> goto fail;
>>
>
> Good point, that's better than only checking the special case |a| ==
> |b|. (But maybe more readable with != instead of ^).
>
Yes, with != it's more readable!
> To get mini-gmp to conform, I find no simpler way than special casing s
> == 0, like
>
s==0 is not a special case, it's one of the cases with smaller |s|.
What about;
/* Arrange so that |s| < |u| / 2g */
mpz_add (s1, s0, s1);
{
int cmp = mpz_cmpabs (s0, s1);
if (cmp >= 0)
{
mpz_swap (s0, s1);
mpz_sub (t1, t0, t1);
if (cmp != 0 || mpz_cmpabs (t0, t1) > 0)
mpz_swap (t0, t1);
}
}
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: major formatted output function bug with %c and the value 0
Ciao Vincent,
15 dic 2023, 13:26 da vinc...@vinc17.net:
> Note that there are similar issues in printf/repl-vsnprintf.c, and I
>
I finally had the time to examine the code and test it. I attach a proposed
patch.
I changed the 3 files: printf/doprntf.c, printf/repl-vsnprintf.c,
printf/sprintffuns.c, to use the returned value of the called functions,
instead of calling strlen on the string.
I also slightly changed the tests, to check at least one case with "%c", 0.
For this to work I also had to change a
- (*__gmp_free_func) (got, strlen(got)+1);
+ (*__gmp_free_func) (got, got_len+1);
When the string comes from a generic print, it is safer to relay on the return
value than on the length computed by strlen()...
> think that this is the cause of the MPFR failure with MS Visual C++
> (vsnprintf is used by gmp_vasprintf).
>
If you can also test on that side, let me know. Thanks!
Gis,
m
diff -r 1c566525476a printf/doprntf.c
--- a/printf/doprntf.c Wed Dec 27 19:35:36 2023 +0100
+++ b/printf/doprntf.c Sun Feb 18 12:17:18 2024 +0100
@@ -267,8 +267,7 @@
mean truncation */
ASSERT (explen >= 0 && explen < sizeof(exponent)-1);
#else
- sprintf (exponent, p->expfmt, expsign, expval);
- explen = strlen (exponent);
+ explen = sprintf (exponent, p->expfmt, expsign, expval);
ASSERT (explen < sizeof(exponent));
#endif
TRACE (printf (" expfmt %s gives %s\n", p->expfmt, exponent));
diff -r 1c566525476a printf/repl-vsnprintf.c
--- a/printf/repl-vsnprintf.c Wed Dec 27 19:35:36 2023 +0100
+++ b/printf/repl-vsnprintf.c Sun Feb 18 12:17:18 2024 +0100
@@ -364,16 +364,14 @@
if (total_width <= buf_size)
{
- vsprintf (buf, orig_fmt, orig_ap);
- len = strlen (buf);
+ len = vsprintf (buf, orig_fmt, orig_ap);
}
else
{
char *s;
s = __GMP_ALLOCATE_FUNC_TYPE (total_width, char);
- vsprintf (s, orig_fmt, orig_ap);
- len = strlen (s);
+ len = vsprintf (s, orig_fmt, orig_ap);
if (buf_size != 0)
{
size_t copylen = MIN (len, buf_size-1);
diff -r 1c566525476a printf/sprintffuns.c
--- a/printf/sprintffuns.c Wed Dec 27 19:35:36 2023 +0100
+++ b/printf/sprintffuns.c Sun Feb 18 12:17:18 2024 +0100
@@ -53,9 +53,9 @@
{
char *buf = *bufp;
int ret;
- vsprintf (buf, fmt, ap);
- ret = strlen (buf);
- *bufp = buf + ret;
+ ret = vsprintf (buf, fmt, ap);
+ if (ret > 0)
+*bufp = buf + ret;
return ret;
}
diff -r 1c566525476a tests/misc/t-printf.c
--- a/tests/misc/t-printf.c Wed Dec 27 19:35:36 2023 +0100
+++ b/tests/misc/t-printf.c Sun Feb 18 12:17:18 2024 +0100
@@ -128,12 +128,11 @@
}
void
-check_vsprintf (const char *want, const char *fmt, va_list ap)
+check_vsprintf (const char *want, int want_len, const char *fmt, va_list ap)
{
char got[MAX_OUTPUT];
- int got_len, want_len;
+ int got_len;
- want_len = strlen (want);
got_len = gmp_vsprintf (got, fmt, ap);
if (got_len != want_len || strcmp (got, want) != 0)
@@ -149,14 +148,12 @@
}
void
-check_vfprintf (const char *want, const char *fmt, va_list ap)
+check_vfprintf (const char *want, int want_len, const char *fmt, va_list ap)
{
char got[MAX_OUTPUT];
- int got_len, want_len, fread_len;
+ int got_len, fread_len;
long ftell_len;
- want_len = strlen (want);
-
rewind (check_vfprintf_fp);
got_len = gmp_vfprintf (check_vfprintf_fp, fmt, ap);
ASSERT_ALWAYS (got_len != -1);
@@ -187,14 +184,12 @@
}
void
-check_vsnprintf (const char *want, const char *fmt, va_list ap)
+check_vsnprintf (const char *want, int want_len, const char *fmt, va_list ap)
{
chargot[MAX_OUTPUT+1];
- int ret, got_len, want_len;
+ int ret, got_len;
size_t bufsize;
- want_len = strlen (want);
-
bufsize = -1;
for (;;)
{
@@ -243,12 +238,11 @@
}
void
-check_vasprintf (const char *want, const char *fmt, va_list ap)
+check_vasprintf (const char *want, int want_len, const char *fmt, va_list ap)
{
char *got;
- int got_len, want_len;
+ int got_len;
- want_len = strlen (want);
got_len = gmp_vasprintf (, fmt, ap);
if (got_len != want_len || strcmp (got, want) != 0)
@@ -261,19 +255,17 @@
printf (" want_len %d\n", want_len);
abort ();
}
- (*__gmp_free_func) (got, strlen(got)+1);
+ (*__gmp_free_func) (got, got_len+1);
}
void
-check_obstack_vprintf (const char *want, const char *fmt, va_list ap)
+check_obstack_vprintf (const char *want, int want_len, const char *fmt, va_list ap)
{
#if HAVE_OBSTACK_VPRINTF
struct obstack ob;
- int got_len, want_len, ob_len;
+ int got_len, ob_len;
char *got;
- want_len = strlen (want);
-
obstack_init ();
got_len = gmp_obstack_vprintf (, fmt, ap);
got = (char *) obstack_base ();
@@ -300,15 +292,30 @@
void
check_one (const char *want, const char *fmt, ...)
{
+ int want_len = strlen (want);
va_list ap;
va_start (ap, fmt);
/* simplest first */
- check_vsprintf (want, fmt, ap);
-
Re: mini-gmp mpz_gcdext Bézout coefficients do not match documentation
Ciao Niels,
18 feb 2024, 10:10 da ni...@lysator.liu.se:
> marco.bodr...@tutanota.com writes:
>
>> What about;
>>
>>
>> /* Arrange so that |s| < |u| / 2g */
>> mpz_add (s1, s0, s1);
>> {
>> int cmp = mpz_cmpabs (s0, s1);
>> if (cmp >= 0)
>> {
>> mpz_swap (s0, s1);
>> mpz_sub (t1, t0, t1);
>> if (cmp != 0 || mpz_cmpabs (t0, t1) > 0)
>> mpz_swap (t0, t1);
>> }
>> }
>>
>
> I think swapping of s and t must go together? I've tried out this
> similar variant
>
You are right, it's better with the two swaps together.
> mpz_add (s1, s0, s1);
> mpz_sub (t1, t0, t1);
> cmp = mpz_cmpabs (s0, s1);
> if (cmp > 0 || (cmp == 0 && mpz_cmpabs (t0, t1) > 0))
> {
> mpz_swap (s0, s1);
> mpz_swap (t0, t1);
> }
>
The only reason why I prefer my solution is: when cmp<0, there is no need to
compute
mpz_sub (t1, t0, t1);
> Seems to work fine, and it's a rather clear way to express the "lexical"
> preference that we want the cofactor pair with the smallest of |s|, |s'|, but
> in case of a tie, we choose the pair with smallest |t|, |t'|.
>
I agree.
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: major formatted output function bug with %c and the value 0
Ciao,
13 dic 2023, 15:53 da vinc...@vinc17.net:
> On 2023-12-03 20:19:10 +0100, Vincent Lefevre wrote:
>
>> With GMP 6.3.0, the formatted output functions do not handle %c
>> with the value 0 correctly. For gmp_sprintf, the return value is
>> incorrect.
>>
> In printf/sprintffuns.c, function gmp_sprintf_format(), I suppose that
>
> vsprintf (buf, fmt, ap);
> ret = strlen (buf);
>
> should actually be something like
>
> ret = vsprintf (buf, fmt, ap);
> if (ret < 0)
> ret = 0;
>
> to avoid issues due to non-terminating null characters (not tested).
>
It was changed in 2001, probably a workaround, because the comment was
"Don't use sprintf return value (it's a pointer on SunOS 4)"
https://gmplib.org/repo/gmp/rev/0889877bb94a
Maybe we should simply "revert" that change, and use the return value both from
sprintf (in printf/doprntf.c) and from vsprintf (in printf/sprintffuns.c)?
Or, if we care not to modify the pointer bufp, we can use something like the
following:
diff -r f6073853d16a printf/sprintffuns.c
--- a/printf/sprintffuns.c Mon Oct 16 08:16:06 2023 +0200
+++ b/printf/sprintffuns.c Wed Dec 13 19:53:50 2023 +0100
@@ -53,9 +53,9 @@
{
char *buf = *bufp;
int ret;
- vsprintf (buf, fmt, ap);
- ret = strlen (buf);
- *bufp = buf + ret;
+ ret = vsprintf (buf, fmt, ap);
+ if (ret > 0)
+ *bufp = buf + ret;
return ret;
}
It passes the test suite, but I didn't really think about what it does.
Ĝis,
mb
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Inconsistent definitions of millerrabin() argument types
Ciao, 24 mar 2024, 10:59 da cas...@gmail.com: > Hi, > > In millerrabin.c, there are conflicting definitions for millerrabin(). > > The prototype is: > I removed the prototype, by swapping the function order :-) Thanks. m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: major formatted output function bug with %c and the value 0
Ciao, 18 feb 2024, 12:29 da marco.bodr...@tutanota.com: > 15 dic 2023, 13:26 da vinc...@vinc17.net: > >> Note that there are similar issues in printf/repl-vsnprintf.c, and I >> > > I finally had the time to examine the code and test it. I attach a proposed > patch. > Vincent, you did not confirm that this code worked for you, but I pushed it anyway. https://gmplib.org/repo/gmp/rev/4ac76064639e Thanks. m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Reduced number of allocated limbs after calling mpz_remove
Ciao, 20 mag 2024, 16:40 da ni...@lysator.liu.se: > Albin Ahlbäck writes: > >> In the project I help maintaining, we have started to rely on that mpz >> never reduce the number of limbs. This is to keep a minimum number of >> limbs allocated to 2 >> With lazy allocation, we moved toward the opposite direction, but having at least two limbs when at least one is allocated anyway might be a good idea. > Could you use mpz_limbs_write (x, 2) for the functions that want a > result area of at least two limbs? > They can, but surely they want an already allocated couple of limbs for speed reasons, calling _limbs_write every now and then might not be in the spirit of the optimization. >> Since this indeed seems to be the exception, I am fine with either >> documenting that this indeed is the exception (perhaps it should then >> be stated under the section "Memory management" as well as the >> docstring for `mpz_remove`), or fixing this in `mpz_remove`. >> Actually the manual (https://gmplib.org/manual/Memory-Management ) reads: "mpz_t and mpq_t variables never reduce their allocated space." The mis-behaviour of mpz_remove is my fault. When I experimented with that function I tested both the "never reduce" and the "may reduce" version, but when I did commit I forgot to push the correct one. https://gmplib.org/repo/gmp/rev/596470e0bc62 As you can see, the correct code is already there, but #if-ed out because WANT_ORIGINAL_DEST is not defined. > I don't have a strong opinion on how to fix this discrepancy between > docs and implementation. > I'll correct the _remove function, it's quite easy to do :-) > But I feel rather strongly that mini-gmp > shouldn't make this promise, so code that rely on it will not work with > mini-gmp. > I agree for the mini-gmp side. Ĝis, mb ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
