Re: make check test failures on (MacOS 14.5, M3 pro, Xcode 15.3)

[Niels Möller]

Luc des Trois Maisons  writes:

> This doesn't appear to be listed in the known build problems, or the
> Notes for particular systems. Apologies in advance if duplicate.

My guess it's a known issue with Apple ARM systems and gmp-6.2.1 (see
https://gmplib.org/#STATUS). Please try latest release, 6.3.0.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

Torbjörn Granlund  writes:

> It is possible that the docs need clarification.

I think so, we should not write "never" if that's not what we mean.

My understanding is that allocation grows as needed, and is not returned
to the the system until mpz_clear. Except that allocation can shrink
only as the effect of mpz_realloc2 (never called internally) or mpz_swap
(called internally in few places).

But we also shouldn't over-allocate things. It could perhaps be
described like this: Each mpz output for a gmp function has an "expected
size" depending on the sizes of the inputs. E.g., excpected size of the
mpz_add output is the size of the largest input + 1, while actual size
may be as small as zero, due to cancellation.

On return, the allocation size of of an mpz_t output parameter should
either be unchanged (available storage could be reused, without any
reallocation, pointer would typically be unchanged too in this case), or
at most a limb or two larger than the expected output size for the
operation. E.g., mpz_powm internally needs storage for squares (twice
the expected output size), but it shouldn't inflate the allocation of
the output parameter to that size.

To the GMP application, the allocation size of an mpz_t is then bounded
by the largest "expected size" for any operation ever using that mpz_t
as output (+ effects of any mpz_swap or mpz_realloc2 in the
*application* code), which should be sufficient to get predictable
memory usage.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

marco.bodr...@tutanota.com writes:

>> 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 :-)

Nice! To avoid regressions, it would be good to have tests for this.
Could possibly go in tests/mpz/reuse.c, but looks like a fair amount of
work to do properly.

>> 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.

Then it should be documented as an exception in mini-gmp/README.
Suggested update below.

Regards,
/Niels

--- a/mini-gmp/README   Wed May 15 20:51:11 2024 +0200
+++ b/mini-gmp/README   Mon May 20 20:53:53 2024 +0200
@@ -39,21 +39,24 @@ mini-gmp as a fallback when for some rea
 not desired as a dependency.
 
 The supported GMP subset of the mpn and mpz interfaces is declared in
-mini-gmp.h, and implemented in mini-gmp.c. The implemented
-functions are fully compatible with the corresponding GMP functions,
-as specified in the GMP manual, with a few exceptions:
+mini-gmp.h, and implemented in mini-gmp.c. The supported GMP subset of
+the mpq layer is declared in mini-mpq.h, and implemented in
+mini-mpq.c. The implemented functions are fully compatible with the
+corresponding GMP functions, as specified in the GMP manual, with a
+few exceptions:
 
   mpz_export and mpz_import support only NAILS = 0.
 
+  mini-gmp's handling of destinations operands does not satisfy the
+  documented property that 'mpz_t' and 'mpq_t' variables never reduce
+  their allocated space.
+
 The performance target for mini-gmp is to be at most 10 times slower
 than the real GMP library, for numbers of size up to a few hundred
 bits. No asymptotically fast algorithms are included in mini-gmp, so
 it will be many orders of magnitude slower than GMP for very large
 numbers.
 
-The supported GMP subset of the mpq layer is declared in mini-mpq.h,
-and implemented in mini-mpq.c.
-
 You should never "install" mini-gmp. Applications can either just
 #include mini-gmp.c (but then, beware that it defines several macros
 and functions outside of the advertised interface), and if needed


-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

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, so that if one where to do a multiplication of
> two limbs, the result is guaranteed to fit inside the mpz without
> having to do a reallocation.

Thanks for explaining. To me, it seems a bit brittle to rely in this.

Could you use mpz_limbs_write (x, 2) for the functions that want a
result area of at least two limbs? Added in gmp-6-0.0. There's also the
mpz_realloc2 function, which does something related, but which may also
shrink the allocation.

> 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`.

I don't have a strong opinion on how to fix this discrepancy between
docs and implementation. But I feel rather strongly that mini-gmp
shpuldn't make this promise, so code that rely on it will not work with
mini-gmp.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

Albin Ahlbäck  writes:

> It is stated in the documentation that "mpz_t and mpq_t variables
> never reduce their allocated space.", which is sort of true given that
> `x` and `dest` are only being swapped, but that requires the user to
> know what the internals are doing.

Whenever an mpz function is called with destination operant equal to one
of the inputs, and the lower-level functions don't support in-place
operation, mpz functions would need to either

1. allocate new storage for the result (violating the above property),
or

2. allocate a copy of the inputs.

It looks like mpz_remove does option (1), while, e.g., mpz_tdiv_qr
follows option (2). I would prefer to give the implementation a bit more
freedom. And mini-gmp follows (1) rather aggressively, even when there
is no argument overlap.

So not sure if code or docs should be adjusted ("usually not" rather
than "never"). Do you think the "never reduce their allocated space"
property is important for your usecase, or for other GMP applications
general? If the strong statement is kept, this should perhaps be mention
as another execption in mini-gmp/README.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP repository: "make" failure if yacc is not available

[Niels Möller]

Vincent Lefevre  writes:

> Is yacc a new requirement? If it is, it should be checked by the
> configure script.

It's not a requirement when building from a release tar file, since then
the files generated by bison are already included.

> Note that neither yacc nor bison is mentioned as needed by "README.HG",
> in case this is specific to the use of the hg repository.

You're right that bison should be listed in README.HG.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

marco.bodr...@tutanota.com writes:

> The only reason why I prefer my solution is: when cmp<0, there is no need to 
> compute
> mpz_sub (t1, t0, t1);

That's certainly a micro optimization, but let's keep things simple.

I've pushed this fix now, I think there were only comment and ChangeLog
changes since the previous version of the patch.

Thanks for the review,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

b, b);
 
-  mpz_gcdext (g, s, t, a, b);
-  if (!gcdext_valid_p (a, b, g, s, t))
-   {
- fprintf (stderr, "mpz_gcdext failed:\n");
- dump ("a", a);
- dump ("b", b);
- dump ("g", g);
- dump ("s", s);
- dump ("t", t);
- abort ();
-   }
+  test_one (a, b);
+}
 
-  mpz_gcd (s, a, b);
-  if (mpz_cmp (g, s))
-   {
- fprintf (stderr, "mpz_gcd failed:\n");
- dump ("a", a);
- dump ("b", b);
- dump ("r", g);
- dump ("ref", s);
- abort ();
-   }
-}
   mpz_clear (a);
   mpz_clear (b);
   mpz_clear (g);
   mpz_clear (s);
-  mpz_clear (t);
 }
diff -r 1c566525476a tests/mpz/t-gcd.c
--- a/tests/mpz/t-gcd.c Wed Dec 27 19:35:36 2023 +0100
+++ b/tests/mpz/t-gcd.c Sun Feb 18 10:02:56 2024 +0100
@@ -432,6 +432,10 @@
   if (mpz_sgn (g) <= 0)
 return 0;
 
+  /* Require that s==0 iff g==abs(b) */
+  if (!mpz_sgn (s) != !mpz_cmpabs (g, b))
+return 0;
+
   mpz_tdiv_qr (temp1, temp3, a, g);
   if (mpz_sgn (temp3) != 0)
 return 0;
@@ -440,8 +444,8 @@
   if (mpz_sgn (temp3) != 0)
 return 0;
 
-  /* Require that 2 |s| < |b/g|, or |s| == 1. */
-  if (mpz_cmpabs_ui (s, 1) > 0)
+  /* Require that 2 |s| < |b/g|, or s == sgn(a) */
+  if (mpz_cmp_si (s, mpz_sgn (a)) != 0)
 {
   mpz_mul_2exp (temp3, s, 1);
   if (mpz_cmpabs (temp3, temp2) >= 0)
@@ -456,8 +460,8 @@
   if (mpz_sgn (temp3) != 0)
 return 0;
 
-  /* Require that 2 |t| < |a/g| or |t| == 1*/
-  if (mpz_cmpabs_ui (temp2, 1) > 0)
+  /* Require that 2 |t| < |a/g| or t == sgn(b) */
+  if (mpz_cmp_si (temp2, mpz_sgn (b)) != 0)
 {
   mpz_mul_2exp (temp2, temp2, 1);
   if (mpz_cmpabs (temp2, temp1) >= 0)


-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

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 ^).

To get mini-gmp to conform, I find no simpler way than special casing s
== 0, like

  if (mpz_sgn (s0) != 0)
{
  /* Arrange so that |s| < |u| / 2g and |t| < |v| / 2g, if possible. */
  mpz_add (s1, s0, s1);
  mpz_sub (t1, t0, t1);
  if (mpz_cmpabs (s0, s1) > 0 || mpz_cmpabs (t0, t1) > 0)
{
  mpz_swap (s0, s1);
  mpz_swap (t0, t1);
}
}

And I think this is the only condition that isn't fully symmetrical, so
perhaps not surprising if it needs a special case.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

marco.bodr...@tutanota.com writes:

> And if I correctly patched and tested your proposed code. with equal numbers 
> I get t=0, instead of s=0.

Thanks for testing, I have to look into that case, then.

> 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)

I don't think that's right. My understanding is that if |s| = |s'|
(notation from my mail, the variables in the code are reassigned several
times, which is a bit confusing), then we ncessarily have |t| != |t'|,
and we must choose candidate to get the smaller one.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

Niels Möller  writes:

> Guido Vranken  writes:
>
>> Computing extended gcd using mpz_gcdext where a = 1, b = 2:
>>
>> libgmp: g: 1, s: 1, t: 0
>> mini-gmp: g: 1, s: -1, t: 1
>> This violates the docs: "s = sgn(a) if abs(b) = 2", e.g. s must be 1
>>
>> Computing extended gcd using mpz_gcdext where a = 6, b = 4:
>> libgmp: g: 2, s: 1, t: -1
>> mini-libgmp: g: 2, s: -1, t: 2
>
> I think mini-gmp is wrong here, I'll have to investigate. Thanks for
> reporting.

The documented conditions say that gmp should return the same cofactors
as one would get naturally with Euclid's algorithm. It appears mini-gmp
uses binary gcdext (I had forgotten that detail), and the
canonicalization logic at the end wasn't right. Appending a patch with a
fix + stricter tests.

At this place in the algorithm, we have a, b >= 0, and we have a
candidate s, t, with

  -b / g <= s <= 0, 0 <= t <= a / g

(not sure at which edges we might have equality), and then we construct
another candidate s', t' as

  s' = s + b / g >= 0, t' = t - a / g <= 0

And we then return s', t' if either |s'| < |s| or |t'| < |t|.

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.

Regards,
/Niels

diff -r 1c566525476a mini-gmp/mini-gmp.c
--- a/mini-gmp/mini-gmp.c   Wed Dec 27 19:35:36 2023 +0100
+++ b/mini-gmp/mini-gmp.c   Sat Feb 17 17:17:21 2024 +0100
@@ -2960,12 +2960,13 @@
   mpz_tdiv_q_2exp (t0, t0, 1);
 }
 
-  /* Arrange so that |s| < |u| / 2g */
+  /* Arrange so that |s| < |u| / 2g and |t| < |v| / 2g, if possible. */
   mpz_add (s1, s0, s1);
-  if (mpz_cmpabs (s0, s1) > 0)
+  mpz_sub (t1, t0, t1);
+  if (mpz_cmpabs (s0, s1) > 0 || mpz_cmpabs (t0, t1) > 0)
 {
   mpz_swap (s0, s1);
-  mpz_sub (t0, t0, t1);
+  mpz_swap (t0, t1);
 }
   if (u->_mp_size < 0)
 mpz_neg (s0, s0);
diff -r 1c566525476a mini-gmp/tests/t-gcd.c
--- a/mini-gmp/tests/t-gcd.cWed Dec 27 19:35:36 2023 +0100
+++ b/mini-gmp/tests/t-gcd.cSat Feb 17 17:17:21 2024 +0100
@@ -79,20 +79,20 @@
   if (mpz_sgn (r) != 0)
 goto fail;
 
-  /* Require that 2 |s| < |b/g|, or |s| == 1. */
-  if (mpz_cmpabs_ui (s, 1) > 0)
+  /* Require that 2 |s| < |b/g|, or s == sgn(a) */
+  if (mpz_cmp_si (s, mpz_sgn (a)) != 0)
 {
   mpz_mul_2exp (r, s, 1);
-  if (mpz_cmpabs (r, tb) > 0)
+  if (mpz_cmpabs (r, tb) >= 0)
goto fail;
 }
 
-  /* Require that 2 |t| < |a/g| or |t| == 1*/
-  if (mpz_cmpabs_ui (t, 1) > 0)
+  /* Require that 2 |t| < |a/g| or t == sgn(b) */
+  if (mpz_cmp_si (t, mpz_sgn (b)) != 0)
 {
   mpz_mul_2exp (r, t, 1);
-  if (mpz_cmpabs (r, ta) > 0)
-   return 0;
+  if (mpz_cmpabs (r, ta) >= 0)
+   goto fail;
 }
 
   mpz_clear (ta);
@@ -102,17 +102,53 @@
   return 1;
 }
 
+static void test_one(const mpz_t a, const mpz_t b)
+{
+  mpz_t g, s, t;
+
+  mpz_init (g);
+  mpz_init (s);
+  mpz_init (t);
+
+  mpz_gcdext (g, s, t, a, b);
+  if (!gcdext_valid_p (a, b, g, s, t))
+{
+  fprintf (stderr, "mpz_gcdext failed:\n");
+  dump ("a", a);
+  dump ("b", b);
+  dump ("g", g);
+  dump ("s", s);
+  dump ("t", t);
+  abort ();
+}
+
+  mpz_gcd (s, a, b);
+  if (mpz_cmp (g, s))
+{
+  fprintf (stderr, "mpz_gcd failed:\n");
+  dump ("a", a);
+  dump ("b", b);
+  dump ("r", g);
+  dump ("ref", s);
+  abort ();
+}
+
+  mpz_clear (g);
+  mpz_clear (s);
+  mpz_clear (t);
+}
+
 void
 testmain (int argc, char **argv)
 {
   unsigned i;
-  mpz_t a, b, g, s, t;
+  mpz_t a, b, g, s;
+  int ai, bi;
 
   mpz_init (a);
   mpz_init (b);
   mpz_init (g);
   mpz_init (s);
-  mpz_init (t);
 
   for (i = 0; i < COUNT; i++)
 {
@@ -129,6 +165,15 @@
}
 }
 
+  /* Exhaustive test of small inputs */
+  for (ai = -30; ai <= 30; ai++)
+for (bi = -30; bi <= 30; bi++)
+  {
+   mpz_set_si (a, ai);
+   mpz_set_si (b, bi);
+   test_one (a, b);
+  }
+
   for (i = 0; i < COUNT; i++)
 {
   unsigned flags;
@@ -147,32 +192,11 @@
   if (flags & 2)
mpz_neg (b, b);
 
-  mpz_gcdext (g, s, t, a, b);
-  if (!gcdext_valid_p (a, b, g, s, t))
-   {
- fprintf (stderr, "mpz_gcdext failed:\n");
- dump ("a", a);
- dump ("b", b);
- dump ("g", g);
- dump ("s", s);
- dump ("t", t);
- abort ();
-   }
+  test_one (a, b);
+}
 
-  mpz_gcd (s, a, b);
-  if (mpz_cmp (g, s))
-   {
- fprintf (stderr, "mpz_gcd failed:\n");
- dump ("a", a);
- dump ("b&

Re: mini-gmp mpz_gcdext Bézout coefficients do not match documentation

[Niels Möller]

Guido Vranken  writes:

> Computing extended gcd using mpz_gcdext where a = 1, b = 2:
>
> libgmp: g: 1, s: 1, t: 0
> mini-gmp: g: 1, s: -1, t: 1
> This violates the docs: "s = sgn(a) if abs(b) = 2", e.g. s must be 1
>
> Computing extended gcd using mpz_gcdext where a = 6, b = 4:
> libgmp: g: 2, s: 1, t: -1
> mini-libgmp: g: 2, s: -1, t: 2

I think mini-gmp is wrong here, I'll have to investigate. Thanks for
reporting.

> The docs state: "abs(s) < abs(b) / (2 g) and abs(t) < abs(a) / (2 g)"
> I think that should be: "abs(s) <= abs(b) / (2 g) and abs(t) <= abs(a) / (2
> g)"
> (< should be <=)

These strict equalities don't hold for the documented "exceptional"
cases. IT seems both your examples have abs(B) = 2G, so that's the case
that applies.

It is a bit subtle. And even if one relaxes the inequalities as you
suggest, 1 = gcd(1,1) would still be an exception (since in that case,
we'd get |s|, |t| < 1/2, i.e., s = t = 0, which isn't reasonable).

Can you suggest any doc change to make it clearer?

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: errors in make check

[Niels Möller]

Paul E Reimer  writes:

> I downloaded what I believe is the most recent version and it seem to
> have passed all checks, except for one which was skipped. (Why?) 

SKIP: t-addaddmul

is likely because mpn_addaddmul_1msb0 is an assembly function only
implemented for a few architectures, and not enabled in your build.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: parameter size mismatch in mpn_pi1_bdiv_q_1

[Niels Möller]

Robert Yates  writes:

> mpn\arm64\bdiv_q_1.asm
> define(`cnt', `x5')
> PROLOGUE(mpn_pi1_bdiv_q_1)
>   sub n, n, #1
>   subsx6, x6, x6  C clear r6 and C flag
>   ldr x9, [up],#8
>   cbz cnt, L(norm)
>
>
> the cbz instruction acts upon parameter 6(32bit int) with the x5(64bit
> register).
>
> i work on an obfuscation compiler at quarkslab, and its possible that
> optimisations or our transformation can leave random bits in the upper
> data of x5 which will make the implementation of mpn_pi1_bdiv_q_1
> fail, since clangs codegen will not emit trunc instructions for the
> 64bit register as the function prototype clearly states `i32` type
> although the internal function uses a 64bit register.

Interesting. I'm not quite familar with arm64, but I think your right
that this is an obscure bug. Almost all use of the cnt register (and the
tnc register) is for shifts, and then I take it all but the least
significant 6 bits are ignored? Except for the comparison to zero in the
cbz instruction, which depends on the higher bits.

> i noticed this issue on apple-arm64.
> i believe the implemetation should be changed to use the `w5`
> register, or the function prototype should use `long`, either of these
> solves the issues ive seen.

Changing the type would be an abi break, so not lightly done (even if
this is an internal function).

Does it work to just change all related w-registers like below patch? Or
will the assembler be unhappy with mix of x and w registers for the
shift instructions?

Regards,
/Niels

--- a/mpn/arm64/bdiv_q_1.asmMon Oct 16 08:16:06 2023 +0200
+++ b/mpn/arm64/bdiv_q_1.asmFri Dec 15 13:12:48 2023 +0100
@@ -49,10 +49,10 @@ define(`up',  `x1')
 define(`n',   `x2')
 define(`d',   `x3')
 define(`di',  `x4')C   just mpn_pi1_bdiv_q_1
-define(`cnt', `x5')C   just mpn_pi1_bdiv_q_1
+define(`cnt', `w5')C   just mpn_pi1_bdiv_q_1
 
 define(`cy',  `r7')
-define(`tnc', `x8')
+define(`tnc', `w8')
 
 ASM_START()
 PROLOGUE(mpn_bdiv_q_1)
@@ -87,7 +87,7 @@ PROLOGUE(mpn_pi1_bdiv_q_1)
 L(unorm):
lsr x12, x9, cnt
cbz n, L(eu1)
-   sub tnc, xzr, cnt
+   sub tnc, wzr, cnt
 
 L(tpu):    ldr x9, [up],#8
lsl x7, x9, tnc


-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: `checking size of mp_limb_t... 0` and `configure: error: Oops, mp_limb_t doesn't seem to work` when compiling the Microchip XC32 compiler from source

[Niels Möller]

Marc Glisse  writes:

> From acinclude.m4:
>
>
> dnl  GMP_INCLUDE_GMP_H
> dnl  -
> dnl  Expand to the right way to #include gmp-h.in.  This must be used
> dnl  instead of gmp.h, since that file isn't generated until the end
> of the
> dnl  configure.
> dnl
> dnl  Dummy value for GMP_LIMB_BITS is enough
> dnl  for all current configure-time uses of gmp.h.
>
> define(GMP_INCLUDE_GMP_H,
> [[#define __GMP_WITHIN_CONFIGURE 1   /* ignore template stuff */
> #define GMP_NAIL_BITS $GMP_NAIL_BITS
> #define GMP_LIMB_BITS 123
> $DEFN_LONG_LONG_LIMB
> #include "$srcdir/gmp-h.in"]
> ])

Ah, I wasn't aware of that. Seems to be used for four tests, the
AC_CHECK_SIZEOF for mp_limb_t (that's the one failing in this bug
report), GMP_FUNC_ALLOCA, GMP_H_EXTERN_INLINE, and GMP_H_HAVE_FILE.

I wonder if it would be more robust to temporarily(?) add -I$srcdir to
CFLAGS?

I don't quite get how this part of the configure works, e.g., I'm
looking closer at

  AC_CHECK_SIZEOF(mp_limb_t, , GMP_INCLUDE_GMP_H)

which is used for define GMP_LIMB_BITS,

  AC_SUBST(GMP_LIMB_BITS, `expr 8 \* $ac_cv_sizeof_mp_limb_t`)

The definition of mp_limb_t in gmp-h.in depends on two preprocessor
symbols, __GMP_SHORT_LIMB (not defined by configure, so presumably set
by the user, like CFLAGS=-D__GMP_SHORT_LIMB?), and _LONG_LONG_LIMB.

But the latter depends on the substitution 

  @DEFN_LONG_LONG_LIMB@

which is skipped during the configure tests, but defined by configure
based on

  case $limb_chosen in
  longlong) DEFN_LONG_LONG_LIMB="#define _LONG_LONG_LIMB 1";;
  *)DEFN_LONG_LONG_LIMB="/* #undef _LONG_LONG_LIMB */" ;;
  esac
  AC_SUBST(DEFN_LONG_LONG_LIMB)

So not clear to me if/how GMP_LIMB_BITS is set correctly in a long long
configuration?

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: `checking size of mp_limb_t... 0` and `configure: error: Oops, mp_limb_t doesn't seem to work` when compiling the Microchip XC32 compiler from source

[Niels Möller]

"Gabriel Staples, ElectricRCAircraftGuy.com"  writes:

> In the answer <https://stackoverflow.com/a/77435216/4561887>, please jump
> halfway down, to the section titled "Explanation of the
> ${gcc_srcdir_RELATIVE}/configure relative path fix that works". I can
> neither explain it more nor less simply than that.

So actual error from your config.log is

  configure:27432: gcc -c -g -O2 -D__USE_MINGW_ACCESS -DNO_ASM 
-I/c/Users/gabriel/GS/dev/Microchip_XC32_Compiler/xc32-v4.35-src/pic32m-build/opt/include
 -imacros host-defs.h conftest.c >&5
  conftest.c:80:10: fatal error: 
/c/Users/gabriel/GS/dev/Microchip_XC32_Compiler/xc32-v4.35-src/pic32m-source/gcc/gmp/gmp-h.in:
 No such file or directory
 80 | #include 
"/c/Users/gabriel/GS/dev/Microchip_XC32_Compiler/xc32-v4.35-src/pic32m-source/gcc/gmp/gmp-h.in"
|

^~~~
  compilation terminated.

And that is from running gmp's configure script, not the configure
script of one of the other components your building? That looks rather
strange to me:

(1) I'm not used to autoconf putting absolute file names in #include
lines in conftest.c. At least, I have never noticed it doing that.

(2) It makes no sense for any C code, in conftest.c or otherwise, to
ever attempt to include gmp-h.in. That's not a valid C header file,
since it lacks the substitutions that turns it into a valid gmp.h
header file.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: `checking size of mp_limb_t... 0` and `configure: error: Oops, mp_limb_t doesn't seem to work` when compiling the Microchip XC32 compiler from source

[Niels Möller]

"Gabriel Staples, ElectricRCAircraftGuy.com"  writes:

> Thanks, Niels. I had been looking in config.log and came across a failure
> to include a file with an absolute path. I found the solution and wrote
> about it here: https://stackoverflow.com/a/77435216/4561887

I've had a quick look, but really too long for me to read carefully. And
please avoid calling other peoples work ugly things like "stinky". If
needed, please calm down before posting stuff.

Can you explain concisely in which way absolute include paths made gmp
configure break in your environment? It's not clear to me why gmp's
configure would ever attempt to compile anything with an #include
"/c/foo/bar.h" in it.

To me, use of absolute paths on the #include line seems rather obscure,
I'd expect relative paths, and compiler -I flags (often with absolute
paths) pointing to location of relevant include directories.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: `checking size of mp_limb_t... 0` and `configure: error: Oops, mp_limb_t doesn't seem to work` when compiling the Microchip XC32 compiler from source

[Niels Möller]

When debugging configure issues, the first step is to check config.log. That 
should tell you in detail what configure tried to compile or run, and how it 
failed.

Regards,
/Niels

"Gabriel Staples, ElectricRCAircraftGuy.com"  skrev: (3 
november 2023 08:26:03 CET)
>I could really use some help here. Many thanks in advance. I don't know if
>this is a GMP problem exactly, but I've described it pretty thoroughly
>here:
>
>GMP gets stuck in the configure process. Again, this may not be directly
>due to GMP, but this is a community effort to compile the GCC Microchip
>PIC32 compiler from source so we don't need to buy a license to program a
>chip.
>
>`checking size of mp_limb_t... 0` and `configure: error: Oops, mp_limb_t
>doesn't seem to work` when compiling the Microchip XC32 compiler from
>source  
>
>Sincerely,
>
>Gabriel Staples
>___
>gmp-bugs mailing list
>gmp-bugs@gmplib.org
>https://gmplib.org/mailman/listinfo/gmp-bugs
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Unsigned integer overflow in `toom_eval_pm2.c`

[Niels Möller]

marco.bodr...@tutanota.com writes:

> Would a comment "It returns 0 or ~0, depending on the sign of the result"
> added to all the mpn_toom_eval_ functions suffice?

Yes. It would be nice if there were some reasonable place to document
that only once, but don't know where that could be.

> 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.

If it's actually used as a mask in several places, I'm happy to leave as
is.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Unsigned integer overflow in `toom_eval_pm2.c`

[Niels Möller]

marco.bodr...@tutanota.com writes:

> 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.

Makes sense, I think.

As Vincent suggested, it would be good to document somewhere what the
convention is (values 0 or ~0). And maybe change to 0 and 1 convention,
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
boolean values elsewhere. But may need further changes, like to
abs_sub_add_n, also noted by Vincent.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Unsigned integer overflow in `toom_eval_pm2.c`

[Niels Möller]

Andrew Teylu  writes:

>> I am not sure the arithmetic on unsigned types is what clang is unhappy
>> about, though.  Perhaps it dislikes the xor with "neg", which is a
>> signed variable.

I can't say precisely what implicit conversions happen according to the
spec: Unsigned to signed is always well defined, but the other direction
only if the converted value fits. It may also depend on whether or not
mp_limb_t is larger than int.

Does it make any difference if you change the "1" constants to "1u" ?

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?

> 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.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Side-channel leakage in the mpz_powm_sec interface

[Niels Möller]

Hubert Kario  writes:

> On Friday, 25 August 2023 07:51:10 CEST, Niels Möller wrote:
>> And that's for all inputs? Nice.

> Well, not all, I mostly tested ones that had obvious patterns, like
> zero to power zero, 0xff to power 0xff, full word to power of 1, full
> word to power (mod-1), etc. All with 2048 bit operands.

Ah, I didn't mean for all possible input values, just all the input
*arguments*.

> If we're doing CRT, then the modulus isn't public either,

You're right, of course.

The leak I was thinking of was using plain binvert_limb on the least
significant limb of the modulo, which includes this table lookup on bits
7-1: https://gmplib.org/repo/gmp/file/tip/gmp-impl.h#l3378

I think older versions of mpn_sec_pown use to do that, and at the time, I
figured it was not a big problem. I'm not aware of any interesting
attacks on RSA where it helps to know just a few of the least
significant bits of the secret factors.

> I did test GnuTLS (and we have discovered an issue: CVE-2023-0361),
> but haven't found any side-channels related to numerical operations.
> AFAIK, that was fixed as a result of CVE-2018-16868, and GnuTLS is
> using only mpn interfaces throughout for RSA operations now.

Nice. Then I should have a look at how they do things if/when I rework
RSA in Nettle.

> Thus, I think it's more of a documentation issue than code issue:
> it will be much better to just say that mpz_powm_sec() is not usable for
> cryptographic purposes and to deprecate it.

Not sure if "unusable" is right, but besides that, I agree documenting
the problem, and discouraging usage, is reasonable action.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Side-channel leakage in the mpz_powm_sec interface

[Niels Möller]

Torbjörn Granlund  writes:

> We should probably exclude certain sec_ functions when not all sensitive
> functions are provided in asm, and thereby as a result of
> --disable-assembly?  We should in essence not provide C versions of
> e.g., mpn_sec_tabselect.

I would suggest testing of side channel silence. That's reasonably easy
to do on platforms supported by valgrind. We probably don't want to make
valgrind a hard requirement for make check, but we could recommend it.

> And we should perhaps provide a normalisation asm function for what
> Niels proposes here?

It's not quite clear to me how that is useful. It could make
mpz_powm_sec silent with respect to leading zero bits in the output, but
as soon as anything uses the resulting size field for accessing the
limbs, we'll leak the resulting size anyway.

> I think we should document mpz_powm_sec as somewhat problematic, but
> also fix it along the lines of Niels' proposal.  The right GMP level for
> side-channel sensitive application is clearly mpn; we should say that.

Agreed.

> We might want to be more cautions about what we promise also for mpn.
> It is not necessarily sufficient to do what we do here, i.e. perform the
> exact same instruction sequence an data reference sequence for any two
> n-bit operand sets.

If docs don't already say explicitly what kind of side channels we try
to silence, that should be made more clear. My understanding is that by
ensuring that same instruction sequence and same memory accesses, we
should silence leaks via timing and cache, but not leaks via any other
kind of data dependency in the hardware.

> Careful power measurements typically can fingerprint either or both
> operands of a bignum multiply. Therefore, additional layers of
> side-channel obfuscation is needed, like standard RSA message
> blinding, mod argument blinding, exponent blinding.

I know you've done more work on that recently, while I have no idea how
"mod argument blinding" works... To me physical side channels, like
consumed power in a circuit, seem too dependent both on hardware details
and on the kind of access the attacker can gain to the system. And
rather difficult to devise general and portable countermeasures. That
said, if GMP can provide advice and/or tools to do it, that's nice of
course.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Side-channel leakage in the mpz_powm_sec interface

[Niels Möller]

marco.bodr...@tutanota.com writes:

>> 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?

Yep.

> 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?

I was thinking that the typical next step would be converting to an
octet string, and to avoid leakage, it has to do that via some method
that ignores the size field and instead uses n (the size of the modulo).
Which works only assuming the new behavior.

Hmm, but for the use case of an RSA secret key operation, the next step
would be CRT reconstruction (since it's a standard performance
optimization to do powm separately for the two secret vectors p and q).
And then maybe unblinding. And then all of those operations must be done
using mpn functions and size n, not mpz.

So I'm leaning towards documenting this problem with mpz_powm_sec, and
recommending mpn_sec_powm for applications that need side-channel silence.

> A possible implementation of your 2-3 points (I didn't look at
> documentation) could be the following.

Looks rather neat! But I'm still not quite convinced that it is worth
doing.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Side-channel leakage in the mpz_powm_sec interface

[Niels Möller]

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.

2. Ensure that the implementation complies with (1) (probably easy, if
   array is written by a call to mpn_sec_powm).

3. Do the normalization, i.e., assignment of the size field, by
   side-channel silent logic iterating over all n limbs.

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?

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Side-channel leakage in the mpz_powm_sec interface

[Niels Möller]

Hubert Kario  writes:

> I was able to confirm that the low-level functions, like the mpn_sec_powm()
> function have no timing leakage with regards to operands or result
> (exactly like section 8.1 of the manual[2] states).

And that's for all inputs? Nice. (I think an earlier version used a
potentially leaking table lookup on the lowest few modulo bits, as the
first step in computing a partial inverse. Which is probably benign in
most use-cases, but still undesirable for a function claimed to be
side-channel silent).

> I wasn't able to do the same with regards to the mpz_powm_sec() function.
>
> Irrespective of how I initialised the used mpz_t objects, if the operands
> don't have high order words set, the timing of the operation is different.
> Thus I believe that if mpz_powm_sec() is used for RSA or Diffie-Hellman
> it would be vulnerable to the Bleichenbacher or Raccoon attacks
> respectively.

Is the main problem the normalization of the *output* of mpz_powm_sec?
For this class of attacks, my understanding is that the secret exponents
are fixed (when doing repeated operations on the secret key under
attack), while the modulo is public, and the base is under the control
of the attacker and hence already known to them.

> Did I miss the methods to ensure that the objects are not clamped, or
> should
> the mpz_powm_sec() interface be marked as _not_ secure for cryptographic
> purposes?

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).

Regarding Nettle (which uses GMP, and is used by GnuTLS): The RSA code
dates from the 1990s (it's one of the oldest algorithms in Nettle), and
has seen a series of incremental improvements over the years, but aiming
to not break api compatibility more than necessary. Most recently
side-channel-silent "decoding" in pkcs#1 RAS decryption. The current
interface is more complex than I'd like, with several variants of most
private key operations, which is a bit confusing.

It would be desirable to with a larger rework; it would be better to (i)
use byte strings, rather than mpz_t values, for the interface to
applications, and (ii) use only mpn-level GMP functions internally. And
I would recommend the same approach for any other implementation of RSA
on top of GMP.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Possibly an annoying test in configure

[Niels Möller]

Dennis Clarke  writes:

> With GMP ver 6.3.0 I run into the same sort of thing :
>
> conftest.c:2:10: error: a function declaration without a prototype is
> deprecated in all versions of C [-Werror,-Wstrict-prototypes]
> int main () { return 0; }
>  ^
>   void

The configure script is really not written to support running with
-Werror, and I suspect that fixing that properaly would be a rather
large undertaking. In particular to support it in combination with
arbitrary other warning options that might be enabled by users, like
-Wall, -Wextra or -pedantic.

Even supporting building the library itself with -Werror is rather
questionable, imo.

My view on -Werror is that it is useful for a maintainer that aims to
address certain warnings on certain compilers/platforms, and is prepared
to fix all resulting errors by code changes or tweaks of -Wno-foo
options.

I would *not* want to support -Werror as something to be used in general
by users, with arbitrary compiler versions, compile flag tweaks, etc.
It would be good to properly document support or lack thereof.

(Which doesn't mean that I'm against bug reports about fixing particular
warnings; making small code changes to avoid warings is often a good
thing, imo).

> int main () { return 0; }
> configure:7072: result: no
> configure:7310: error: could not find a working compiler, see
> config.log for details
>
>
> This is seen on FreeBSD 14.0 on a RISC-V machine ( the SiFive board )
> however I bet it happens just about anywhere if one goes with strict
> C99 CFLAGS.

My expectation is that if not using the -Werror option (or equivalent
for other compilers), the test is very widely portable in practice.

Since gmp doesn't support K C any longer, it would make some sense to
update GMP-specific tests to use proper prototypes, but as far as I'm
aware, many of the "standard" autoconf macros still intentionally skip
prototype declarations, e.g., to test for existence of a function that
may have slightly different prototype on different systems. So even
fixing all GMP-specific tests would likely not solve your problem (but
feel free to try that out, if you believe that would be useful).

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Outdated libtool creates trouble on macOS

[Niels Möller]

FX Coudert  writes:

> From the generated files, it seems OK: the only effect is a change in
> the position of some code. Still, it needs to be tested on Windows,
> and I don’t have access to such machines.

One option to get a kind of windows testing is to cross compile, 

 ./configure --host=x86_64-w64-mingw32

and run tests using wine. On debian, the cross compiler is in the
package "gcc-mingw-w64-x86-64-win32".

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: integer overflow in mini-gmp due to integer promotion

[Niels Möller]

Vincent Lefevre  writes:

> No problems when testing MPFR with MINI_GMP_LIMB_TYPE = long, int,
> short and char, with -m64 and with -m32.

Thanks for testing. I've now committed that change.

Regards,
/Niels
-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: integer overflow in mini-gmp due to integer promotion

[Niels Möller]

Vincent Lefevre  writes:

> On 2023-07-19 21:24:03 +0200, Niels Möller wrote:
>> I think that's needed, to be able to support any size of
>> MINI_GMP_LIMB_TYPE. Something like
>> 
>> #define umullo_limb(u, v) \
>>   (sizeof(mp_limb_t) >= sizeof(int)) ? (u)*(v) : (unsigned int)(u) * (v))
>> 
>> If I understand you correctly, the two multiplies in
>> gmp_udiv_qrnnd_preinv and gmp_udiv_qr_3by2 are the only places where we
>> need a mullo operation, i.e., producing the low limb of a limb product?
>
> These are the only ones that affect MPFR, but I haven't looked
> at the whole code.

Can you try out the attached patch?

Regards,
/Niels

diff -r 73d9ef70d14f mini-gmp/mini-gmp.c
--- a/mini-gmp/mini-gmp.c	Wed Jul 19 11:44:37 2023 +0200
+++ b/mini-gmp/mini-gmp.c	Wed Jul 19 21:54:11 2023 +0200
@@ -172,12 +172,19 @@
 }	\
   } while (0)
 
+/* If mp_limb_t is of size smaller than int, plain u*v implies
+   automatic promotion to *signed* int, and then multiply may overflow
+   and cause undefined behavior. Explicitly cast to unsigned int for
+   that case. */
+#define gmp_umullo_limb(u, v) \
+  ((sizeof(mp_limb_t) >= sizeof(int)) ? (u)*(v) : (unsigned int)(u) * (v))
+
 #define gmp_udiv_qrnnd_preinv(q, r, nh, nl, d, di)			\
   do {	\
 mp_limb_t _qh, _ql, _r, _mask;	\
 gmp_umul_ppmm (_qh, _ql, (nh), (di));\
 gmp_add_ss (_qh, _ql, _qh, _ql, (nh) + 1, (nl));		\
-_r = (nl) - _qh * (d);		\
+_r = (nl) - gmp_umullo_limb (_qh, (d));\
 _mask = -(mp_limb_t) (_r > _ql); /* both > and >= are OK */		\
 _qh += _mask;			\
 _r += _mask & (d);			\
@@ -198,7 +205,7 @@
 gmp_add_ss ((q), _q0, (q), _q0, (n2), (n1));			\
 	\
 /* Compute the two most significant limbs of n - q'd */		\
-(r1) = (n1) - (d1) * (q);		\
+(r1) = (n1) - gmp_umullo_limb ((d1), (q));\
 gmp_sub_ddmmss ((r1), (r0), (r1), (n0), (d1), (d0));		\
 gmp_umul_ppmm (_t1, _t0, (d0), (q));\
 gmp_sub_ddmmss ((r1), (r0), (r1), (r0), _t1, _t0);			\

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: integer overflow in mini-gmp due to integer promotion

[Niels Möller]

Vincent Lefevre  writes:

> ./configure --with-mini-gmp=/home/vlefevre/software/gmp/mini-gmp CC=gcc-13 
> CFLAGS="-O2 -fsanitize=undefined -fno-sanitize-recover 
> -DMINI_GMP_LIMB_TYPE=short"
>
> I get lots of failures in mini-gmp.c (I suspect that the errors were
> hidden by some optimization in GCC 12 and before).

Interesting. It seems rather undocumented what settings of
MINI_GMP_LIMB_TYPE are supported/tested. I can try to guess your
motivation for using such a small size, but can you give a bit more
context?

> For instance:
>
> cventin:...ftware/mpfr/tests> ./texceptions
> mini-gmp.c:993:7: runtime error: signed integer overflow: 46604 * 61440 
> cannot be represented in type 'int'

That looks like a problem, since we aim to stick to standard C.

> I suppose that the simplest solution would be to add a cast to
> unsigned long, so that the multiplication is done in this type (and
> the subtraction too as a consequence), as this should be the largest
> MINI_GMP_LIMB_TYPE size... hoping that the compiler will optimize.

I think it's desirable to support setting MINI_GMP_LIMB_TYPE to long
long (which would make sense, e.g., on 64-bit windows, where for some
historical reasons long is still only 32 bits). Unconditionally casting
to unsigned long would break that.
 
> Otherwise the sizes of the types could be checked like in
> gmp_umul_ppmm.

I think that's needed, to be able to support any size of
MINI_GMP_LIMB_TYPE. Something like

#define umullo_limb(u, v) \
  (sizeof(mp_limb_t) >= sizeof(int)) ? (u)*(v) : (unsigned int)(u) * (v))

If I understand you correctly, the two multiplies in
gmp_udiv_qrnnd_preinv and gmp_udiv_qr_3by2 are the only places where we
need a mullo operation, i.e., producing the low limb of a limb product?

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Miscompilation on arm64 with GCC LTO

[Niels Möller]

Sam James  writes:

> Note that Jannik identified the bad commit [0] as 18082:c5d0fcb06969 [4].
[...]
> [0] https://gmplib.org/list-archives/gmp-bugs/2020-December/004981.html
> [1] https://gmplib.org/list-archives/gmp-bugs/2023-January/005223.html
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109765
> [4] https://gmplib.org/repo/gmp/rev/c5d0fcb06969

It looks like that commit changes

  adrp  x1, approx_tab
  add   x1, x1, :lo12:approx_tab

to

  adrp  x1, :got:approx_tab
  ldr   x1, [x1, #:got_lo12:approx_tab]

and only when PIC is defined (via LEA_HI and LEA_LO m4 macros). I
haven't double checked what assembly files actually look like after
preprocessing, though.

And something similar for __gmp_binvert_limb_table.

But I have no clue about the arm64 abi. Is PIC defined in the failing
build, or should it be?

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: 6.2.1 Bus error

[Niels Möller]

guoyizh...@malacology.net writes:

> I already asked the upstream aberol. It states that GMP is being built
> through Cargo in order to use the gmp-mpfr-sys crate
> (https://crates.io/crates/gmp-mpfr-sys), which is a transitive
> dependency of Amberol.
>
>> ├─gmp-mpfr-sys
>> ├─rug
>> ├─srgb
>> ├─amberol
>
> What other upstream should I report? Arch Linux or Rust crate?

A rather complex setup, with lots of pieces with which I (and other GMP
developers, I guess) am not at all familiar. If you believe it really is
a GMP bug which we might be able to track down, please carefully follow
the instructions at https://gmplib.org/manual/Reporting-Bugs.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: issue with Microsoft compiler

[Niels Möller]

Marc Glisse  writes:

> I think changing it in public headers (gmp.h, gmpxx.h) is the
> important part, changing it in internal source files is less of an
> issue.

Good point. I got the impression that someone was building GMP with
-Werror. Getting this by just *using* gmp and including gmp.h is
a different setting with different tradeoffs.

It might make some sense to add something like

  #ifdef _MSC_VER
  # pragma warning(disable:4146)
  #endif

to the installed gmp.h, if that is deemed not too brittle (I don't know
how stable warning numbers are, or if there's some better way). I got
_MCS_VER from a quick look at
https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170

> To be fair, it is often not the user who enables /WX but the Visual
> Studio IDE that enables /SDL by default, which turns some warnings
> that Microsoft deems relevant to security into errors. And Microsoft's
> reply in bug reports is "disable this option if you don't like it".

Is the pragma a documented / recommended way to disable the warning?

The warning would make more sense to me if narrowed to cases where the
result is assigned/used in some signed context where it matters for the
result. E.g., if long is a larger size than int, warning for code like
below seems a lot more reasonable than warning for gmp's use case.

  #include 
  
  int main (int argc, char **argv) {
unsigned int x = 17;
signed long y = -x;
printf("y = %ld\n", y);
return 0;
  }

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: issue with Microsoft compiler

[Niels Möller]

Marc Glisse  writes:

> It is certainly possible to avoid the warning, either with a pragma or
> with different code, but until now, the policy has been to tell people
> to disable this non-sensical behavior in visual studio or use a better
> compiler. I don't have a strong opinion here.

My view is that GMP simply depends on the required semantics of the C
specification. And negating mp_limb_t values is something that's done in
lots of places. I'm not aware of any workaround that wouldn't result in
an annoying amount of clutter.

And in general, I'd say that whoever decides to add something like
-Werror (turn all warnings into compile errors) to the compiler flags
get's to deal with the work of suppressing any false positives.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in __gmp_replacement_vsnprintf

[Niels Möller]

Paul Zimmermann  writes:

> this bug report got no feedback so far:
>
> https://gmplib.org/list-archives/gmp-bugs/2022-October/005200.html
>
> Do the GMP developers acknowledge it?

I'm not so familiar with this part of GMP, but it looks like a bug to
me.

I would suggest first changing the ASSERT at
https://gmplib.org/repo/gmp/file/tip/printf/repl-vsnprintf.c#l355 to
ASSERT_ALWAYS; it seems rather dangerous to pass format specifiers we're
not understanding to the system's vsprintf. And to really fix this
issue, we'd also have to actually support hex floats with %a and %A.

Looks like the file was written by Kevin Ryde two decades ago. I wonder
if it's possible/reasonable to replace with gnulib's version? That's a
few thousand lines of rather non-trivial code, though:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/vasnprintf.c;h=ab11ad026ed1b5d224dd71a8c880a30d859339cb;hb=HEAD

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.2.1 core2 x86_64 assembler error "operands invalid for `movq'"

[Niels Möller]

Torbjörn Granlund  writes:

> Note that the movq instances the old assembler complains about here read
> from memory.  Using movd might yield surprises there.

Hmm, it wasn't clear to me fromt he error report exactly which
instructions it was complaining about, so I guessed this was one of
them:

https://gmplib.org/repo/gmp/file/tip/mpn/x86_64/core2/hamdist.asm#l194

  movq  %xmm0, %rax

For the memory accesses, e.g., 

  movq  (up), %xmm1

I agree changing those to movd sounds scary.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.2.1 core2 x86_64 assembler error "operands invalid for `movq'"

[Niels Möller]

Torbjörn Granlund  writes:

> This is not the same bug as we worked around for register-to-register
> copying on x86-32 some years ago.  It is not cleer what syntax this
> assembler might accept, and which also gives the right instruction (here
> and on non-prolematic hosts).

For reference, in nettle x86_64 code, there are a few places where I
write "movd" instead of "movq" for 64-bit moves between general 64-bit
registers and xmm registers, to work around build problems on macos.
E.g.,

umac-nh.s:  movd%xmm4, %rax
sha3-permute.s: movd%xmm15, %r9

Seems to work fine everywhere I've tested it, but I've not really
understood why "movd" could ever be used as mnemonic for that operation
(I also use it in other places for 32-bit moves). I guess there are some
historic reasons.

So would be useful to try if replacement movq --> movd

(i) solves the problem on (older) macos, and

(ii) produces identical object code on systems with more up-to-date
assemblers.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Reporting a gmp bug

[Niels Möller]

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
> overflow.

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'm afraid I don't understand the comment

/* Corresponds to a merit 14 prime_gap, which is rare. */
odds_in_composite_sieve = 5 * nbits;

Thanks for reporting.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mini-gmp mpz_powm incorrect result

[Niels Möller]

Marco Bodrato  writes:

>>> 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?

Committed, and I've verified that it fixes Guido's test case.
 
> 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.

> 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);

Adding 9 looks very arbitrary?

> +  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);

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.

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.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mini-gmp mpz_powm incorrect result

[Niels Möller]

Paul Zimmermann  writes:

> $ diff -u mini-gmp.c.orig mini-gmp.c
> --- mini-gmp.c.orig 2022-08-29 10:28:20.700995412 +0200
> +++ mini-gmp.c  2022-08-29 10:27:36.112191428 +0200
> @@ -3060,6 +3060,7 @@
>if (en == 0)
>  {
>mpz_set_ui (r, 1);
> +  mpz_tdiv_r (r, r, m);
>return;
>  }

Should solve the problem, but maybe a bit overkill to call mpz_tdiv_r. Perhaps

   mpz_set_ui (r, mpz_cmpabs_ui (m, 1) != 0);

or even (mn == 0 check just above this code rules out |m| < 1)

   mpz_set_ui (r, mpz_cmpabs_ui (m, 1));

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Using WSL2 to cross-compile from Linux to Windows

[Niels Möller]

johanneskauffm...@hotmail.com writes:

> A while back someone messaged about cross-compiling from Linux to Windows [1].
> That person had a problem with the GMP script detecting the wrong build
> compiler:

It looks like that particular message ([1]
https://gmplib.org/list-archives/gmp-bugs/2020-January/004715.html) was
mine.

> Below, I implemented the patch suggested in the referenced message, and it 
> works
> wonderfully.
>
>
> diff -r 58bb9b017366 acinclude.m4
> --- a/acinclude.m4  Sun May 29 18:08:56 2022 +0200
> +++ b/acinclude.m4  Sun Jun 12 23:34:56 2022 +0200
> @@ -3794,11 +3794,15 @@
> [CC_FOR_BUILD=$HOST_CC],
> [AC_MSG_ERROR([Specified HOST_CC doesn't seem to work])])
> else
> -  for i in "$CC" "$CC $CFLAGS $CPPFLAGS" cc gcc c89 c99; do
> -GMP_PROG_CC_FOR_BUILD_WORKS($i,
> -  [CC_FOR_BUILD=$i
> -   break])
> -  done
> +  if test $cross_compiling = no ; then
> +CC_FOR_BUILD="$CC"
> +  else
> +for i in cc gcc c89 c99; do
> +  GMP_PROG_CC_FOR_BUILD_WORKS($i,
> +[CC_FOR_BUILD=$i
> + break])
> +done
> +  fi
>if test -z "$CC_FOR_BUILD"; then
> AC_MSG_ERROR([Cannot find a build system compiler])
>fi

Still makes sense to me. Could perhaps keep $CC at the *end* of the list?

I'm a bit annoyed by the related problem, that it is not enough to pass
--host to get cross_compilation set properly. For some backwards
compatiblity reasons one has to explicitly pass --build as well, even
when config.guess figures out the build system type perfectly right.
Documented in some detail at
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#Hosts-and-Cross_002dCompilation

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

Torbjörn Granlund  writes:

> The language accepted by -Wall -Werror ain't C.  Unfortunately, GMP and
> its configure snippets are written in C.

I've always liked gcc -Wall. I think it adheres to its design to warn
only about things that (1) are prone to be errors, and (2) in the case
that they aren't errors, are easy to clarify in a way that makes the
compiler stop warning about them.

Use of -Werror, on the other hand, is something that I can't generally
recommend. Imposing it on library users by default is certainly a bad
idea. Using it when compiling tests that are part of configure is almost
sure to break.

But it could make sense to enable in certain nightly builds with known
compilers, if one has the ambition that the code should build without
(certain) warnings in that configuration, and stay that way.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

Paul Eggert  writes:

> Mattias Engdegård reported that the Emacs master source currently
> generates the following warning when Emacs is built with mini-gmp.c
> under Clang 13:

Probably not that compiler specific. Minimal example:

  #include 
  void foo(void) {int x = 1; assert(x);}

No warnings with gcc -Wall -c, but warns with gcc -Wall -DNDEBUG -c.

We currently don't use -Wall in gmp or mini-gmp Makefiles. And I suspect
no nightly builds try -DNDEBUG (since main gmp code doesn't use plain
assert, it's not that an interesting configuration). To do things
specifically for mini-gmp, I guess one could tweak the check-mini-gmp
make target, or the arguments passed to it in nightly builds.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

Vincent Lefevre  writes:

>> 1. Is the void cast really needed? Corresponding macros in gmp-impl.h
>> are defined like
>> 
>>   #if WANT_ASSERT
>>   #define ASSERT_CARRY(expr) ASSERT_ALWAYS ((expr) != 0)
>>   #define ASSERT_NOCARRY(expr)   ASSERT_ALWAYS ((expr) == 0)
>>   #else
>>   #define ASSERT_CARRY(expr) (expr)
>>   #define ASSERT_NOCARRY(expr)   (expr)
>>   #endif
>
> I'd say that a cast to void is better in order to ensure that
> ASSERT_CARRY(expr) and ASSERT_NOCARRY(expr) have type void
> whether WANT_ASSERT is defined or not, so that type issues
> could be detected more easily.

I see, it would matter for invalid use such as

mp_limb_t cy = ASSERT_NOCARRY(...);

Leaving unchanged for now.

>> Alternative patch:
>> 
>> --- a/mini-gmp/mini-gmp.cTue Feb 15 09:18:40 2022 +0100
>> +++ b/mini-gmp/mini-gmp.cFri Apr 15 07:20:40 2022 +0200
>> @@ -90,6 +90,7 @@ see https://www.gnu.org/licenses/.  */
>>  #define gmp_assert_nocarry(x) do { \
>>  mp_limb_t __cy = (x);  \
>>  assert (__cy == 0);\
>> +(void) __cy;   \
>>} while (0)
>
> I prefer this patch.

I pushed this version to the repo.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Can't install on Kali linux

[Niels Möller]

Adham Khalile Yousef  writes:

> First off, I don't really think that's a bug, so if I'm addressing the
> wrong staff a redirection would be appreciated :) .

I think the gmp-disc...@gmplib.org list is more appropriate for
installation and usage help.

> I'm unable to make anything with the Makefile.
> Steps:
> 1. Download latest gmp from official gmp site (gmp-6.2.1.tar.lz
> <https://gmplib.org/download/gmp/gmp-6.2.1.tar.lz>)
> 2. lzip then tar to extract; cd gmp<*>
> 3. sudo ./configure --enable-cxx --prefix=/usr

I can't say exactly what's going wrong, but except for make install, you
should *not* run configure and make as root (with sudo). Something like 

  ./configure --prefix=/usr
  make
  make check
  sudo make install

is expected to work, to install in a system directory like /usr.

> 4. make tries:
>  4.1 $> sudo make outputs: make: *** No targets specified and no
> makefile found.  Stop.

If there's no makefile, that sounds like the configure step failed.
Check if it produced any errors (and if it did, more details can be
found in config.log).

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

Paul Eggert  writes:

> Mattias Engdegård reported that the Emacs master source currently
> generates the following warning when Emacs is built with mini-gmp.c
> under Clang 13:
>
>> In file included from /Users/mattias/emacs/lib/mini-gmp-gnulib.c:47:
>> /Users/mattias/emacs/lib/mini-gmp.c:1138:2: warning: unused variable '__cy' 
>> [-Wunused-variable]
>> gmp_assert_nocarry (mpn_rshift (np, np, dn, shift));
>> ^
>> /Users/mattias/emacs/lib/mini-gmp.c:91:15: note: expanded from macro 
>> 'gmp_assert_nocarry'
>> mp_limb_t __cy = (x);  \
>
> The problem occurs because assert(X) does not evaluate X when NDEBUG
> is defined. Proposed patch attached.

Thanks for the report. I suspect builds with NDEBUG defined are not that
well tested.

> diff -r d45103d658ca mini-gmp/mini-gmp.c
> --- a/mini-gmp/mini-gmp.c Wed Mar 30 23:16:18 2022 +0200
> +++ b/mini-gmp/mini-gmp.c Fri Apr 08 16:18:06 2022 -0700
> @@ -87,10 +87,11 @@
>  #define GMP_MPN_OVERLAP_P(xp, xsize, yp, ysize)  
> \
>((xp) + (xsize) > (yp) && (yp) + (ysize) > (xp))
>  
> -#define gmp_assert_nocarry(x) do { \
> -mp_limb_t __cy = (x);   \
> -assert (__cy == 0); \
> -  } while (0)
> +#ifdef NDEBUG
> +# define gmp_assert_nocarry(x) ((void) (x))
> +#else
> +# define gmp_assert_nocarry(x) assert ((x) == 0)
> +#endif

I have two minor comments on this proposed fix:

1. Is the void cast really needed? Corresponding macros in gmp-impl.h
are defined like

  #if WANT_ASSERT
  #define ASSERT_CARRY(expr) ASSERT_ALWAYS ((expr) != 0)
  #define ASSERT_NOCARRY(expr)   ASSERT_ALWAYS ((expr) == 0)
  #else
  #define ASSERT_CARRY(expr) (expr)
  #define ASSERT_NOCARRY(expr)   (expr)
  #endif

I.e., in builds without run-time asserts, ASSERT_NO_CARRY(X) expands to
just (X).

2. I'm a bit uneasy about side effects in the argument to the standard
assert macro, even with the NDEBUG ifdefs.

Alternative patch:

--- a/mini-gmp/mini-gmp.c   Tue Feb 15 09:18:40 2022 +0100
+++ b/mini-gmp/mini-gmp.c   Fri Apr 15 07:20:40 2022 +0200
@@ -90,6 +90,7 @@ see https://www.gnu.org/licenses/.  */
 #define gmp_assert_nocarry(x) do { \
 mp_limb_t __cy = (x);     \
 assert (__cy == 0);   \
+(void) __cy;  \
   } while (0)

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

Paul Eggert  writes:

> In libgmp 6.2.1, mini-gmp.c defines a macro without using it, causing
> the command "gcc -Wunused-macros -Werror" to fail with the following
> diagnostic:

I haven't used -Wunused-macros before, I take it it warns only about
macros defined in .c files? Since it's perfectly normal that macros
defined in .h files are unused in some of the compilation units
including the .h file?

mini-gmp.c is a bit special, in that one more-or-less recommended
usecase is to #include this file into some other compilation unit. E.g.,
like in https://gmplib.org/repo/gmp/file/tip/bootstrap.c#l33.

But probably still shouln't define macros not used within mini-gmp.c;
any additional utility macros should probably go in mini-gmp.h, and be
compatible with public macros from gmp.h.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Errors making GMP621 on SCO Openserver 6.

[Niels Möller]

Torbjörn Granlund  writes:

> Marco Bodrato  writes:
>
>   ==> /tmp/config.guess.log <==
>   ./config.guess: syntax error at line 284: `(' unexpected
>
> Perhaps the $(command ...) syntax is not known by the old SCO shell?
> Really old /bin/sh only had `command ...`.

I take it this is gmp's config.guess (not the plain autoconf/gnulib
version, which is configfsf.guess in gmp)?

Autoconf is usually very careful about problems with old and obscure
variants of /bin/sh, but perhaps gmp's shell scripts are not.

I think the autoconf configure script has a CONFIG_SHELL environment,
maybe it would work better to install, e.g., bash, and set
CONFIG_SHELL=/usr/bin/bash (that's a feature I've never had to use)?

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: 2 minor issues on Windows

[Niels Möller]

George Woltman  writes:

> I've built the library (64-bit) using Cygwin.  This creates a DLL and a
> gmp.h file that can be used with Microsoft Visual Studio C compiler.
> As you probably know, MSVC strangely defines long as 32-bits.

Hi, looking through old mail, sorry for the late reply.

> In gmp.h, these lines appear:
>
> #ifdef __GMP_SHORT_LIMB
> typedef unsigned int mp_limb_t;
> typedef int mp_limb_signed_t;
> #else
> #ifdef _LONG_LONG_LIMB
> typedef unsigned long long int mp_limb_t;
> typedef long long int mp_limb_signed_t;
> #else
> typedef unsigned long int mp_limb_t;
> typedef long int mp_limb_signed_t;
> #endif
> #endif
> typedef unsigned long int mp_bitcnt_t;
>
> The problem is that while _LONG_LONG_LIMB is defined, the definition of
> mp_bitcnt_t ought to also use "long long".
> 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?

Do you also get a 32-bit mp_size_t ?

> 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)
> {
>   while (*__gmp_up == 0) /* Low zero limbs are unchanged by negation. */
> {
>   *__gmp_rp = 0;
>   if (!--__gmp_n) /* All zero */
> return 0;
>   ++__gmp_up; ++__gmp_rp;
> }
>
>   *__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
> unsigned

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 cornercases to work according to spec.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: macOS version detection broken in configure

[Niels Möller]

Marc Glisse  writes:

> From a quick look at the mailing list and the git repository, it seems
> to have been entirely unmaintained for more than 2 years now :-(

Ouch, not being much of a libtool user myself, I hadn't noticed that.

We could consider configuring shared libraries without libtool. That's
what I do in Nettle (which uses neither libtool nor automake), see
https://git.lysator.liu.se/nettle/nettle/-/blob/master/configure.ac#L761
It hasn't been that much hassle to maintain, but may well be inferior to
libtool in some ways.

Or are there any useful configure helpers in the gnulib package?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: 68000 issue in longlong.h

[Niels Möller]

"se...@t-online.de"  writes:

> There you see the original code on the left and the generated assembly in the 
> middle.
> You can add the & to
> "=d" (__umul_tmp1)
> in the left window and you see immediately the change in the comiled output.

Ok, let me see if I understand the problem. The inline asm for umul_ppmm
is as follows:

#define umul_ppmm(xh, xl, a, b) \
  do { USItype __umul_tmp1, __umul_tmp2;\
__asm__ ("| Inlined umul_ppmm\n"\
"   move%.l %5,%3\n"\
"   move%.l %2,%0\n"\
"   move%.w %3,%1\n"\
"   swap%3\n"   \
"   swap%0\n"   \
"   mulu%.w %2,%1\n"\
"   mulu%.w %3,%0\n"\
"   mulu%.w %2,%3\n"\
"   swap%2\n"   \
"   mulu%.w %5,%2\n"\
"   add%.l  %3,%2\n"\
"   jcc 1f\n"   \
"   add%.l  %#0x1,%0\n" \
"1: move%.l %2,%3\n"\
"   clr%.w  %2\n"   \
"   swap%2\n"   \
"   swap%3\n"   \
"   clr%.w  %3\n"   \
"   add%.l  %3,%1\n"\
"   addx%.l %2,%0\n"\
"   | End inlined umul_ppmm"\
  : "=" (xh), "=" (xl), \
"=d" (__umul_tmp1), "=" (__umul_tmp2) \
  : "%2" ((USItype)(a)), "d" ((USItype)(b)));   \
  } while (0)

There are two instructions mentioning the input %5,

  move%.l %5,%3   (first instruction)

  mulu%.w %5,%2   (close to the middle)

The %2 register is both an input and output, and referenced in a few
places in between. My m68k assembly knowledge is very rusty, most of
them may be harmless reads, but the "swap %2" instruction just before
the use of %5 looks like it relies on %2 and %5 being distinct
registers? In the linked-to compiler output (listed as gcc-6.5.0b, using
-O1), the template is instantiated as

| Inlined umul_ppmm
move.l  d5,d2
move.l  d5,d0
move.w  d2,d1
swapd2
swapd0
mulu.w  d5,d1
mulu.w  d2,d0
mulu.w  d5,d2
swapd5
mulu.w  d5,d5
add.l   d2,d5
jcc 1f
add.l   #0x1,d0
clr.w   d5
swapd5
swapd2
clr.w   d2
add.l   d2,d1
addx.l  d5,d0
| End inlined umul_ppmm

so it's quite clear that both %2 and %5 are mapped to the same register,
d5. Adding the suggested &, marking %2 as an "early clobber" output,
changes the instantiation to

| Inlined umul_ppmm
move.l  d5,d2
move.l  d6,d0
move.w  d2,d1
swapd2
swapd0
mulu.w  d6,d1
mulu.w  d2,d0
mulu.w  d6,d2
swapd6
mulu.w  d5,d6
add.l   d2,d6
jcc 1f
add.l   #0x1,d0
clr.w   d6
swapd6
swapd2
clr.w   d2
add.l   d2,d1
addx.l  d6,d0
| End inlined umul_ppmm

I.e., %2 gets its own register, d6. If my analysis is right, the
critical difference is

swapd5
mulu.w  d5,d5

vs

swapd6
mulu.w  d5,d6

I can't say for sure if using the same register for %2 and %5 is
expected behavior of gcc. But to me it seems reasonable of gcc to try to
share a register when an inline asm template is instantiated with
identical expressions for two of the inputs (as in the squaring
umul_ppmm(xh, xl, u, u). And the additional & seems to be the documented
way to tell it to not do that for this asm template.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: small patch to suppress a warning

[Niels Möller]

Stephan Pleines  writes:

> So what is the verdict in this patch please?

Adding the pair of parentheses makes the code slightly more readable to
me. But it would still be nice if you could say what the warninsg
message to be suppressed is, and which compiler and version produces that
warning.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP website: old release (3.1.1) cannot be downloaded

[Niels Möller]

"Peter Jin"  writes:

> 1. Go to https://gmplib.org/download/gmp/archive/
> 2. Try to download either "gmp-3.1.1.tar.bz2" or "gmp-3.1.1.tar.xz"
> 3. Response: HTTP/2 403 Forbidden (server: nginx/1.18.0, etc.)

Going to that directory listing page (I'm using firefox, no idea if it
attempts to use HTTP/2) and clicking those links works for me. Maybe
some temporary error? If problem persists, you'd need to share more
details on what tools you use to download.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP Problem with % under C++

[Niels Möller]

Miki Hermann  writes:

> The result of the command '22b-gmp < 22input.txt' is:
>
>*** b = 62010736820046
>f(1) - b = -15681174147849
>a = -15681174147849
>On position 2020 is the card 102220661749926

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,
so that (f(1) - b) / DECKSIZE == -1.

So your problem really is with % in C++, GMP just follows the
conventions for the builtin integers. I'm not even sure if rounding is
specified by the C++ standards, but rounding towards zero is what all C
and C++ implementations I'm aware of use.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: possible miscompilation on macOS Catalina 10.15.6

[Niels Möller]

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. It isn't miscompilation if the source
> statement is undefined.

As a general statement, that's hard to dispute. But previous experience
is that most problems like this boil down to compiler bugs, after
someone spends the time to investigate properly. 

And the compiler shipped with the initial release of MacOS "Catalina",
in particular, has known issues, if I don't misremember previous reports
on this list.

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.

GMP correctness depends on the compiler getting arithmetic right
including in edge cases not exercised by most applications, and it also
has a pretty thorough test suite that tends to detect compiler bugs.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: possible miscompilation on macOS Catalina 10.15.6

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> Trevor Spiteri  writes:
>
>   This is all the information I got; sorry if it is incomplete. (The
>   user's issue was solved by using their already installed homebrew?
>   libraries instead of compiling GMP anew.)
>
> OK, so *some* compiler compiled GMP with and *some* GMP test program
> reported a segfault.  I will right away start the natural deduction over
> all possible instances of compilers and GMP test cases. Oh wait, I need
> to consider all possible CPUs and relevant environment variables as
> well.

And to be a bit less sarcastic: Fairly recent Apple compilers have had
bugs making them miscompile GMP. Most likely explanation for the
reported problem is that your user has a buggy version of the compiler
installed. So try a different compiler. And if you suspect it's a
genuine GMP bug, please follow bug reporting instructions in the fine
manual.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Patch: support callback on allocation overflow instead of calling abort()

[Niels Möller]

Colin Caine  writes:

> Sorry, this patch was posted to this list last month, but I didn't see it
> in the archives. See here for related discussion:
> https://gmplib.org/list-archives/gmp-bugs/2020-September/004865.html

I asked some questions (some off list), and haven't seen satisfactory
answers. The thing is, it seems fairly safe to use the propsed callback
to write a friendly error message, backtrace of involved julia
functions, etc, and then exit the process.

But my impression is that julia may also longjmp out and continue
execution, and to me, that seems very brittle. You can have memory
leaks, you may leave GMP data structures in an inconsistent state.

To make any progress with adding a callback like this, we'd need to
either:

1. Find out and document how to longjmp out from the callback safely.

2. Agree and document that when GMP invokes this callback, GMP state
   should be considered invalid. The process must not make any further
   calls to any GMP functions.

And in the latter case, would that be satisfactory for Julia's use?

There are other approaches to avoid these crashes, e.g., I think the
recent emacs integration uses a (configurable) limit on bignum size, and
will raise an emacs exception long before hitting GMP's limits, and the
emacs process can go on running with no issues.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Hardcoded value of GMP_LIMB_BITS impedes bi-arch builds

[Niels Möller]

Jan Engelhardt  writes:

> When ./configure has run, the GMP_LIMB_BITS define in gmp.h is hardcoded 
> to 32 or 64, depending on arch. This makes it impossible to use that 
> header file for a x86_64-driven build with gcc -m32.

For what it's worth, debian multilib installs would have two separate
header files,

  /usr/include/x86_64-linux-gnu/gmp.h 
  /usr/include/i386-linux-gnu/gmp.h

belonging to different arch versions of the packages, libgmp-dev:amd64
and libgmp-dev:i386, respectively.

>   #define GMP_LIMB_BITS (sizeof(mp_limb_t) * CHAR_BIT)

As Torbjörn said, that doesn't work, since GMP_LIMB_BITS is expected to
be a constant known to the preprocessor, which is ignorant of C things
like types and sizeof. You'd need a gmp-h.in with something like

#ifdef @ALT_ARCH@
#define GMP_LIMB_BITS @ALT_GMP_LIMB_BITS@
#else
#define GMP_LIMB_BITS @GMP_LIMB_BITS@
#endif

and corresponding configure.ac setup. Not sure it's worth the effort,
since the multilib organization works fine, and works for *all*
libraries with arch-dependent headers.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

m4_error not working?

[Niels Möller]

Hi, I was looking at the m4 macrology in mpn/asm-defs.m4 (to borrow some
of it to Nettle). But the error machinery is not working the way I
expect. E.g., m4_length is defined using m4_assert_onearg(). But if I
try using it with an incorrect number of arguments, I get no error:

  $ echo 'm4_length(foo)' | m4 mpn/asm-defs.m4 -
  3
  $ echo 'm4_length(foo, bar)' | m4 mpn/asm-defs.m4 -
  3
  $ echo $?
  0

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

___
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

[Niels Möller]

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?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Niels Möller]

Paul Zimmermann  writes:

>Dear Niels,
>
>> The excluded case,
>> 
>>   sub_ddmmss(ah, al, bh, /*compile time constant*/0) 
>> 
>> could clearly be optimized, in a different way, but I'd guess it's rare
>> enough in real code to not be worth the effort?

Sorry for being unclear, sub_ddmmss has six arguments, and the case I
wanted to single out was

   sub_ddmmss(rh, rl, ah, al, bh, /*compile time constant*/0)
 
> in MPFR we have 15 places where we call sub_ddmmss, among which 8 have bl=0:

Those seem to have al == 0 (in above notation), which is a different
case.

  sub_ddmmss (rh, rl, ah, 0, bh, bl)

should be the same as

  rh = ah - bh - (bl > 0);
  rl = -bl;

So we have a borrow to propagate except of also bl == 0, and hence some
runtime carry logic is needed.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

>   >   {cout, r} = a + ~b + cin
>
>   This is a - b - borrow, where the borrow is the complement of the
>   carry bit.
>
> Niels' definition is important as it captures the similarity with
> addition.  It is indeed how the instructions are described in the vendor
> manuals.

And it's closer to the hardware, since this makes it clear that there's
only one stage of carry propagation (~b is a totally parallel bit-by-bit
inversion, while logic to constuct -b is slower and more complex), done
identically as for addition. Likely using something like
https://en.wikipedia.org/wiki/Kogge%E2%80%93Stone_adder.

Then, the ISA could of course complement the carry flag at input and
output, regardless of the rest of the hardware, like it's done on x86.
But I've found the ARM convention more convenient, e.g., when writing
wraparound code for special-form ECC-related primes.

And, which I guess is more relevant in the sub_ddmmss context, it also
means that there's little need for separate instructions for adding and
subtracting constants.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> The two - signs ought to be ~, I think.  Let me think a buit more about that.

If I remember ARM conventions correctly, subtract with carry is defined
as

  {cout, r} = a + ~b + cin

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: gmp 6.2.0 build failure in 32-bit mode on Linux/mips

[Niels Möller]

Bruno Haible  writes:

> I've read the first 10 lines of that chapter again, and I cannot see the
> solution of the adventure game through which you want to chase me.

Please set "ABI" on the configure command line. Adding ABI-changing
flags to CC causes confusion (even if it works fine with other packages,
and possibly for gmp too *if* configured with --disable-assembly). Don't
do that.

The relation between C and asm files is a bit intricate, and you have to
either leave ABI choice completely to configure, or tell it in the
documented way what you want.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Niels Möller]

Marc Glisse  writes:

> On Sat, 6 Jun 2020, Mihai Preda wrote:
>
>> I would rather suggest to support intmax_t and uintmax_t.
>
> That's one possibility for C (and C++, although it is a bit more
> painful there), but not one that everyone agrees with. I think the
> majority in standard committees believes that those 2 types were a
> mistake,

Any reference for such discussions?

> in particular because they are 64 bits on platforms that now
> have a 128 bit type, but cannot change intmax_t as that would break
> the ABI.

Isn't that exactly what happened to "long", long ago? Just like
intmax_t, long was supposed to be the platform's largest supported
integer type. Maybe we'll see a "long intmax_t" type when 128-bit types
become more established ;-)

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

tsurzin  writes:

> $ ./config.guess
> skylake-pc-msys

Hmm. You could try adding a pattern *-*-msys for the case

*-*-mingw* | *-*-cygwin)
  GMP_INCLUDE_MPN(x86_64/dos64.m4) ;;

around line 3800 in configure.ac (and then rerun autoconf and
configure).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.2 error

[Niels Möller]

Vincent Lefevre  writes:

> Seriously, I think that the default prefix is non-sense. But this is
> not a GMP issue either, rather an autoconf issue.

Consistency is nice too. I think it's old tradition to allow trusted
non-root users to install things under /usr/local. E.g., on Debian
GNU/Linux, if you're a member of the group "staff", you have sufficient
permissions for a default

  ./configure && make && make check && make install

install of gmp, or any other GNU package. As well as many non-GNU
packages, even some not using autoconf. And that's still how I install
more or less everything that I install from sources rather than from
binary packages.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Problem by compiling GMP 6.0.2 ....

[Niels Möller]

"Zhéxué M. Krawutschke [ Net.Admin & Sys.Admin ]"
 writes:

> Well, your information about „not clean“ is perfect, but I don‘t understand, 
> why?
> Because I had say „make clean“, before I compile it again for my „armv7l“ - 
> Node.

According to GNU standards, "make clean" generally deletes only files that
were created by running make. To delete things created by running
configure, you need to run "make distclean".

And I also highly recommend using a separate build directory for each
configuration.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpz_gcdext bug in mini-gmp

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> (I am not sure why MiniGMP uses the same internal field names as the
> full GMP.  Perhaps it should use different names to discourage
> non-complying code?)

I think the definition of mpz_t and struct __mpz_struct were simply
copied verbatim. Renaming fields and dropping leading underscores in
mini-gmp might make sense. But keeping them the same makes it easier to
copy code between gmp and mini-gmp, which also has benefits.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpz_gcdext bug in mini-gmp

[Niels Möller]

Syed Jafri  writes:

> https://github.com/jafri/gmp-bug

To make it easy to follow the example, I would suggest simplifying it to
something like

#include 
#include   /* or #include "mini-gmp.c" */

int main (int argc, char **argv) 
{
  mpz_t a, b, g, s;

  mpz_init_set_str(a, ...);
  mpz_init_set_str(b, ...);
  mpz_init (g);
  mpz_init (s);
  mpz_gcdext (g, s, NULL, a, b);
  gmp_printf ("g = %Zd, s = %Zd\n", g, s);
  return 0;
}

Never access internal fields of mpz_t directly. If for any reason (this
example has no good reason, as far as I see) one needs to use a limb
array as input, use mpz_roinit_n.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: error compiling gmp-6.2.0 on sparc-sun-solaris2.11 - v9os

[Niels Möller]

"Klaus Ziegler - owner of sunfreeware.de" 
writes:

> But now to my real problem, if I try to compile gmp-6.2.0 on v9os
> using Sun C 5.11,
> I'll get the following very long lines:
> gmp-6.2.0/gmpxx.h", line 3375: Error: static
> __gmp_expr<__mpz_struct[1], __mpz_struct[1]>::factorial(signed char),
> returning __gmp_expr<__mpz_struct[1], __gmp_unary_expr __gmp_fac_function>>, was previously declared returning
> __gmp_expr<__mpz_struct[1], __gmp_unary_expr __gmp_fac_function>>.

I'm afraid I've not familiar enough with C++ to undersnd the error, but
Sun C 5.11 must be a pretty old C++ compiler, right? Maybe it simply
doesn't understand current C++?

Do you really need the C++ glue to boostrap gmp and gcc? If not, try
configuring gmp with --disable-cxx.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: whitespace and grammar fixes for mini-gmp.c

[Niels Möller]

Paul Eggert  writes:

> When merging GNU MP 6.2.0 mini-gmp.c into GNU Emacs (which uses
> mini-gmp on platforms lacking libgmp), I noticed three trivial fixes
> that had been applied on the Emacs copy that would be useful to
> propagate upstream to GNU MP.

Thanks, applied. (And I don't think copyright assignment is needed for
these fixes).

I wasn't aware that emacs uses GMP or mini-gmp, cool!

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

Vincent Lefevre  writes:

> Under Debian/unstable, I've configured GMP with:
>
>   ./configure --host=i686-w64-mingw32 --disable-shared --enable-assert
>
> but "make check LOG_COMPILER=wine" gives:
>
> FAIL: t-printf
> ==
>
> snprntffuns.c:79: GNU MP assertion failed: strlen (d->buf) == avail-1
> FAIL t-printf.exe (exit status: 3)
>
> The failing code is
>
>   ret = vsnprintf (d->buf, avail, fmt, ap);
>   if (ret == -1)
> {
>   ASSERT (strlen (d->buf) == avail-1);
>   ret = avail-1;
> }

Does it make a difference if you add CPPFLAGS=-D__USE_MINGW_ANSI_STDIO
to the configuration?

> I don't understand the ASSERT. A return value of -1 means an output
> error, so that you cannnot deduce anything about the contents stored
> in d->buf.

Non-standard versions of snprintf returned -1 for truncation (including
old glibc, and likely windows libc too). And the way I read the ASSERT,
it says that truncation is the only expected reason for vsnprintf to
return -1. What was fmt? It would be helpful to understand the reason
for the -1 return in the failing case.

> /* Define to 1 if you have the `vsnprintf' function and it works properly. */
> #define HAVE_VSNPRINTF 1

I guess it's hard for configure to check for proper return value when cross
compiling.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: [SOLVED] Re: setting CPU_TYPE when cross-compiling from Linux to Windows

[Niels Möller]

Claude Heiland-Allen  writes:

> CC_FOR_BUILD is necessary otherwise the configure fails because it
> uses the wrong build system compiler:
[...]
> checking build system compiler x86_64-w64-mingw32-gcc... yes

Ah, candidates are

  for i in "$CC" "$CC $CFLAGS $CPPFLAGS" cc gcc c89 c99; do

(from acinclude.m4), whether cross compiling or not. In Nettle's
configure I instead do

  if test $cross_compiling = no ; then
CC_FOR_BUILD="$CC"  
  else
for i in gcc cc c89 c99; do
  ...

Would that make sense for gmp too?

And I've just pushed a change to delete the suggestion to use
TESTS_ENVIRONMENT to run wine.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: [SOLVED] Re: setting CPU_TYPE when cross-compiling from Linux to Windows

[Niels Möller]

Claude Heiland-Allen  writes:

> Aha, thanks for this tip, I found an incantation that works:
>
> ```
> CC=x86_64-w64-mingw32-gcc \
> CC_FOR_BUILD=x86_64-linux-gnu-gcc \
> CPPFLAGS=-D__USE_MINGW_ANSI_STDIO \
> LDFLAGS="-static-libgcc -static-libstdc++" \
> ./configure \
>   --build=x86_64-linux-gnu \
>   --host=x86_64-w64-mingw32 \
>   --enable-fat \
>   --enable-static \
>   --disable-shared \
>   --prefix=/home/claude/wintmp/
> ```
>
> The `CPPFLAGS` is necessary to avoid test failure in printf/scanf.

That's a known problem, maybe it should somehow be enabled by default by
gmp's configure, but I don't fully understand the implications.

Not sure why the setting of LDFLAGS and CC_FOR_BUILD are needed though,
can you explain?

Also, I think it's generally recomended to set CC and other variables
affecting configure as arguments to the configure script rather than in
the environment, i.e.,

  ./configure CC=... 

rather than

  CC=... ./configure

> I
> found that `make check` works (I have binfmt support enabled so wine
> is invoked automatically), but `make check TESTS_ENVIRONMENT=wine64`
> as suggested fails:
>
> ```
> make[5]: Entering directory '/home/claude/wintmp/src/gmp/tests'
> wine: Bad EXE format for Z:\bin\bash..

It seems that's a bad suggestion these days, thanks for reporting. I'm
fairly confident it used to work with some older version of automake,
before the current fancier test framework.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: setting CPU_TYPE when cross-compiling from Linux to Windows

[Niels Möller]

Claude Heiland-Allen  writes:

> However trying the method suggested in the documentation also fails,
> but in a different way:
>
> ```
> CC_FOR_BUILD="gcc" \
> CPP_FOR_BUILD="gcc -E" \
> CFLAGS="-march=native -O3 -fomit-frame-pointer" \
> CXXFLAGS="-march=native -O3 -fomit-frame-pointer" \
> LDFLAGS="-static-libgcc -static-libstdc++" \
> CPPFLAGS="-D__USE_MINGW_ANSI_STDIO" \
> ./configure --build=zen-pc-linux-gnu --host=zen-w64-mingw32 \
>   --prefix=/home/claude/winNATIVE
> ...
> config.status: linking mpn/x86_64/zen/gmp-mparam.h to gmp-mparam.h
> config.status: executing libtool commands
> configure: summary of build options:
>
>   Version:   GNU MP 6.1.99
>   Host type: zen-w64-mingw32
>   ABI:   64
>   Install prefix:    /home/claude/winNATIVE
>   Compiler:  gcc
>   Static libraries:  yes
>   Shared libraries:  no
>
> configure: If wine64 is installed, use make check TESTS_ENVIRONMENT=wine64.
> ```
>
> Notice it uses compiler `gcc` instead of `x86_64-w64-mingw32-gcc`,
> which leads to a build for Linux, not Windows.

Autoconf has a convenience feature to automatically pick a
cross-compiler based on the host triplet. But that works only if
cross-compiler name and host-triplet match perfectly. Otherwise, you
must specify the correct cross compiler explicitly, with
CC=x86_64-w64-mingw32-gcc.

> Trying a fat build (thanks for the pointer to this method, I think
> it's what I really need) also fails, at `make check`:

Can't say why this fails. If you have tried different configs in the
same build tree, try starting over from make distclean.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

"Damm, Stephen"  writes:

> I was able to narrow down the cause.  In GC 7.2.0 the GMP_LLIMB_MASK is wrong:
>
> =GCC 4.8.5=
> GMP_LIMB_BITS=64
> GMP_LLIMB_MASK=4294967295=0x
>
> =GCC 7.2.0=
> GMP_LIMB_BITS=64
> GMP_LLIMB_MASK=1=0x0001
>
> From my understanding this might be a difference in how GCC 7.2.0 handles 
> unsigned longs vs GCC 4.8.5.  It also could be I am missing some vital 
> compiler flag for GMP.

Can you file a gcc bug? These constants are defined as

#define GMP_LIMB_BITS (sizeof(mp_limb_t) * CHAR_BIT)/* 64, you say */

#define GMP_HLIMB_BIT ((mp_limb_t) 1 << (GMP_LIMB_BITS / 2))
#define GMP_LLIMB_MASK (GMP_HLIMB_BIT - 1)

I see no reasonable way that can end up defining GMP_LLIMB_MASK as 1.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
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

[Niels Möller]

Hans Åberg  writes:

> How about memory allocations? — There is info here, suggesting uninitialized 
> memory access in the test suite:
> https://lists.llvm.org/pipermail/cfe-users/2019-November/001640.html

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, but I can't look for
that at the moment.

Seems unrelated to the stack alignment issue, though.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in gmp_fprintf still in next release?

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> IIRC, the size field counts bytes for these functions.  The size in mpz
> counts limbs.

You're right. So then for positive numbers, mpz_out_raw can deal with
numbers of at most 2^34 - 8 bits. And negative numbers of at most 2^34
bits (absolute value). Which is smaller than the mpz_t limit.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in gmp_fprintf still in next release?

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> But we cannot make %* type arguments work, easily.  It will be limping
> unless we change int to size_t (or some such).

Another limit that was pointed out to me the other day is mpz_out_raw,
with a 32-bit length field (matching the current mpz_t limit, though).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: error on mpz_inits and mpz_clears

[Niels Möller]

Rabindra Moirangthem  writes:

> I have installed the gmp library on a centos system. When I compiled my c
> file, it gives errors only when I am using mpz_inits and mpz_clears in my
> program. Other functions compiled successfully.
> The errors given are:
> undefined reference to `__gmpz_inits'
> undefined reference to `__gmpz_clears'
>
> What seems to be the problem here?

Most likely, you are linking with a too old version of the gmp library.
Do you get this error at compile/link time, or at runtime/loadtime? In
the latter case, try running ldd on your executable, and will tell you
which libraries it loads.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Latest commit introduces undefined behavior in hgcd2.c

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> Or simply:
>
>   dh = (dh << dcnt) + (dl >> (GMP_LIMB_BITS - 1 - dcnt) >> 1);

Looks better, thanks.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Latest commit introduces undefined behavior in hgcd2.c

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> I think it is a false positive.  The result of the shifted value is
> masked when the shift count is not in range.

The line in question is

  dh = (dh << dcnt) + (-(dcnt > 0) & (dl >> (GMP_LIMB_BITS - dcnt)));

Should be fine if shift by 64 is "implementation defined", but a
problem, at least in theory, if it is "undefined behavior". I'm afraid I
don't know these fine details of the C spec by heart.

Is it reasonable to change it to

  #define LIMB_SHIFT_MASK (GMP_LIMB_BITS - 1)
  dh = (dh << dcnt) + (-(dcnt > 0) & (dl >> (LIMB_SHIFT_MASK & - dcnt)));

I'd expect compilers for common archs will generate the same code. It
depends on GMP_LIMB_BITS being a power of 2, though.

Vaguely related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157. But
unlike rotate, an extra masking step seems necessary.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Assembly routines break Windows 64-bit SEH

[Niels Möller]

"E. Madison Bray"  writes:

> This is because the assembly routines do not include the metadata that
> is necessary on 64-bit Windows [1] for stack unwinding to work
> properly during exception handling.

It would be a good start to document what's the bare minimum to get an
exception, like a null pointer dereference, to reliable cause a crash
saying what type of crash it was.

It somewhat surprising to me if stack-unwinding meta data is required
for non-recoverable exceptions. Say, you have an executable, and you
replace some part of the object code with random garbage data. It will
most likely crash in an unrecoverable way when you run it, and not carry
any consistent metadata. But it ought to be the operating system's
responsibility to report the failure, without assuming the executable is
particularly cooperative.

>  For example a
> `push_reg()` macro would emit (on Windows 64):
>
> push 
> .seh_pushreg 
>
> whereas on all other platforms it would just emit the plain `push
> ` instruction.  This part I believe is easy.

Sounds like reasonable approach, if we want to do this. But a bit
intrusive if there are lots of pushes.

> The trickiest part is just ensuring that some register is available to
> establish a frame pointer, when necessary (it doesn't necessarily have
> to be RBP; any nonvolatile register will do). 

We strive to not spend registers on frame pointers. I think most gmp
assembly functions are leaf functions. mpn_divrem_1 is an unusual case.
And the mpn_invert function it calls is unlikely to crash for any input;
I don't see any way it can crash, except if the object code is corrupted
or the relocation for mpn_invert_limb_table or the function itself is
somehow buggy and makes it point into nowhere.

I also wonder if any other architectures (ARM?) needs anything similar?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: gmp-6.1.2 Bug Report (gmp_fprintf(), "implicit declaration of function" warning)

[Niels Möller]

"mlg ."  writes:

> Long story short, with gcc, the function/macro "gmp_fprintf()" gives
> an"implicit declaration of function" warning. Please see the attached file
> for the complete report.

See
https://gmplib.org/manual/Headers-and-Libraries.html#Headers-and-Libraries.

: Note however that prototypes for GMP functions with FILE * parameters
: are only provided if  is included too. 

> #include 
> #include 

These two includes need to be in the opposite order.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: failure with Clang's memory sanitizer: use-of-uninitialized-value

[Niels Möller]

Marc Glisse  writes:

> Just recompiling GMP with CC='clang-7 -fsanitize=memory' (and
> --disable-shared) gives the more specific
>
> ==28897==WARNING: MemorySanitizer: use-of-uninitialized-value
> #0 0x498856 in mpn_bc_get_str /tmp/g/mpn/get_str.c:239:7

Looks like the branch on rp[1] here,

  ul = rp[1];  
  while (ul != 0)  // <---

rp[1] appears initialized with

  MPN_COPY (rp + 1, up, un);

A bit unobvious what MPN_COPY expands to, but possibly some assembly
that the clang analyzer can't reason about? Since the result of the
function is as expected, it seems unlikely that ul doesn't hold the
proper input value.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: configure sometimes misses passing LDFLAGS when testing linker

[Niels Möller]

Jameson Nash  writes:

> OK, here's take 2, where I use that approach instead. You're right, this
> seems to a bit more precise about which calls to the compiler are using the
> linker.

This patch to acinclude.m4 (quoted below) looks good to me. I'm not that
familiar with gmp's compiler tests, though. Torbjörn, do you agree this
is the right fix?

> --- gmp-6.1.2/acinclude.m42016-12-16 10:45:27.0 -0500
> +++ gmp-6.1.2-LDFLAGS/acinclude.m42019-03-26 13:08:01.328189815 -0400
> @@ -826,7 +826,7 @@ AC_DEFUN([GMP_PROG_CC_WORKS_PART_TEST],
>  [$3]
>  EOF
>echo "Test compile: [$2]" >_FD_CC
> -  gmp_compile="$1 conftest.c >_FD_CC"
> +  gmp_compile="$1 $LDFLAGS conftest.c >_FD_CC"
>if AC_TRY_EVAL(gmp_compile); then
>  cc_works_part=yes
>  if test "$cross_compiling" = no; then
> @@ -1147,7 +1147,7 @@ AC_DEFUN([GMP_GCC_NO_CPP_PRECOMP],
>cat >conftest.c <  int main () { return 0; }
>  EOF
> -  gmp_compile="$2 $3 -no-cpp-precomp conftest.c >conftest.out 2>&1"
> +  gmp_compile="$2 $3 $LDFLAGS -no-cpp-precomp conftest.c >conftest.out 2>&1"
>if AC_TRY_EVAL(gmp_compile); then
>  if grep "unrecognized option.*-no-cpp-precomp" conftest.out >/dev/null; 
> then : ;
>  else
> @@ -1328,7 +1328,7 @@ _main:
>   xorl%eax, %eax
>   ret
>  EOF
> -  gmp_compile="$1 conftest.s -o conftest >_FD_CC"
> +  gmp_compile="$1 $LDFLAGS conftest.s -o conftest >_FD_CC"
>if AC_TRY_EVAL(gmp_compile); then
>  if AC_TRY_COMMAND([./a.out || ./b.out || ./a.exe || ./a_out.exe || 
> ./conftest]); then
>gmp_cv_os_x86_xmm=yes
> @@ -1495,7 +1495,7 @@ AC_DEFUN([GMP_PROG_CXX_WORKS_PART],
>  int main (void) { return 0; }
>  EOF
>echo "Test compile: [$2]" >_FD_CC
> -  gmp_cxxcompile="$1 conftest.cc >_FD_CC"
> +  gmp_cxxcompile="$1 $LDFLAGS conftest.cc >_FD_CC"
>if AC_TRY_EVAL(gmp_cxxcompile); then
>  if test "$cross_compiling" = no; then
>if AC_TRY_COMMAND([./a.out || ./b.out || ./a.exe || ./a_out.exe || 
> ./conftest]); then :;
> @@ -2382,7 +2382,7 @@ for tmp_underscore in "" "_"; do
>  ${tmp_gsym_prefix}main$gmp_cv_asm_label_suffix
>   addl$ ${tmp_underscore}_GLOBAL_OFFSET_TABLE_, %ebx
>  EOF
> -  gmp_compile="$CCAS $CFLAGS $CPPFLAGS $lt_prog_compiler_pic conftest.s 
> >_FD_CC && $CC $CFLAGS $CPPFLAGS $lt_prog_compiler_pic conftest.$OBJEXT 
> >_FD_CC"
> +  gmp_compile="$CCAS $CFLAGS $CPPFLAGS $lt_prog_compiler_pic conftest.s 
> >_FD_CC && $CC $CFLAGS $CPPFLAGS $LDFLAGS $lt_prog_compiler_pic 
> conftest.$OBJEXT >_FD_CC"
>if AC_TRY_EVAL(gmp_compile); then
>  if test "$tmp_underscore" = "_"; then
>gmp_cv_asm_x86_got_underscore=yes
> @@ -3856,7 +3856,7 @@ main ()
>return 0;
>  }
>  EOF
> -gmp_compile="$1 conftest.c"
> +gmp_compile="$1 $LDFLAGS conftest.c"
>  cc_for_build_works=no
>  if AC_TRY_EVAL(gmp_compile); then
>if (./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest) >_FD_CC 
> 2>&1; then
> @@ -3931,7 +3931,7 @@ main ()
>  }
>  EOF
>  for i in .exe ,ff8 ""; do
> -  gmp_compile="$CC_FOR_BUILD conftest.c -o conftest$i"
> +  gmp_compile="$CC_FOR_BUILD $LDFLAGS conftest.c -o conftest$i"
>if AC_TRY_EVAL(gmp_compile); then
>  if (./conftest) 2>_FD_CC; then
>    gmp_cv_prog_exeext_for_build=$i
> @@ -3966,7 +3966,7 @@ main (int argc, char **argv)
>return 0;
>  }
>  EOF
> -gmp_compile="$CC_FOR_BUILD conftest.c"
> +gmp_compile="$CC_FOR_BUILD $LDFLAGS conftest.c"
>  if AC_TRY_EVAL(gmp_compile); then
>gmp_cv_c_for_build_ansi=yes
>  else
> @@ -4007,7 +4007,7 @@ foo ()
>return log (d);
>  }
>  EOF
> -gmp_compile="$CC_FOR_BUILD conftest.c -lm"
> +gmp_compile="$CC_FOR_BUILD $LDFLAGS conftest.c -lm"
>  if AC_TRY_EVAL(gmp_compile); then
>gmp_cv_check_libm_for_build=-lm
>  else

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: not really a bug .. is there a way to set the host type in the Makefile.am ?

[Niels Möller]

Dennis Clarke  writes:

> On 2/18/19 10:31 PM, Vincent Lefevre wrote:
>> It seems more likely to be an issue with the gcc build scripts.
>> I don't think that GMP and MPFR can or should do anything.
>
> Well said.  I just hope I can figure this out.

You'd first need to figure out how the gcc scripts set the gmp host
type. Is gmp's config.* involved in any way? If all else fails, you
could try hacking the configure script in the gmp tree, to hard code all
host-related variables and ignore whatever is passed in from outside.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: compilation fails with CompCert-3.4 on Linux x86-64; patch proposed

[Niels Möller]

Vincent Lefevre  writes:

> The code given by the autoconf manual is:
>
>   #ifdef STDC_HEADERS
>   # include 
>   # include 
>   #else
>   # ifdef HAVE_STDLIB_H
>   #  include 
>   # endif
>   #endif
>   #ifdef HAVE_ALLOCA_H
>   # include 
>   #elif !defined alloca
>   # ifdef __GNUC__
>   #  define alloca __builtin_alloca
>   # elif defined _AIX
>   #  define alloca __alloca
>   # elif defined _MSC_VER
>   #  include 
>   #  define alloca _alloca
>   # elif !defined HAVE_ALLOCA
>   #  ifdef  __cplusplus
>   extern "C"
>   #  endif
>   void *alloca (size_t);
>   # endif
>   #endif

The last case, declaring alloca, is that expecting that a replacement
alloca.c is used as a fallback? As far as I see, we don't do that in
gmp.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
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)

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> Let's move on.  No bug to be found here.

Just FYI: There was a bug in Nettle's test code, a line

  assert (mpz_invert(key->d, pub->e, phi));

Obviously not working with -DNDEBUG. Fix in commit
https://git.lysator.liu.se/nettle/nettle/commit/73d3c6d5586cc0fd81eab081078144d621de07b4

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mini-gmp: error: no previous prototype for 'mpz_lucas_mod'

[Niels Möller]

"Marco Bodrato"  writes:

> The wrapper you propose is more elegant than the workaround I used.
> I removed the _TESTING definition and pushed it:
>
> https://gmplib.org/repo/gmp/rev/14649658a790

Thanks!

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
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)

[Niels Möller]

Vincent Lefevre  writes:

> If you
> don't like that, you can write a wrapper library that will sanitize
> all the inputs and implement error processing (e.g. where the return
> value contains an error code and the result, if any), and call this
> library instead of GMP.

Regarding invalid inputs, in the GMP sources, validity checks on
function inputs generally use the ASSERT macro, which is disabled by
default. Non-assert validity checks with a return value are used only
when the check is non-trivial, e.g., for the mpz_invert function which
requires arguments to be co-prime. All easy validity checks (null
pointers, divide by zero, and the like) are left as the responsibility
of the application.

In a few places, GMP sources use ASSERT_ALWAYS. This is for internal
consistency checks, or when deveolopers believe a condition is
arithmetically impossible, but really would like to get a bug report if
that belief turns out to be wrong.

The assert that Jeffrey has hit is in sec_powm.c, 

  ASSERT_ALWAYS (enb >= windowsize);

As far as I can see, "enb" is the input argument to the win_size function,
and "windowsize" is the return value. I'm waiting for more information,
since it works fine in my build. Possible explanations I see are

1. Invalid configuration of POWM_SEC_TABLE (used by the win_size function).

2. Some general memory-overwrite problem, due to too small scratch
   space or something like that.

I interpret this ASSERT_ALWAYS as a way to check that POWM_SEC_TABLE is
sane.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
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)

[Niels Möller]

Jeffrey Walton  writes:

> The GMP library uses asserts to crash a program at runtime when
> presented with data it did not expect. The library also ignores user
> requests to remove asserts using Posix's -DNDEBUG. Posix asserts are a
> deugging aide intended for developement, and using them in production
> software ranges from questionable to insecure.

Crashing in a controlled fashion may also be *more* secure that
continuing execution with undefined results. Depending on circumstances,
of course.

I read the general statement "asserts considered harmful" as your
personal opionion, likely based on experience with very different
development projects than I'm involved with. And gmp-bugs isn't really
the right place for that debate (and neither is the nettle mailinglist).

> Second, the SIGABRT terminates the process and can write a core file.

A security sensitive application can easily disable generation of core
files, using setrlimit (on the linux kernel, prctl may also be useful).
That's all part of crashing in a *controlled* fashion on assertion
failures. As far as I'm aware, disabling core dumps is a fairly common
practice in security sensitive applications.

(And besides, most systems have zero ulimit -c as the system default
these days. Which makes sense to me (any application might handle data
that is sensitive to the user), even though as a developer, it's
annoying with extra hoops required to get proper core dumps, including
disabling the core dump collection "services" you mention).

And as Vincent says, there are many ways to crash due to bugs, without
triggering any assertion failure. And you should avoid generating core
dumps for those crashes too.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: [ADMIN] Foul language and swearwords

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> We have rejected a couple of messages sent to this list on a recent
> subject because they contained profanity.
>
> Keeping a reasonably civil tone is required on these mailing list.

One might also want to refer to the recently published
https://www.gnu.org/philosophy/kind-communication.html

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mini-gmp: error: no previous prototype for 'mpz_lucas_mod'

[Niels Möller]

Vincent Lefevre  writes:

> I get the following error when compiling mini-gmp.c:
>
> mini-gmp.c:3486:1: error: no previous prototype for 'mpz_lucas_mod' 
> [-Werror=missing-prototypes]
>  3486 | mpz_lucas_mod (mpz_t V, mpz_t Qk, long Q,
>   | ^
>
> Indeed, mini-gmp.c exports mpz_lucas_mod:
>
> int
> mpz_lucas_mod (mpz_t V, mpz_t Qk, long Q,
>mp_bitcnt_t b0, const mpz_t n)
> {
> [...]
> }
>
> but it is not declared in mini-gmp.h.

Hi, a late reply on this issue. It seems the current workaround is to
have a check for __MIN_GMP_TESTING in mini-gmp.c, and a prototype in
t-lucm.c.

A different way to do it is to add a wrapper in testutils.c (which
*includes* mini-gmp.c, in order to get access to internals), and a
prototype for that wrapper in testutils.h. Then nothing special is
needed in mini-gmp.c itself.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Likely GMP bug

[Niels Möller]

"Marco Bodrato"  writes:

> ... the effect is that in many cases (if U don't need reduction modulo V)
> the trailing zeros of U are removed twice.

But you may be right that it's important for performance to avoid a
redundant count_trailing_zeros on u.

It seems tricky to avoid that, without code duplication or complications
in the code flow. For my personal preference, tradeoff threshold between
goto and duplicated code is around 5-10 duplicated code lines.

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
should compile to three instructions (assuming we have a ctz
instruction), ctz + shift + shift, or ctz + add + shift. But with the
first variant, the first shift can be issued in parallel with ctz,
reducing the critical path of the gcd loop.

We'd need some benchmarking to see if it makes a difference.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Likely GMP bug

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> For now, I'd suggest to just rip out USE_ZEROTAB.

I've pushed a change to do just that. For making the rest of the file
clearer, I'd suggest the below (complete file, I think that's more
readable than the diff). I've also ripped out the GCD_1_METHOD==1 code,
since it appears to be disabled everywhere. Let me know if anyone has
any interest in keeping that around.

The last part of the function requires vlimb odd, but tolerates
arbitrary u, including 0. This would be a candidate gcd_11 or
gcd_11_odd. If it's made it's own function, the live zero_bits variable
prevents it from being a tail call, but maybe that's not a big deal.

I haven't done any benchmarks, and I'm not able to do any tonight.

Regards,
/Niels

/* mpn_gcd_1 -- mpn and limb greatest common divisor.

Copyright 1994, 1996, 2000, 2001, 2009, 2012 Free Software Foundation, Inc.

This file is part of the GNU MP Library.

The GNU MP Library is free software; you can redistribute it and/or modify
it under the terms of either:

  * the GNU Lesser General Public License as published by the Free
Software Foundation; either version 3 of the License, or (at your
option) any later version.

or

  * the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any
later version.

or both in parallel, as here.

The GNU MP Library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received copies of the GNU General Public License and the
GNU Lesser General Public License along with the GNU MP Library.  If not,
see https://www.gnu.org/licenses/.  */

#include "gmp-impl.h"
#include "longlong.h"

/* Does not work for U == 0 or V == 0.  It would be tough to make it work for
   V == 0 since gcd(x,0) = x, and U does not generally fit in an mp_limb_t.

   The threshold for doing u%v when size==1 will vary by CPU according to
   the speed of a division and the code generated for the main loop.  Any
   tuning for this is left to a CPU specific implementation.  */

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);
}
  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;

}

  ASSERT (vlimb & 1);
  if (ulimb == 0)
return vlimb << zero_bits;

  count_trailing_zeros (c, ulimb);
  /* Note that if ulimb == GMP_LIMB_HIGHBIT, c+1 is an invalid shift count. */
  ulimb >>= c;

  /* 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. */
  ulimb >>= 1;
  vlimb >>= 1;

  while (ulimb != vlimb)
{
  mp_limb_t t;
  mp_limb_t vgtu;

  t = ulimb - vlimb;
  vgtu = LIMB_HIGHBIT_TO_MASK (t);

  /* v <-- min (u, v) */
  vlimb += (vgtu & t);

  /* u <-- |u - v| */
  ulimb = (t ^ vgtu) - vgtu;

  count_trailing_zeros (c, t);
  ASSERT (c + 1 < GMP_LIMB_BITS);
      ulimb >>= (c + 1);
}

  vlimb = (vlimb << 1) | 1;
  return vlimb << zero_bits;
}





-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Likely GMP bug

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> It really worries me that our crazy broad testing did not catch this
> until now.  This makes me much less confident about GMP's correctness,
> actually.

Here we have a bug where assumptions made by the code are violated, with
a pretty low probability given random inputs. And which results in an
actual miscomputation with *even* lower probability.

So found thanks to ubsan, not the testcode's validation of the result.

It's good to use ASSERTs to document assumptions made, even if an
ASSERT (c <= GMP_LIMB_BITS - 2) was missing in this case.

I think another contributing factor is that gcd_1 does two different
things: The tight loop to compute gcd of two words, and somewhat hairy
logic to reduce larger numbers before entering the loop. If we had gcd_1
doing the reduction and then calling a gcd_11 (ulimb, vlimb) to do the
remaining work, where the latter function has a well defined interface
with its own tests, it had been harder and less tempting to do the
obscure thing.

> Replacement code should not jump into loops.  This bug (but not the
> shortcoming of the test suite) should teach us that lesson.

goto has its uses, but this case with multiple target labels is more
like the infamous COME FROM... https://en.wikipedia.org/wiki/COMEFROM

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Likely GMP bug

[Niels Möller]

"Marco Bodrato" <bodr...@mail.dm.unipi.it> writes:

> Il Ven, 25 Maggio 2018 2:10 pm, Niels Möller ha scritto:
>> That fails with undefined behavior if by chance t == 2^31, so that c ==
>> 31.
>>
>> I don't see how that can happen, though, since ulimb, vlimb < 2^31
>> through out the loop, and t = (ulimb - vlimb) mod 2^32.
>
> ... but can jump inside the loop ...
>
> That's the culprit:
>
>   if (size > 1)
> {
>   ulimb = MPN_MOD_OR_MODEXACT_1_ODD (up, size, vlimb);
>   goto strip_u_maybe;
> }

Ah, that's subtle! Thank's for tracking it down. Do you know if it
results in a miscomputation on the typical (32-bit) machines where (x >>
32) == x?

> diff -r a2b594f11916 mpn/generic/gcd_1.c
> --- a/mpn/generic/gcd_1.c   Sun May 13 16:13:42 2018 +0200
> +++ b/mpn/generic/gcd_1.c   Sat May 26 09:29:41 2018 +0200
> @@ -83,8 +83,13 @@
> }
>
>ulimb = MPN_MOD_OR_MODEXACT_1_ODD (up, size, vlimb);
> -  if (ulimb == 0)
> -   goto done;
> +  ASSERT_ALWAYS (POW2_P (0));
> +  if (POW2_P (ulimb))
> +   {
> + if (ulimb != 0)
> +   vlimb = 1;
> + goto done;
> +   }
>
>goto strip_u_maybe;
>  }

Alternatively, change only the branch that have this problem,
something like this (untested):

*** /tmp/extdiff.B7tg0s/gmp.aab8a010d10f/mpn/generic/gcd_1.c
2018-05-26 10:42:48.367993924 +0200
--- /home/nisse/hack/gmp/mpn/generic/gcd_1.c2018-05-26
10:42:42.89642 +0200
*** mpn_gcd_1 (mp_srcptr up, mp_size_t size,
*** 180,185 
{
strip_u_maybe:
  vlimb >>= 1;
! t = ulimb;
}
count_trailing_zeros (c, t);
--- 180,189 
{
strip_u_maybe:
+ count_trailing_zeros (c, ulimb);
  vlimb >>= 1;
! ulimb >>= 1;
!     /* c+1 is not always a valid shift count. */
! ulimb >>= c;
! continue;
}
count_trailing_zeros (c, t);

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs