Re: major formatted output function bug with %c and the value 0

[Vincent Lefevre]

On 2024-03-25 18:13:22 +0100, marco.bodr...@tutanota.com wrote:
> Vincent, you did not confirm that this code worked for you, but I
> pushed it anyway.
> https://gmplib.org/repo/gmp/rev/4ac76064639e

Thanks. I'll look at it when I have some time.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: major formatted output function bug with %c and the value 0

[marco . bodrato]

Ciao,

18 feb 2024, 12:29 da marco.bodr...@tutanota.com:

> 15 dic 2023, 13:26 da vinc...@vinc17.net:
>
>> Note that there are similar issues in printf/repl-vsnprintf.c, and I
>>
>
> I finally had the time to examine the code and test it. I attach a proposed 
> patch.
>
Vincent, you did not confirm that this code worked for you, but I pushed it 
anyway.
https://gmplib.org/repo/gmp/rev/4ac76064639e

Thanks.
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: major formatted output function bug with %c and the value 0

[marco . bodrato]

Ciao Vincent,

15 dic 2023, 13:26 da vinc...@vinc17.net:

> Note that there are similar issues in printf/repl-vsnprintf.c, and I
>

I finally had the time to examine the code and test it. I attach a proposed 
patch.

I changed the 3 files: printf/doprntf.c, printf/repl-vsnprintf.c, 
printf/sprintffuns.c, to use the returned value of the called functions, 
instead of calling strlen on the string.

I also slightly changed the tests, to check at least one case with "%c", 0.
For this to work I also had to change a
-  (*__gmp_free_func) (got, strlen(got)+1);
+  (*__gmp_free_func) (got, got_len+1);
When the string comes from a generic print, it is safer to relay on the return 
value than on the length computed by strlen()...


> think that this is the cause of the MPFR failure with MS Visual C++
> (vsnprintf is used by gmp_vasprintf).
>
If you can also test on that side, let me know. Thanks!

Gis,
m

diff -r 1c566525476a printf/doprntf.c
--- a/printf/doprntf.c	Wed Dec 27 19:35:36 2023 +0100
+++ b/printf/doprntf.c	Sun Feb 18 12:17:18 2024 +0100
@@ -267,8 +267,7 @@
 	 mean truncation */
   ASSERT (explen >= 0 && explen < sizeof(exponent)-1);
 #else
-  sprintf (exponent, p->expfmt, expsign, expval);
-  explen = strlen (exponent);
+  explen = sprintf (exponent, p->expfmt, expsign, expval);
   ASSERT (explen < sizeof(exponent));
 #endif
   TRACE (printf ("  expfmt %s gives %s\n", p->expfmt, exponent));
diff -r 1c566525476a printf/repl-vsnprintf.c
--- a/printf/repl-vsnprintf.c	Wed Dec 27 19:35:36 2023 +0100
+++ b/printf/repl-vsnprintf.c	Sun Feb 18 12:17:18 2024 +0100
@@ -364,16 +364,14 @@
 
   if (total_width <= buf_size)
 {
-  vsprintf (buf, orig_fmt, orig_ap);
-  len = strlen (buf);
+  len = vsprintf (buf, orig_fmt, orig_ap);
 }
   else
 {
   char  *s;
 
   s = __GMP_ALLOCATE_FUNC_TYPE (total_width, char);
-  vsprintf (s, orig_fmt, orig_ap);
-  len = strlen (s);
+  len = vsprintf (s, orig_fmt, orig_ap);
   if (buf_size != 0)
 	{
 	  size_t  copylen = MIN (len, buf_size-1);
diff -r 1c566525476a printf/sprintffuns.c
--- a/printf/sprintffuns.c	Wed Dec 27 19:35:36 2023 +0100
+++ b/printf/sprintffuns.c	Sun Feb 18 12:17:18 2024 +0100
@@ -53,9 +53,9 @@
 {
   char  *buf = *bufp;
   int   ret;
-  vsprintf (buf, fmt, ap);
-  ret = strlen (buf);
-  *bufp = buf + ret;
+  ret = vsprintf (buf, fmt, ap);
+  if (ret > 0)
+*bufp = buf + ret;
   return ret;
 }
 
diff -r 1c566525476a tests/misc/t-printf.c
--- a/tests/misc/t-printf.c	Wed Dec 27 19:35:36 2023 +0100
+++ b/tests/misc/t-printf.c	Sun Feb 18 12:17:18 2024 +0100
@@ -128,12 +128,11 @@
 }
 
 void
-check_vsprintf (const char *want, const char *fmt, va_list ap)
+check_vsprintf (const char *want, int want_len, const char *fmt, va_list ap)
 {
   char  got[MAX_OUTPUT];
-  int   got_len, want_len;
+  int   got_len;
 
-  want_len = strlen (want);
   got_len = gmp_vsprintf (got, fmt, ap);
 
   if (got_len != want_len || strcmp (got, want) != 0)
@@ -149,14 +148,12 @@
 }
 
 void
-check_vfprintf (const char *want, const char *fmt, va_list ap)
+check_vfprintf (const char *want, int want_len, const char *fmt, va_list ap)
 {
   char  got[MAX_OUTPUT];
-  int   got_len, want_len, fread_len;
+  int   got_len, fread_len;
   long  ftell_len;
 
-  want_len = strlen (want);
-
   rewind (check_vfprintf_fp);
   got_len = gmp_vfprintf (check_vfprintf_fp, fmt, ap);
   ASSERT_ALWAYS (got_len != -1);
@@ -187,14 +184,12 @@
 }
 
 void
-check_vsnprintf (const char *want, const char *fmt, va_list ap)
+check_vsnprintf (const char *want, int want_len, const char *fmt, va_list ap)
 {
   chargot[MAX_OUTPUT+1];
-  int ret, got_len, want_len;
+  int ret, got_len;
   size_t  bufsize;
 
-  want_len = strlen (want);
-
   bufsize = -1;
   for (;;)
 {
@@ -243,12 +238,11 @@
 }
 
 void
-check_vasprintf (const char *want, const char *fmt, va_list ap)
+check_vasprintf (const char *want, int want_len, const char *fmt, va_list ap)
 {
   char  *got;
-  int   got_len, want_len;
+  int   got_len;
 
-  want_len = strlen (want);
   got_len = gmp_vasprintf (, fmt, ap);
 
   if (got_len != want_len || strcmp (got, want) != 0)
@@ -261,19 +255,17 @@
   printf ("  want_len %d\n", want_len);
   abort ();
 }
-  (*__gmp_free_func) (got, strlen(got)+1);
+  (*__gmp_free_func) (got, got_len+1);
 }
 
 void
-check_obstack_vprintf (const char *want, const char *fmt, va_list ap)
+check_obstack_vprintf (const char *want, int want_len, const char *fmt, va_list ap)
 {
 #if HAVE_OBSTACK_VPRINTF
   struct obstack  ob;
-  int   got_len, want_len, ob_len;
+  int   got_len, ob_len;
   char  *got;
 
-  want_len = strlen (want);
-
   obstack_init ();
   got_len = gmp_obstack_vprintf (, fmt, ap);
   got = (char *) obstack_base ();
@@ -300,15 +292,30 @@
 void
 check_one (const char *want, const char *fmt, ...)
 {
+  int want_len = strlen (want);
   va_list ap;
   va_start (ap, fmt);
 
   /* simplest first */
-  check_vsprintf (want, fmt, ap);
-  

Uodate on "make check" fail bug reported by me on 29 November 2023 -- works on M3 iMac

[Jay Freeman]

On 29 November 2023 I reported a bug with the title: "GMP 6.3.0 fails "make 
check" on Mac Pro 2019 (Intel) running macOS Ventura 13.6.1".

I can now report that GMP 6.3.0 passed "make check" with no errors after 
downloading, configuring, and installing on a 2023 24-inch iMac (Apple Silicon 
M3), running macOS Sonoma 14.2. That is the same sequence of commands that led 
to the failure originally reported.

I have not yet updated my Intel Macintosh to Sonoma: When I do, I will repeat 
the attempt to install and check, and report what happens.

--  Jay Reynolds Freeman
-
jay_reynolds_free...@mac.com
http://JayReynoldsFreeman.com (personal web site)

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: major formatted output function bug with %c and the value 0

[Vincent Lefevre]

Hi,

On 2023-12-13 20:03:13 +0100, marco.bodr...@tutanota.com wrote:
> It was changed in 2001, probably a workaround, because the comment was
> "Don't use sprintf return value (it's a pointer on SunOS 4)"
> https://gmplib.org/repo/gmp/rev/0889877bb94a

Note that there are similar issues in printf/repl-vsnprintf.c, and I
think that this is the cause of the MPFR failure with MS Visual C++
(vsnprintf is used by gmp_vasprintf).

This file was added on 26 Oct 2001, thus 2 months after 0889877bb94a.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: major formatted output function bug with %c and the value 0

[marco . bodrato]

Ciao,

13 dic 2023, 15:53 da vinc...@vinc17.net:

> On 2023-12-03 20:19:10 +0100, Vincent Lefevre wrote:
>
>> With GMP 6.3.0, the formatted output functions do not handle %c
>> with the value 0 correctly. For gmp_sprintf, the return value is
>> incorrect.
>>
> In printf/sprintffuns.c, function gmp_sprintf_format(), I suppose that
>
>  vsprintf (buf, fmt, ap);
>  ret = strlen (buf);
>
> should actually be something like
>
>  ret = vsprintf (buf, fmt, ap);
>  if (ret < 0)
>  ret = 0;
>
> to avoid issues due to non-terminating null characters (not tested).
>
It was changed in 2001, probably a workaround, because the comment was
"Don't use sprintf return   value (it's a pointer on SunOS 4)"
https://gmplib.org/repo/gmp/rev/0889877bb94a

Maybe we should simply "revert" that change, and use the return value both from 
sprintf (in printf/doprntf.c) and from vsprintf (in printf/sprintffuns.c)?

Or, if we care not to modify the pointer bufp, we can use something like the 
following:
diff -r f6073853d16a printf/sprintffuns.c
--- a/printf/sprintffuns.c  Mon Oct 16 08:16:06 2023 +0200
+++ b/printf/sprintffuns.c  Wed Dec 13 19:53:50 2023 +0100
@@ -53,9 +53,9 @@
{
   char  *buf = *bufp;
   int   ret;
-  vsprintf (buf, fmt, ap);
-  ret = strlen (buf);
-  *bufp = buf + ret;
+  ret = vsprintf (buf, fmt, ap);
+  if (ret > 0)
+    *bufp = buf + ret;
   return ret;
}
 
It passes the test suite, but I didn't really think about what it does.

Ĝis,
mb
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: major formatted output function bug with %c and the value 0

[Vincent Lefevre]

On 2023-12-03 20:19:10 +0100, Vincent Lefevre wrote:
> With GMP 6.3.0, the formatted output functions do not handle %c
> with the value 0 correctly. For gmp_sprintf, the return value is
> incorrect.

In printf/sprintffuns.c, function gmp_sprintf_format(), I suppose that

  vsprintf (buf, fmt, ap);
  ret = strlen (buf);

should actually be something like

  ret = vsprintf (buf, fmt, ap);
  if (ret < 0)
ret = 0;

to avoid issues due to non-terminating null characters (not tested).

But I'm wondering how an error is possibly detected. The comment is:

/* If vsprintf returns -1 then pass it upwards.  It doesn't matter that
   "*bufp" is ruined in this case, since gmp_doprint will bail out
   immediately anyway.  */

> For gmp_asprintf and gmp_vasprintf, this is either a buffer overflow
> (according to the GMP manual: "The block will be the size of the
> string and null-terminator.") or, in case this is an error in the
> GMP manual, possible memory corruption when freeing the allocated
> memory, if the custom memory allocation function cares about the
> size parameter.

This should be checked and the GMP manual should be fixed.

> 
> Testcase for gmp_sprintf:
> 
> 
> #include 
> #include 
> 
> static void test (int flag)
> {
>   char s[3] = { 1, 1, 1 };
>   int r;
> 
>   r = (flag ? sprintf : gmp_sprintf) (s, "%c", 0);
>   printf ("%4s: r = %d, s = { %d %d %d }\n",
>   flag ? "libc" : "gmp", r, s[0], s[1], s[2]);
> }
> 
> int main (void)
> {
>   test (0);
>   test (1);
>   return 0;
> }
> 
> 
> which currently gives:
> 
>  gmp: r = 0, s = { 0 0 1 }
> libc: r = 1, s = { 0 0 1 }
> 
> MPFR has various issues concerning %c with the value 0, but an
> attempt to fix them fails due to
> 
>   length = gmp_vasprintf (...);
> [...]
>   mpfr_free_str (s);
> 
> which is similar to GMP's tests/misc/t-printf.c file, which contains
> 
>   got_len = gmp_vasprintf (, fmt, ap);
> [...]
>   (*__gmp_free_func) (got, strlen(got)+1);
> 
> But replacing
> 
>   mpfr_free_str (s);
> 
> by
> 
>   mpfr_free_func (s, length + 1);
> 
> i.e. using the return value length instead of strlen(s), also fails.
> I suppose that this is related to the incorrect return value.

Well, the failure was due to another mpfr_free_func, no longer this
one (I've now completely fixed MPFR, I think).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

major formatted output function bug with %c and the value 0

[Vincent Lefevre]

With GMP 6.3.0, the formatted output functions do not handle %c
with the value 0 correctly. For gmp_sprintf, the return value is
incorrect. For gmp_asprintf and gmp_vasprintf, this is either a
buffer overflow (according to the GMP manual: "The block will be
the size of the string and null-terminator.") or, in case this
is an error in the GMP manual, possible memory corruption when
freeing the allocated memory, if the custom memory allocation
function cares about the size parameter.

Testcase for gmp_sprintf:


#include 
#include 

static void test (int flag)
{
  char s[3] = { 1, 1, 1 };
  int r;

  r = (flag ? sprintf : gmp_sprintf) (s, "%c", 0);
  printf ("%4s: r = %d, s = { %d %d %d }\n",
  flag ? "libc" : "gmp", r, s[0], s[1], s[2]);
}

int main (void)
{
  test (0);
  test (1);
  return 0;
}


which currently gives:

 gmp: r = 0, s = { 0 0 1 }
libc: r = 1, s = { 0 0 1 }

MPFR has various issues concerning %c with the value 0, but an
attempt to fix them fails due to

  length = gmp_vasprintf (...);
[...]
  mpfr_free_str (s);

which is similar to GMP's tests/misc/t-printf.c file, which contains

  got_len = gmp_vasprintf (, fmt, ap);
[...]
  (*__gmp_free_func) (got, strlen(got)+1);

But replacing

  mpfr_free_str (s);

by

  mpfr_free_func (s, length + 1);

i.e. using the return value length instead of strlen(s), also fails.
I suppose that this is related to the incorrect return value.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[Brett Kuntz]

I have dug deeper into understanding what happens with both versions (method 1 
& 2). 

If the divisor has a high bit set, then pre[2] is not initialized inside 
mpn_mod_1_1p_cps(), but it is also not used inside mpn_mod_1_1p() as there are 
no leading zeroes. 

In the other scenario, if the high bit is set, pre[2] is set to its appropriate 
value, and it is used inside mpn_mod_1_1p(). 

Some commenting could be placed inside /mpn/generic/mod_1.c around lines 248 
and 261, or pre[4] can be initialized to all 0's on both 248 & 261: mp_limb_t 
pre[4] = { 0 }; 

-Brett Kuntz 


From: "Vincent Lefevre"  
To: "marco bodrato"  
Cc: "Brett Kuntz" , gmp-bugs@gmplib.org 
Sent: Thursday, August 31, 2023 11:06:51 AM 
Subject: Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c 

On 2023-08-31 17:03:12 +0200, marco.bodr...@tutanota.com wrote: 
> Ciao, 
> 
> 31 ago 2023, 16:30 da ku...@shaw.ca: 
> 
> > 1) Edit line 248 mpn/generic/mp_limb_t pre[4]; into: 
> > 
> ~/src/gmp$ hg diff mpn/generic/ 
> diff -r 3ac5afa36be5 mpn/generic/mod_1.c 
> --- a/mpn/generic/mod_1.c Wed Nov 02 13:48:37 2022 +0100 
> +++ b/mpn/generic/mod_1.c Thu Aug 31 16:46:35 2023 +0200 
> @@ -245,7 +245,7 @@ 
> } 
> else 
> { 
> - mp_limb_t pre[4]; 
> + mp_limb_t pre[4] = {-1, -1, -1, -1}; 
> mpn_mod_1_1p_cps (pre, b); 
> return mpn_mod_1_1p (ap, n, b, pre); 
> } 
> 

I don't think that this is sufficient for the test. 
The code Brett mentioned is for MOD_1_1P_METHOD = 2. 
So, in mpn/generic/mod_1_1.c, I also changed 

# define MOD_1_1P_METHOD 1 /* need to make sure this is 2 for asm testing */ 

to 

# define MOD_1_1P_METHOD 2 /* need to make sure this is 2 for asm testing */ 

and at the beginning of 

mpn_mod_1_1p (mp_srcptr ap, mp_size_t n, mp_limb_t b, const mp_limb_t bmodb[4]) 

I added 

ASSERT (bmodb[2] != -1); 

(if bmodb[2] is not set, this would fail). 

Then I configured with 

./configure --disable-assembly --enable-assert 

to enable the code and the assert, then "make" and "make check". 

But even with that, I don't get any failure. 

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/> 
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) 
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[Brett Kuntz]

> Looking at mpn/generic/mod_1_1.c, 
> if MOD_1_1P_METHOD == 1, the value[2] in the array is always set and always 
> used; 
> if MOD_1_1P_METHOD == 2, the value[2] is set only if cnt!=0, and it is used 
> only if cnt!=0. 
> There are also some assembler code implementations, each one with its couple 
> of functions. 

I concluded the same just now. 

-Brett Kuntz 


From: "marco bodrato"  
To: "Vincent Lefevre"  
Cc: "Brett Kuntz" , gmp-bugs@gmplib.org 
Sent: Thursday, August 31, 2023 12:33:46 PM 
Subject: Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c 

Ciao, 

31 ago 2023, 18:06 da vinc...@vinc17.net: 



I don't think that this is sufficient for the test. 
The code Brett mentioned is for MOD_1_1P_METHOD = 2. 




The code Brett mentioned is mixed, I fear. 
Looking at mpn/generic/mod_1_1.c, 
if MOD_1_1P_METHOD == 1, the value[2] in the array is always set and always 
used; 
if MOD_1_1P_METHOD == 2, the value[2] is set only if cnt!=0, and it is used 
only if cnt!=0. 
There are also some assembler code implementations, each one with its couple of 
functions. 


BQ_BEGIN

So, in mpn/generic/mod_1_1.c, I also changed 
# define MOD_1_1P_METHOD 1 /* need to make sure this is 2 for asm testing */ 

BQ_END


Not enough, MOD_1_1P_METHOD may be defined by gmp-mparam.h 
One should also check how MOD_1N_TO_MOD_1_1_THRESHOLD interact with the tests. 

BQ_BEGIN

ASSERT (bmodb[2] != -1); 

BQ_END



BQ_BEGIN

But even with that, I don't get any failure. 

BQ_END

Actually it is possible to trigger this, if you put it in the wrong place, I 
mean, outside the branch actually using the value... but it is not interesting. 

Ĝis, 
Marco 

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[marco . bodrato]

Ciao,

31 ago 2023, 18:06 da vinc...@vinc17.net:

> I don't think that this is sufficient for the test.
> The code Brett mentioned is for MOD_1_1P_METHOD = 2.
>

The code Brett mentioned is mixed, I fear.
Looking at mpn/generic/mod_1_1.c,if MOD_1_1P_METHOD == 1, the value[2] in the 
array is always set and always used;
if MOD_1_1P_METHOD == 2, the value[2] is set only if cnt!=0, and it is used 
only if cnt!=0.
There are also some assembler code implementations, each one with its couple of 
functions.


> So, in mpn/generic/mod_1_1.c, I also changed
> # define MOD_1_1P_METHOD 1/* need to make sure this is 2 for asm testing 
> */
>

Not enough, MOD_1_1P_METHOD may be defined by gmp-mparam.h
One should also check how MOD_1N_TO_MOD_1_1_THRESHOLD interact with the tests.

> ASSERT (bmodb[2] != -1);
>


> But even with that, I don't get any failure.
>
Actually it is possible to trigger this, if you put it in the wrong place, I 
mean, outside the branch actually using the value... but it is not interesting.

Ĝis,
Marco
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[Vincent Lefevre]

On 2023-08-31 17:03:12 +0200, marco.bodr...@tutanota.com wrote:
> Ciao,
> 
> 31 ago 2023, 16:30 da ku...@shaw.ca:
> 
> > 1) Edit line 248 mpn/generic/mp_limb_t pre[4]; into:
> >
> ~/src/gmp$ hg diff mpn/generic/
> diff -r 3ac5afa36be5 mpn/generic/mod_1.c
> --- a/mpn/generic/mod_1.c   Wed Nov 02 13:48:37 2022 +0100
> +++ b/mpn/generic/mod_1.c   Thu Aug 31 16:46:35 2023 +0200
> @@ -245,7 +245,7 @@
>     }
>    else
>     {
> - mp_limb_t pre[4];
> + mp_limb_t pre[4] = {-1, -1, -1, -1};
>   mpn_mod_1_1p_cps (pre, b);
>   return mpn_mod_1_1p (ap, n, b, pre);
>     }
> 

I don't think that this is sufficient for the test.
The code Brett mentioned is for MOD_1_1P_METHOD = 2.
So, in mpn/generic/mod_1_1.c, I also changed

# define MOD_1_1P_METHOD 1/* need to make sure this is 2 for asm testing */

to

# define MOD_1_1P_METHOD 2/* need to make sure this is 2 for asm testing */

and at the beginning of

mpn_mod_1_1p (mp_srcptr ap, mp_size_t n, mp_limb_t b, const mp_limb_t bmodb[4])

I added

  ASSERT (bmodb[2] != -1);

(if bmodb[2] is not set, this would fail).

Then I configured with

  ./configure --disable-assembly --enable-assert

to enable the code and the assert, then "make" and "make check".

But even with that, I don't get any failure.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[marco . bodrato]

Ciao,

31 ago 2023, 16:30 da ku...@shaw.ca:

> 1) Edit line 248 mpn/generic/mp_limb_t pre[4]; into:
>
~/src/gmp$ hg diff mpn/generic/
diff -r 3ac5afa36be5 mpn/generic/mod_1.c
--- a/mpn/generic/mod_1.c   Wed Nov 02 13:48:37 2022 +0100
+++ b/mpn/generic/mod_1.c   Thu Aug 31 16:46:35 2023 +0200
@@ -245,7 +245,7 @@
    }
   else
    {
- mp_limb_t pre[4];
+ mp_limb_t pre[4] = {-1, -1, -1, -1};
  mpn_mod_1_1p_cps (pre, b);
  return mpn_mod_1_1p (ap, n, b, pre);
    }


> 2) Recompile GMP.
>
~/src/gmp$ mkdir testbuild; (cd testbuild/;../configure&) >/dev/null


> 3) Use the mpn_mod_1() function as described on the following page and you 
> will now get incorrect results:
>
~/src/gmp$ (cd testbuild/;make TESTS="t-mod_1" check -C tests/mpn; )|tail -n 15
PASS: t-mod_1

Testsuite summary for GNU MP 6.2.99

# TOTAL: 1
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Even the modified library passes the tests.

Sorry, I'm not able to reproduce your bug report, not even with an arbitrarily 
modified source code.

~/src/gmp$ hg revert mpn/generic/
sto ripristinando mpn/generic/mod_1.c

I'd say that when the limb you are looking at is not initialized, then a 
function not using it is called.

I'd suggest: when reading mpn/generic/mod_1_1.c, pay attention to #if and 
#endif .

Ĝis,
Marco
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[Torbjörn Granlund]

Brett Kuntz  writes:

  Go to line 248 inside mpn/generic/mod_1.c 

  mp_limb_t pre[4]; 

There is no such thing on an unedited version of GMP 6.3, not on line
248 not anyplace else in that file.

  mpn_mod_1_1p_cps (pre, b); 

  Only initializes pre[0], pre[1], and pre[3]. ***NOT*** pre[2]. 

Your point?

  The final line: 

  return mpn_mod_1_1p (ap, n, b, pre); 

  Reads from pre[2] erroneously and gives incorrect results if your
  stack memory has anything other than a 0 there.

That line does not read any elements from pre[].  You have misunderstood
the semantics of C.

  But if you actually claim that an unedited GMP has a bug here, please 
  construct a test case which uses documented interfaces, and which 
  demonstrates the claimed bug. 

  1) Edit line 248 mpn/generic/mp_limb_t pre[4]; into: 

There is no file with that name.

  mp_limb_t pre[4] = { -1, -1, -1, -1 }; 

  2) Recompile GMP. 

  3) Use the mpn_mod_1() function as described on the following page and
  you will now get incorrect results:

It is clear that you have not tried that yourself.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[Brett Kuntz]

> It does not exist, only pre[0] through pre[3] does. 

pre[4] **IS** pre[0] through pre[3] 

Go to line 248 inside mpn/generic/mod_1.c 

mp_limb_t pre[4]; 

That is NOT initialized. 

The next line: 

mpn_mod_1_1p_cps (pre, b); 

Only initializes pre[0], pre[1], and pre[3]. ***NOT*** pre[2]. 

The final line: 

return mpn_mod_1_1p (ap, n, b, pre); 

Reads from pre[2] erroneously and gives incorrect results if your stack memory 
has anything other than a 0 there. 

> But if you actually claim that an unedited GMP has a bug here, please 
construct a test case which uses documented interfaces, and which 
demonstrates the claimed bug. 

1) Edit line 248 mpn/generic/mp_limb_t pre[4]; into: 

mp_limb_t pre[4] = { -1, -1, -1, -1 }; 

2) Recompile GMP. 

3) Use the mpn_mod_1() function as described on the following page and you will 
now get incorrect results: 

https://gmplib.org/manual/Low_002dlevel-Functions 

-Brett Kuntz 




From: "Torbjörn Granlund"  
To: "Brett Kuntz"  
Cc: gmp-bugs@gmplib.org 
Sent: Thursday, August 31, 2023 3:40:47 AM 
Subject: Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c 

Brett Kuntz  writes: 

Take a look at function mpn_mod_1() in /mpn/generic/ mod_1.c on lines 248 - 250 

mp_limb_t pre[4]; 
mpn_mod_1_1p_cps (pre, b); 

mp_limb_t pre[4] is not initialized 

It does not exist, only pre[0] through pre[3] does. 

and the mpn_mod_1_1p_cps() function 
never writes to pre[2]. So if we change that to mp_limb_t pre[4] = { -1, 
-1, -1, -1 }; as a test we'll quickly see that inside mpn_mod_1_1p_cps() 
the value cps[2] (pre[2]) is never written to and if we print out pre[4] 
after running it we'll get output like: 0x21CFE6CFC938B36BU, 
0xU, 0xU, 0x9581CA13918612E1U (pre[2] is 
-1) 

/mpn/generic/mod_1_1.c lines 260-266: 

if (LIKELY (cnt != 0)) 
{ 
mp_limb_t B1modb = -b; 
B1modb *= ((bi >> (GMP_LIMB_BITS-cnt)) | (CNST_LIMB(1) << cnt)); 
ASSERT (B1modb <= b); /* NB: not fully reduced mod b */ 
cps[2] = B1modb >> cnt; 
} 

cnt will ALWAYS equal 0 since there will be NO leading 0's when this is 
called since /mpn/generic/mod_1_1.c checks for the high bit being SET 
before calling.. which means this function only ever gets called with NO 
leading zeros!!! 

Why are you so worked up? 

The logic seems perfectly fine. 

ALSO there are unexplained differences between MOD_1_1P_METHOD 1 and 
MOD_1_1P_METHOD 2 when it comes to the function mpn_mod_1_1p_cps(). In 
one of them pre[4] is always set and in the other (method 2) pre[2] is 
skipped! Why are these two functions different? It looks like their job 
is to calculate the inverses for the following mod functions so one 
would expect them to be the same. 

There are lots of "unexplained" things in the GMP internal functions. 
But trust me, the GMP developers understand the sources. 

ALSO the x64 assembly versions of these codes also does not always set 
all 4 values of pre[4] and this has lead to incorrect results when using 
the exported function mpn_mod_1(). 

You hypothesise things here. And you're wrong. 

I benevolent reading of your claims here is that things will be bad if 
you use one variant of the internal _cps function with another variant 
of the corresponding internal mod function. If that's what you're 
trying to say, then you're right. GMP is not edit proof, local user 
edits might break it in all sorts of ways, 

But if you actually claim that an unedited GMP has a bug here, please 
construct a test case which uses documented interfaces, and which 
demonstrates the claimed bug. 

I do not understand these functions enough 

Shouting from the top of your lungs about a bug which is just the result 
of reading the sources, without allowing yourself time to understand the 
logic fully, is somewhat unfair. 

-- 
Torbjörn 
Please encrypt, key id 0xC8601622 
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[Torbjörn Granlund]

Brett Kuntz  writes:

  Take a look at function mpn_mod_1() in /mpn/generic/ mod_1.c on lines 248 - 
250

  mp_limb_t pre[4];
  mpn_mod_1_1p_cps (pre, b);

  mp_limb_t pre[4] is not initialized

It does not exist, only pre[0] through pre[3] does.

  and the mpn_mod_1_1p_cps() function
  never writes to pre[2]. So if we change that to mp_limb_t pre[4] = { -1,
  -1, -1, -1 }; as a test we'll quickly see that inside mpn_mod_1_1p_cps()
  the value cps[2] (pre[2]) is never written to and if we print out pre[4]
  after running it we'll get output like: 0x21CFE6CFC938B36BU,
  0xU, 0xU, 0x9581CA13918612E1U (pre[2] is
  -1)

  /mpn/generic/mod_1_1.c lines 260-266:

if (LIKELY (cnt != 0))
  {
mp_limb_t B1modb = -b;
B1modb *= ((bi >> (GMP_LIMB_BITS-cnt)) | (CNST_LIMB(1) << cnt));
ASSERT (B1modb <= b);   /* NB: not fully reduced mod b */
cps[2] = B1modb >> cnt;
  }

  cnt will ALWAYS equal 0 since there will be NO leading 0's when this is
  called since /mpn/generic/mod_1_1.c checks for the high bit being SET
  before calling.. which means this function only ever gets called with NO
  leading zeros!!!

Why are you so worked up?

The logic seems perfectly fine.

  ALSO there are unexplained differences between MOD_1_1P_METHOD 1 and
  MOD_1_1P_METHOD 2 when it comes to the function mpn_mod_1_1p_cps(). In
  one of them pre[4] is always set and in the other (method 2) pre[2] is
  skipped! Why are these two functions different? It looks like their job
  is to calculate the inverses for the following mod functions so one
  would expect them to be the same.

There are lots of "unexplained" things in the GMP internal functions.
But trust me, the GMP developers understand the sources.

  ALSO the x64 assembly versions of these codes also does not always set
  all 4 values of pre[4] and this has lead to incorrect results when using
  the exported function mpn_mod_1().

You hypothesise things here.  And you're wrong.

I benevolent reading of your claims here is that things will be bad if
you use one variant of the internal _cps function with another variant
of the corresponding internal mod function.  If that's what you're
trying to say, then you're right.  GMP is not edit proof, local user
edits might break it in all sorts of ways,

But if you actually claim that an unedited GMP has a bug here, please
construct a test case which uses documented interfaces, and which
demonstrates the claimed bug.

  I do not understand these functions enough

Shouting from the top of your lungs about a bug which is just the result
of reading the sources, without allowing yourself time to understand the
logic fully, is somewhat unfair.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[Brett Kuntz]

Hello, today I found a bug in the latest GMP (6.3) using uninitialized memory 
in /mpn/generic/mod_1_1.c while trying to understand some functions like 
mpn_mod_1_1p_cps.

Take a look at function mpn_mod_1() in /mpn/generic/ mod_1.c on lines 248 - 250

mp_limb_t pre[4];
mpn_mod_1_1p_cps (pre, b);
return mpn_mod_1_1p (ap, n, b, pre);

mp_limb_t pre[4] is not initialized and the mpn_mod_1_1p_cps() function never 
writes to pre[2]. So if we change that to mp_limb_t pre[4] = { -1, -1, -1, -1 
}; as a test we'll quickly see that inside mpn_mod_1_1p_cps() the value cps[2] 
(pre[2]) is never written to and if we print out pre[4] after running it we'll 
get output like: 0x21CFE6CFC938B36BU, 0xU, 0xU, 
0x9581CA13918612E1U (pre[2] is -1)

/mpn/generic/mod_1_1.c lines 260-266:

  if (LIKELY (cnt != 0))
{
  mp_limb_t B1modb = -b;
  B1modb *= ((bi >> (GMP_LIMB_BITS-cnt)) | (CNST_LIMB(1) << cnt));
  ASSERT (B1modb <= b); /* NB: not fully reduced mod b */
  cps[2] = B1modb >> cnt;
}

cnt will ALWAYS equal 0 since there will be NO leading 0's when this is called 
since /mpn/generic/mod_1_1.c checks for the high bit being SET before calling.. 
which means this function only ever gets called with NO leading zeros!!!

ALSO there are unexplained differences between MOD_1_1P_METHOD 1 and 
MOD_1_1P_METHOD 2 when it comes to the function mpn_mod_1_1p_cps(). In one of 
them pre[4] is always set and in the other (method 2) pre[2] is skipped! Why 
are these two functions different? It looks like their job is to calculate the 
inverses for the following mod functions so one would expect them to be the 
same.

Method 2 is the function that was written in x64 asm.

ALSO the x64 assembly versions of these codes also does not always set all 4 
values of pre[4] and this has lead to incorrect results when using the exported 
function mpn_mod_1().

/mpn/x86_64/mod_1_1.asm

neg %r12
mov %r12, %r8
mov %rax, (%rbx)C store bi
mov %rbp, 8(%rbx)   C store cnt
imul%rax, %r12
mov %r12, 24(%rbx)  C store B2modb
mov R32(%rbp), R32(%rcx)
testR32(%rcx), R32(%rcx)
jz  L(z)

mov $1, R32(%rdx)
ifdef(`SHLD_SLOW',`
C Destroys %rax, unlike shld. Otherwise, we could do B1modb
C before B2modb, and get rid of the move %r12, %r8 above.

shl R8(%rcx), %rdx
neg R32(%rcx)
shr R8(%rcx), %rax
or  %rax, %rdx
neg R32(%rcx)
shldR8(%rcx), %rax, %rdx
imul%rdx, %r8
shr R8(%rcx), %r8
mov %r8, 16(%rbx)   C store B1modb
L(z):
pop %r12
pop %rbx
pop %rbp
FUNC_EXIT()
ret

Notice on line 230 of the asm file (mov %r8, 16(%rbx) // C store B1modb) gets 
skipped over when count is 0 (which it will be 100% of the time when the 
high-bit is set).

I checked mod_1_2.c, mod_1_3.c, and mod_1_4.c and they do not seem to have this 
problem.

Also note that most compilers and run-times for me seem to have a flukey '0' 
here in memory (which will be the correct value when the high-bit is set) so 
that might be why no one has stumbled upon this bug yet or why it might pass 
tests.

I do not understand these functions enough to suggest a fix. I do not know if 
initializing pre[4] to all 0's will produce correct results.

Which is the correct version of mpn_mod_1_1p_cps() to use for now? (Method 1 or 
Method 2)

My apologies if this is not the best bug report ever.

-Brett Kuntz
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in __gmp_replacement_vsnprintf

[Vincent Lefevre]

On 2023-08-21 10:59:13 +0200, Paul Zimmermann wrote:
> here is a small program that exhibits the bug (for example on gcc231):
[...]

An OpenBSD 7 machine, and this is due to the fact that %n is
no longer supported by the system *printf functions, so that
GMP uses __gmp_replacement_vsnprintf.

See also in the archives:

https://gmplib.org/list-archives/gmp-bugs/2022-October/005200.html
https://gmplib.org/list-archives/gmp-bugs/2023-January/005230.html

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

bug in __gmp_replacement_vsnprintf

[Paul Zimmermann]

   Hi,

here is a small program that exhibits the bug (for example on gcc231):

gcc231$ cat bug.c
#include 
#include 
#include 

static void
foo (char **buf, const char *fmt, ...)
{
  va_list ap;
  va_start (ap, fmt);
  gmp_vasprintf (buf, fmt, ap);
  va_end (ap);
}

int
main (int argc, char **argv)
{
  char *buf[1];
  foo (buf, "%a", -1.25);
  printf ("buf='%s'\n", buf[0]);
}

gcc231$ cc -I. bug.c .libs/libgmp.a   
.libs/libgmp.a(doprntf.o): In function `__gmp_doprnt_mpf2':
doprntf.c:(.text+0x2c4): warning: sprintf() is often misused, please use 
snprintf()
.libs/libgmp.a(repl-vsnprintf.o): In function `__gmp_replacement_vsnprintf':
repl-vsnprintf.c:(.text+0x3a8): warning: vsprintf() is often misused, please 
use vsnprintf()

gcc231$ ./a.out   
repl-vsnprintf.c:389: GNU MP assertion failed: len < total_width
Abort trap (core dumped) 

You can also reproduce on any other computer after uncommenting
#define HAVE_VSNPRINTF 1 in config.h.

Paul

PS: it would be nice to add some tests with %a or %A in tests/misc/t-printf.c
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

bug in __gmp_replacement_vsnprintf

[Paul Zimmermann]

ping:

https://gmplib.org/list-archives/gmp-bugs/2022-October/005200.html

The bug was acknowledged by Niels in January:

https://gmplib.org/list-archives/gmp-bugs/2023-January/005230.html

but not fixed in 6.3.0.

Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug

[Paul Zimmermann]

   Hi,

as a complement to Torbjörn answer:

1) the decimal string 0.693...875 cannot be represented exactly within 3000
   bits, thus the mpf_set_str() necessarily performs some rounding
2) the mpf_get_str() also has to perform some rounding, since you convert
   a 3000-bit number into a 99-digit decimal string
3) mpf functions do not specify any rounding, see the GMP reference manual:

   Note that the 'mpf' functions are _not_ intended as a smooth
extension to IEEE P754 arithmetic.  In particular results obtained on
one computer often differ from the results on a computer with a
different word size.

   New projects should consider using the GMP extension library MPFR
() instead.  MPFR provides well-defined precision
and accurate rounding, and thereby naturally extends IEEE P754.

4) with MPFR, if you tell mpfr_set_str to round up and mpfr_get_str to
   round to nearest, you get:

$ cat f.c
#include 
#include 

int main()
{
  mpfr_t x;
 mpfr_init2(x,3000);
 
mpfr_set_str(x,"0.6931471805599453094172321214581765680755001343602552541206800094933936219696947156058633269964186875",10,MPFR_RNDU);
 char str[300];
 mpfr_exp_t myexp;
 mpfr_get_str(str, , 10, 99, x, MPFR_RNDN);
 mpfr_clear(x);


printf("%s\n",str);
}

$ gcc f.c -lmpfr
$ ./a.out
693147180559945309417232121458176568075500134360255254120680009493393621969694715605863326996418688

Best regards,
Paul Zimmermann

PS: followups about MPFR should go on the MPFR list

> From: 赵世忠 
> Date: Sun, 30 Jul 2023 08:41:43 +0800 (GMT+08:00)
> 
> mpf_t x;
> mpf_init2(x,3000);
> mpf_set_str(x,"0.6931471805599453094172321214581765680755001343602552541206800094933936219696947156058633269964186875",10);
> char str[300];
> mp_exp_t myexp;
> mpf_get_str(str, , 10, 99, x); 
> mpf_clear(x);
> 
> 
> printf("%s\n",str);
> 
> 
> The last digit should be '8', but mpf_get_str outputs '7'.
> 
> 
> 
> 
> 
> 
> ___
> 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: bug

[Torbjörn Granlund]

赵世忠  writes:

  The last digit should be '8', but mpf_get_str outputs '7'.

"Should be"?

Please read the GMP documentation, and if you still think there is a
bug, please write a bug report where you motivate what you think is not
right with GMP's current behaviour.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

bug

[赵世忠]

mpf_t x;
mpf_init2(x,3000);
mpf_set_str(x,"0.6931471805599453094172321214581765680755001343602552541206800094933936219696947156058633269964186875",10);
char str[300];
mp_exp_t myexp;
mpf_get_str(str, , 10, 99, x); 
mpf_clear(x);


printf("%s\n",str);


The last digit should be '8', but mpf_get_str outputs '7'.






___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Bug with MacOs

[Eleonora Vercesi]

Dear Sir/Madame, 

I am here to report a bug in GMP, in particular, make check fails 31 tests out 
of 50.

Please find attached the test-suite.log and the report, hopefully as detailed 
as needed.

Best, 
Eleonora Vercesi


___
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

bug in __gmp_replacement_vsnprintf

[Paul Zimmermann]

   Hi,

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?

Best regards,
Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Reporting a gmp bug

[Marco Bodrato]

Ciao,

Il 2022-10-26 13:40 ni...@lysator.liu.se ha scritto:

jy l  writes:


It seems like in `mpz_nextprime` this line (
https://gmplib.org/repo/gmp/file/tip/mpz/nextprime.c#l204), when `n` 
is

very large, it doesn't restrict the value of `odds_in_composite_sieve`
which leads to the `alloca` below crash and might cause more buffer


You are right.
Thank you very much for the report.


I agree the array size odds_in_composite_sieve should have an upper
bound here (and if we expect a very large sieve to be useful, it should
be allocated with TMP_ALLOC_TYPE, which falls back to heap allocation
for large sizes).


I'd like to have the time to rewrite that part of the code, but I 
actually don't.
I agree, we probably don't really need a very large array, and the code 
should work with any size. But the author of the code proposed the 
5*nbits size, and this size can be used...
I then just applied a patch following your suggestion: use ALLOC instead 
of SALLOC.



I'm afraid I don't understand the comment

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


The author of the code was working on large prime gaps (large sequences 
of composites between two primes). The "merit" is some kind of measure 
of how much unlikely the size of a prime gap is, so that the likeliness 
of a gap of 1000 numbers between primes with 1000 digits can be compared 
with the likeliness of a gap of 900 numbers only, but with much smaller 
primes. But I do not know the details. I'm sure that one can find them 
on mersenneforum :-) and I assume that also a shorter array should work 
very well :-D


Ĝis,
m

--
http://bodrato.it/papers/
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

Reporting a gmp bug

[jy l]

Dear developers/maintainers,

Hope this email finds you well!
I'm writing to report a crash we met while using libgmp. The POC looks like
this:
```
mpz_t n;
mpz_init(n);
mpz_fac_ui(n, 0x10006f);

mpz_t n2;
mpz_init(n2);
mpz_nextprime(n2, n);
```
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.
Could you please help us to verify this bug? Looking forward to your reply,
thanks!

Best regards,
Jiayi Lin
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

bug in __gmp_replacement_vsnprintf

[Paul Zimmermann]

   Hi,

[for the record, this issue was originally reported on the MPFR list:
https://sympa.inria.fr/sympa/arc/mpfr/2022-10/msg1.html]

Originally, it appeared only under Windows with the clang compiler,
and using MPIR, but I can reproduce it under Linux with GMP 6.2.1:

1) configure GMP
2) uncomment the #define HAVE_VSNPRINTF 1 line in config.h
3) build GMP
4) run the MPFR tsprintf test file with the built GMP

The issue is because __gmp_replacement_vsnprintf does not deal with %a not %A.
Then when calling gmp_printf ("%a", -1.25) for example, we get total_width=3
initially, we jump to the 'default' case, where the ASSERT(0) does nothing
in production code, and we go to next, where width=0 and prec=6, thus
total_width is increased to 9. But we also have len=9 because
buf='-0x1.4p+0'. Then the assertion ASSERT_ALWAYS (len < total_width) fails.

Paul

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Arithmetic bug on ARM (STM 32 F4)

[Titouan Coladon]

Hi,

I cannot run make check because of the cross-compilation.

I also noticed that the GMP function "mpz_probab_prime_p" fail when GMP
is built with the latest versions (after 7) of gcc-arm-none-eabi.


Titouan Coladon


Le 22/01/2021 à 12:33, Vincent Lefevre a écrit :
> Hi,
>
> On 2021-01-22 11:59:43 +0100, Titouan Coladon wrote:
>> it's indeed, gcc that must have a bug.
>>
>> The older bare metal version: gcc-arm-none-eabi-7-2017-q4-major-linux is
>> working properly.
>>
>> Then the latest version : gcc-arm-none-eabi-8-2018-q4-major-linux,
>> gcc-arm-none-eabi-9-2020-q2-update-x86_64-linux and
>> gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux all have the issue.
> Does "make check" fail? If it doesn't, perhaps a new test could be
> added.
>
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Arithmetic bug on ARM (STM 32 F4)

[Vincent Lefevre]

On 2021-01-22 13:29:13 +0100, Titouan Coladon wrote:
> I cannot run make check because of the cross-compilation.

I think that it would be a good idea to use an emulator to check the
GMP build. This should always be done. Compiler bugs are common.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Arithmetic bug on ARM (STM 32 F4)

[Vincent Lefevre]

Hi,

On 2021-01-22 11:59:43 +0100, Titouan Coladon wrote:
> it's indeed, gcc that must have a bug.
> 
> The older bare metal version: gcc-arm-none-eabi-7-2017-q4-major-linux is
> working properly.
> 
> Then the latest version : gcc-arm-none-eabi-8-2018-q4-major-linux,
> gcc-arm-none-eabi-9-2020-q2-update-x86_64-linux and
> gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux all have the issue.

Does "make check" fail? If it doesn't, perhaps a new test could be
added.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Arithmetic bug on ARM (STM 32 F4)

[Dennis Clarke]

On 1/21/21 3:17 PM, Torbjörn Granlund wrote:
>   ttt =
>   
> 3578942983869995381409279381784954092773488221200587338717407747084074518600438737913956360066709506626656635118978526559637095289631190671071178702312877654
> 
>   but ttt should be
>   
> 5247183143879283565064056089869553515440215252945038779070795247972433237341511292686962488915110675351673985513318500576097977116134885013371639187873069514
> 
>   I give the code to reproduce the bug in attachment.
> 
>   GMP is built with the options:
>   
> CC=/home/titouan/Softs/gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux/gcc-arm-none-eabi-10-2020-q4-major/bin/arm-none-eabi-gcc
>   ../configure CFLAGS="-nostartfiles --specs=nosys.specs -mcpu=cortex-m4"
>   --host=arm-none-eabi --disable-assembly --prefix=YOUR_CHOICE
> 
> As you might guess, GMP's mod operation has been tested a lot during
> GMP's 30 years of existence.  A completely fundamental bug like the one
> you observe is of course still possible, but incredibly unlikely.
> 
> It is much more likely that the compiler you used for compiling GMP is
> buggy.  That's indeed where you should start looking.
> 
> Unfortunatly, we cannot help.  We don't know what compiler you used, and
> even if we did, we don't have access to it.
> 
> 

I just checked on Debian sid with gcc 10.2 and sparc64 and IBM Power9
ppc64le and also on Oracle Fujitsu SPARC64 with Oracle Studio 12.6 as
well as on Debian sid i686 and also FreeBSD UNIX with LLVM/Clang on
amd64 and then a few other sundy systems. All work perfectly.

/***
 * The Open Group Base Specifications Issue 6
 * IEEE Std 1003.1, 2004 Edition
 *
 *  An XSI-conforming application should ensure that the feature
 *  test macro _XOPEN_SOURCE is defined with the value 600 before
 *  inclusion of any header. This is needed to enable the
 *  functionality described in The _POSIX_C_SOURCE Feature Test
 *  Macro and in addition to enable the XSI extension.
 ***/
#define _XOPEN_SOURCE 600

#include 
#include 
#include 
#include 
#include 
#include 

#include 

int main(int argc, char *argv[])
{

mpz_t t;
mpz_init(t);
mpz_t tt;
mpz_init(tt);
mpz_t ttt;
mpz_init(ttt);

mpz_t result_check, expected_result;
mpz_init(result_check);
mpz_init(expected_result);

mpz_set_str( tt,
"25975415027868818028037643145183730078267964363630309107863975221668725232906664910091356673487591948237515304861352649057814029879720636142810833722202669061030484458925649047021859875730105532595466846094449735851132072400310565642",
10);

mpz_set_str(t,
"6864797660130609714981900799081393217269435300143305409394463459185543183397655394245057746333217197532963996371363321113864768612440380340372808892707005449",
10);

mpz_mod(ttt, tt, t);

printf("tt = ");
gmp_printf("%Zd", tt);
printf("\n");

printf("t = ");
gmp_printf("%Zd", t);
printf("\n");

printf("ttt = ");
gmp_printf("%Zd", ttt);
printf("\n");


mpz_set_str(expected_result,

"5247183143879283565064056089869553515440215252945038779070795247972433237341511292686962488915110675351673985513318500576097977116134885013371639187873069514",
10);


mpz_sub(result_check, expected_result, ttt);
printf("\n check the diff on the expected result = ");
gmp_printf("%Zd",result_check);
printf("\n");


mpz_clear(t);
mpz_clear(tt);
mpz_clear(ttt);

mpz_clear(expected_result);
mpz_clear(result_check);

return EXIT_SUCCESS;

}


As soon as I have some arm data I will be sure to pass that along.



-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Arithmetic bug on ARM (STM 32 F4)

[Torbjörn Granlund]

  ttt =
  
3578942983869995381409279381784954092773488221200587338717407747084074518600438737913956360066709506626656635118978526559637095289631190671071178702312877654

  but ttt should be
  
5247183143879283565064056089869553515440215252945038779070795247972433237341511292686962488915110675351673985513318500576097977116134885013371639187873069514

  I give the code to reproduce the bug in attachment.

  GMP is built with the options:
  
CC=/home/titouan/Softs/gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux/gcc-arm-none-eabi-10-2020-q4-major/bin/arm-none-eabi-gcc
  ../configure CFLAGS="-nostartfiles --specs=nosys.specs -mcpu=cortex-m4"
  --host=arm-none-eabi --disable-assembly --prefix=YOUR_CHOICE

As you might guess, GMP's mod operation has been tested a lot during
GMP's 30 years of existence.  A completely fundamental bug like the one
you observe is of course still possible, but incredibly unlikely.

It is much more likely that the compiler you used for compiling GMP is
buggy.  That's indeed where you should start looking.

Unfortunatly, we cannot help.  We don't know what compiler you used, and
even if we did, we don't have access to it.


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: A message bug. At least Version 6.2.0

[Marco Bodrato]

Ciao,

Il 2020-12-22 15:55 Guillermo Monguia ha scritto:

In mini-gmp.c function mpz_export, when calling gmp_die("mpz_import:
...") instead of gmp_die("mpz_export: ...")


Corrected, thanks!

https://gmplib.org/repo/gmp/rev/6fed56750f6f

Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: A message bug. At least Version 6.2.0

[Paul Zimmermann]

> In mini-gmp.c function mpz_export, when calling gmp_die("mpz_import: ...") 
> instead of gmp_die("mpz_export: ...")

btw, are nails still supported for current architectures? On x86_64 I get:

$ ./configure --enable-nails
...
configure: error: no version of invert_limb_table found in path:  
x86_64/skylake/nails x86_64/skylake x86_64/coreibwl/nails x86_64/coreibwl 
x86_64/coreihwl/nails x86_64/coreihwl x86_64/coreisbr/nails x86_64/coreisbr 
x86_64/coreinhm/nails x86_64/coreinhm x86_64/core2/nails x86_64/core2 
x86_64/nails x86_64 generic

$ ./config.guess 
skylake-pc-linux-gnu

Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

A message bug. At least Version 6.2.0

[Guillermo Monguia]

In mini-gmp.c function mpz_export, when calling gmp_die("mpz_import: ...") 
instead of gmp_die("mpz_export: ...")

Sent from my iPhone
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Andreas Buff]

Am 16.10.20 um 11:48 schrieb Torbjörn Granlund:
> Andreas Buff  writes:
>
>thanks to your help, its building fine now without --disable-assembly,
>but it crashes using it.
>
>I am totally not into ASM, so forgive unqualified report(s).
>
>Here is the backtrace:
>
>* thread #8, queue = 'PEPAsyncSession.queue', stop reason =
>EXC_BAD_ACCESS (code=2, address=0x16fbcc000)
>   * frame #0: 0x0001019baf58 PEPObjCAdapterFramework`__gmpn_add_n + 
> 144
>     frame #1: 0x0001019babe4 PEPObjCAdapterFramework`__gmpn_add + 68
>     frame #2: 0x0001019e756c
>PEPObjCAdapterFramework`__gmpn_toom2_sqr + 1020
>     frame #3: 0x0001019c8030 PEPObjCAdapterFramework`__gmpn_sqr + 144
>     frame #4: 0x0001019fe838 PEPObjCAdapterFramework`__gmpn_powm + 
> 3416
>     frame #5: 0x0001019b5678 PEPObjCAdapterFramework`__gmpz_powm + 
> 2432
>
>Let me know if and how to provide more useful information if needed.
>
> Your report is scarce of detail.  Perhaps there is a bug in your
> program?
>
> Another possibility is that GMP does not work right on Ios.  Since that
> is a closed platform where developers need to pay Apple for programming,
> you cannot excpect any effort from the GMP team with regards to
> development or testing of GMP for Ios.
>
> If somebody who pays the Apple programmer tax is willing to help you
> debug your crash, we will certainly look at whatever GMP change might be
> needed.
>
Haha, fair enough, thanks :-)

JFYI: I can confirm GMP works fine on iOS with ASM disabled.





pEpkey.asc
Description: application/pgp-keys
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Andreas Buff]

Hi Marco,

thanks to your help, its building fine now without --disable-assembly,  
but it crashes using it.

I am totally not into ASM, so forgive unqualified report(s).

Here is the backtrace:

* thread #8, queue = 'PEPAsyncSession.queue', stop reason =  
EXC_BAD_ACCESS (code=2, address=0x16fbcc000)
   * frame #0: 0x0001019baf58 PEPObjCAdapterFramework`__gmpn_add_n + 144
     frame #1: 0x0001019babe4 PEPObjCAdapterFramework`__gmpn_add + 68
     frame #2: 0x0001019e756c  
PEPObjCAdapterFramework`__gmpn_toom2_sqr + 1020
     frame #3: 0x0001019c8030 PEPObjCAdapterFramework`__gmpn_sqr + 144
     frame #4: 0x0001019fe838 PEPObjCAdapterFramework`__gmpn_powm + 3416
     frame #5: 0x0001019b5678 PEPObjCAdapterFramework`__gmpz_powm + 2432

Let me know if and how to provide more useful information if needed.

Thanks,
Andreas

Am 15.10.20 um 13:57 schrieb Andreas Buff:
> Hi Marco,
>
>
> Am 14.10.20 um 22:21 schrieb Torbjörn Granlund:
>> Marco Bodrato  writes:
>>
>> Look for a filename starting with gmp-6.2.0-202010...
>>
>> Then please follow up here!
>>
>> I changed how snapshots are managed.
>>
>> 1. There are now subdirs for each release series, plus "gmp-next".  The
>>  latter is made from the bleeding edge repo.
>>
>> 2. We have had an idea of an "active" repo, which is the same as the
>>  autobuilds use.  Now, both that active repo and the bleeding edge
>>  repo will have snapshots manufactured once per day.
>>
>> I've long planned to change the snapshot mechanism even more:
>>
>> 3. Make snapshots just after checkins and only after checkins which pass
>> some tests.  If n checkins are made in a day, n snapshots are made,
>> where n might be 0.
>>
>> 4. Do that for all GMP repos
> Using the latest snapshot (6.2.99-20201015) fixed the issue.
>
> Thx! A lot!
>




pEpkey.asc
Description: application/pgp-keys
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Torbjörn Granlund]

Andreas Buff  writes:

  thanks to your help, its building fine now without --disable-assembly,  
  but it crashes using it.

  I am totally not into ASM, so forgive unqualified report(s).

  Here is the backtrace:

  * thread #8, queue = 'PEPAsyncSession.queue', stop reason =  
  EXC_BAD_ACCESS (code=2, address=0x16fbcc000)
     * frame #0: 0x0001019baf58 PEPObjCAdapterFramework`__gmpn_add_n + 144
       frame #1: 0x0001019babe4 PEPObjCAdapterFramework`__gmpn_add + 68
       frame #2: 0x0001019e756c  
  PEPObjCAdapterFramework`__gmpn_toom2_sqr + 1020
       frame #3: 0x0001019c8030 PEPObjCAdapterFramework`__gmpn_sqr + 144
       frame #4: 0x0001019fe838 PEPObjCAdapterFramework`__gmpn_powm + 3416
       frame #5: 0x0001019b5678 PEPObjCAdapterFramework`__gmpz_powm + 2432

  Let me know if and how to provide more useful information if needed.

Your report is scarce of detail.  Perhaps there is a bug in your
program?

Another possibility is that GMP does not work right on Ios.  Since that
is a closed platform where developers need to pay Apple for programming,
you cannot excpect any effort from the GMP team with regards to
development or testing of GMP for Ios.

If somebody who pays the Apple programmer tax is willing to help you
debug your crash, we will certainly look at whatever GMP change might be
needed.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Andreas Buff]

Hi Marco,


Am 14.10.20 um 22:21 schrieb Torbjörn Granlund:
> Marco Bodrato  writes:
>
>Look for a filename starting with gmp-6.2.0-202010...
>
>Then please follow up here!
>
> I changed how snapshots are managed.
>
> 1. There are now subdirs for each release series, plus "gmp-next".  The
> latter is made from the bleeding edge repo.
>
> 2. We have had an idea of an "active" repo, which is the same as the
> autobuilds use.  Now, both that active repo and the bleeding edge
> repo will have snapshots manufactured once per day.
>
> I've long planned to change the snapshot mechanism even more:
>
> 3. Make snapshots just after checkins and only after checkins which pass
> some tests.  If n checkins are made in a day, n snapshots are made,
> where n might be 0.
>
> 4. Do that for all GMP repos
Using the latest snapshot (6.2.99-20201015) fixed the issue.

Thx! A lot!



pEpkey.asc
Description: application/pgp-keys
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Andreas Buff]

Am 14.10.20 um 15:38 schrieb Marc Glisse:
> On Wed, 14 Oct 2020, Andreas Buff wrote:
>
>> Using host `aarch64-apple-darwin` gives me "unknown AArch64 fixup kind!"
>> errors.
>
> There was a discussion related to arm64 and apple in july, did you try 
> with a recent snapshot from https://gmplib.org/download/snapshot/ ?
>
Will try. I am using 6.2.0

Latest snapshot is from may though (re "discussion related to arm64 and 
apple in july").

Will come back with results.

Thx!




pEpkey.asc
Description: application/pgp-keys
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Hans Åberg]

> On 14 Oct 2020, at 12:59, Andreas Buff  wrote:
> 
> We are cross building GMP for use on ARM64 iOS devices using this command:
> …

This link suggests using the -target option for makefiles outside Xcode.

https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Torbjörn Granlund]

Marco Bodrato  writes:

  Look for a filename starting with gmp-6.2.0-202010...

  Then please follow up here!

I changed how snapshots are managed.

1. There are now subdirs for each release series, plus "gmp-next".  The
   latter is made from the bleeding edge repo.

2. We have had an idea of an "active" repo, which is the same as the
   autobuilds use.  Now, both that active repo and the bleeding edge
   repo will have snapshots manufactured once per day.

I've long planned to change the snapshot mechanism even more:

3. Make snapshots just after checkins and only after checkins which pass
some tests.  If n checkins are made in a day, n snapshots are made,
where n might be 0.

4. Do that for all GMP repos.


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Marco Bodrato]

Il 2020-10-14 21:28 t...@gmplib.org ha scritto:

Andreas Buff  writes:

  Latest snapshot is from may though



There is one made every day.


Look for a filename starting with gmp-6.2.0-202010...

Then please follow up here!

Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Torbjörn Granlund]

Andreas Buff  writes:

  Latest snapshot is from may though

Not quite.  Look better.

There is one made every day.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Andreas Buff]

Hi,

thanks (!) for useful and fast response.

See below.

Best,
Andreas


Am 14.10.20 um 14:50 schrieb Marc Glisse:
> On Wed, 14 Oct 2020, Andreas Buff wrote:
>
>> We are cross building GMP for use on ARM64 iOS devices using this 
>> command:
>>
>> ```
>> export CFLAGS="-arch ${ARCH} -isysroot ${SDK_PATH}
>> -miphoneos-version-min=${MIN_IOS_VERSION} -std=c99"
>> export LDFLAGS="-arch ${ARCH}"
>> export CC="$(whereis gcc) -arch ${ARCH} -isysroot ${SDK_PATH}"
>>
>> PKG_CONFIG_ALLOW_CROSS=1 PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig
>> ./configure --host=${HOST} --prefix=$PREFIX
>> make -j4
>> make install
>> ```
>>
>> Where:
>> ${ARCH}="arm64"
>> ${SDK_PATH}=path to iOS14 SDK (failed also wirth previous SDK versions
>> MIN_IOS_VERSION="11.0"
>> ${HOST}="arm-apple-darwin"
>
> That triplet looks like 32 bits to me, don't you mean something like 
> aarch64 or arm64 instead of arm there?

Ah, Good catch.

Using host `aarch64-apple-darwin` gives me "unknown AArch64 fixup kind!" 
errors.

Find relevant part of the log attached.

tmp-bdiv_q_1.s:75:2: libtool: compile:  
/Applications/Xcode_11.6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
 -arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sbpi1_bdiv_r 
-arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -miphoneos-version-min=11.0 -std=c99 -c sbpi1_bdiv_r.c  -fno-common -DPIC -o 
.libs/sbpi1_bdiv_r.o
libtool: compile:  
/Applications/Xcode_11.6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
 -arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sbpi1_bdiv_qr 
-arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -miphoneos-version-min=11.0 -std=c99 -c sbpi1_bdiv_qr.c -o sbpi1_bdiv_qr.o 
>/dev/null 2>&1
libtool: compile:  
/Applications/Xcode_11.6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
 -arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sbpi1_bdiv_r 
-arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -miphoneos-version-min=11.0 -std=c99 -c sbpi1_bdiv_r.c -o sbpi1_bdiv_r.o 
>/dev/null 2>&1
libtool: compile:  
/Applications/Xcode_11.6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
 -arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dcpi1_bdiv_q 
-arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -miphoneos-version-min=11.0 -std=c99 -c dcpi1_bdiv_q.c  -fno-common -DPIC -o 
.libs/dcpi1_bdiv_q.o
error: /bin/sh ../libtool  --tag=CC   --mode=compile 
/Applications/Xcode_11.6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
 -arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -DHAVE_CONFIG_H -I. -I..  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo 
dcpi1_bdiv_qr | sed 's/_$//'`   -arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -miphoneos-version-min=11.0 -std=c99 -c -o dcpi1_bdiv_qr.lo dcpi1_bdiv_qr.c
ADR/ADRP relocations must be GOT relative
 adrp x7, :got:__gmp_binvert_limb_table
 ^
tmp-bdiv_q_1.s:75:2: error: unknown AArch64 fixup kind!
/bin/sh ../libtool  --tag=CC   --mode=compile 
/Applications/Xcode_11.6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
 -arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -DHAVE_CONFIG_H -I. -I..  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo mu_bdiv_q 
| sed 's/_$//'`   -arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -miphoneos-version-min=11.0 -std=c99 -c -o mu_bdiv_q.lo mu_bdiv_q.c
libtool: compile:  
/Applications/Xcode_11.6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
 -arch arm64 -isysroot 
/Applications/Xcode_11.6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk
 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dcpi1_bdiv_qr 
-arch arm64 -isysroot 

GMP bug (?) - unable to build for ARM64 with assembly enabled

[Andreas Buff]

Hi,

We are cross building GMP for use on ARM64 iOS devices using this command:

```
export CFLAGS="-arch ${ARCH} -isysroot ${SDK_PATH} 
-miphoneos-version-min=${MIN_IOS_VERSION} -std=c99"
export LDFLAGS="-arch ${ARCH}"
export CC="$(whereis gcc) -arch ${ARCH} -isysroot ${SDK_PATH}"

PKG_CONFIG_ALLOW_CROSS=1 PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig 
./configure --host=${HOST} --prefix=$PREFIX
make -j4
make install
```

Where:
${ARCH}="arm64"
${SDK_PATH}=path to iOS14 SDK (failed also wirth previous SDK versions
MIN_IOS_VERSION="11.0"
${HOST}="arm-apple-darwin"

Error:
configure: error: Oops, mp_limb_t is 64 bits, but the assembler code
in this configuration expects 32 bits.
You appear to have set $CFLAGS, perhaps you also need to tell GMP the
intended ABI, see "ABI and ISA" in the manual.


Adding --disable-assembly to configure works.

I have tried several things from the manual with no success like setting 
ABI=64 (-> "configure: error: ABI=64 is not among the following valid 
choices: 32".

Can you please assist?

Best,
Andreas



pEpkey.asc
Description: application/pgp-keys
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Marc Glisse]

On Wed, 14 Oct 2020, Andreas Buff wrote:


Using host `aarch64-apple-darwin` gives me "unknown AArch64 fixup kind!"
errors.


There was a discussion related to arm64 and apple in july, did you try 
with a recent snapshot from https://gmplib.org/download/snapshot/ ?


--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Marc Glisse]

On Wed, 14 Oct 2020, Andreas Buff wrote:


We are cross building GMP for use on ARM64 iOS devices using this command:

```
export CFLAGS="-arch ${ARCH} -isysroot ${SDK_PATH}
-miphoneos-version-min=${MIN_IOS_VERSION} -std=c99"
export LDFLAGS="-arch ${ARCH}"
export CC="$(whereis gcc) -arch ${ARCH} -isysroot ${SDK_PATH}"

PKG_CONFIG_ALLOW_CROSS=1 PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig
./configure --host=${HOST} --prefix=$PREFIX
make -j4
make install
```

Where:
${ARCH}="arm64"
${SDK_PATH}=path to iOS14 SDK (failed also wirth previous SDK versions
MIN_IOS_VERSION="11.0"
${HOST}="arm-apple-darwin"


That triplet looks like 32 bits to me, don't you mean something like 
aarch64 or arm64 instead of arm there?


--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: gmp 6.2.0 documentation bug

[Hans Åberg]

> On 29 Sep 2020, at 19:17, Marco Bodrato  wrote:
> 
> Il 2020-09-29 16:09 TonyMcC ha scritto:
>> I think there is a word (a function name?) missing from the
>> documentation for gmp 6.2.0.  In gmp.texi, at line 2541 it reads:
>> "it's probably best to call to get a starting point and iterate from there."
>> Should there be a function name after "call"?
> 
> The complete sentence is:
> 
> Functions like @code{mpz_fac_ui}, @code{mpz_fib_ui} and @code{mpz_bin_uiui}
> are designed for calculating isolated values.  If a range of values is wanted
> it's probably best to call to get a starting point and iterate from there.
> 
> Maybe we can simply remove "to call".
> 
> The documentation of mpz_fib_ui correctly suggests the function to call: 
> mpz_fib2_ui.
> 
> Speaking about mpz_fac_ui and mpz_bin_uiui, it shouldn't be necessary to 
> suggest how to get the starting point.

It might say:
  If a range of values is wanted, see the definition respective function.
Since it is properly described for first two. For the binomials, it would be 
most efficient to compute the trapezoid above the values in Pascal's triangle, 
I would think, and the function does not provide an efficient way to get that.


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

gmp 6.2.0 documentation bug

[TonyMcC]

Hi,

I think there is a word (a function name?) missing from the 
documentation for gmp 6.2.0.  In gmp.texi, at line 2541 it reads:


"it's probably best to call to get a starting point and iterate from there."

Should there be a function name after "call"?

Best wishes,
Tony
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: gmp 6.2.0 documentation bug

[Marco Bodrato]

Ciao,

Il 2020-09-29 16:09 TonyMcC ha scritto:

I think there is a word (a function name?) missing from the
documentation for gmp 6.2.0.  In gmp.texi, at line 2541 it reads:

"it's probably best to call to get a starting point and iterate from 
there."


Should there be a function name after "call"?


The complete sentence is:

Functions like @code{mpz_fac_ui}, @code{mpz_fib_ui} and 
@code{mpz_bin_uiui}
are designed for calculating isolated values.  If a range of values is 
wanted
it's probably best to call to get a starting point and iterate from 
there.


Maybe we can simply remove "to call".

The documentation of mpz_fib_ui correctly suggests the function to call: 
mpz_fib2_ui.


Speaking about mpz_fac_ui and mpz_bin_uiui, it shouldn't be necessary to 
suggest how to get the starting point.


Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: gmp 6.2.0 documentation bug

[Paul Zimmermann]

   Hi Tony,

> I think there is a word (a function name?) missing from the 
> documentation for gmp 6.2.0.  In gmp.texi, at line 2541 it reads:
> 
> "it's probably best to call to get a starting point and iterate from there."
> 
> Should there be a function name after "call"?

yes, I guess you should read "it's probably best to call them to get a
starting point and iterate from there" where "them" refers to mpz_fac_ui,
mpz_fib_ui and mpz_bin_uiui.

Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpz_sizeinbase() bug

[Vincent Lefevre]

On 2020-08-19 10:39:01 +0200, Paul Zimmermann wrote:
>Dear Johannes,
> 
> if you read carefully the GMP documentation, you will see this is not a bug:
> 
>  -- Function: size_t mpz_sizeinbase (const mpz_t OP, int BASE)
>  Return the size of OP measured in number of digits in the given
>  BASE.  BASE can vary from 2 to 62.  The sign of OP is ignored, just
>  the absolute value is used.  The result will be either exact or 1
>  too big.  If BASE is a power of 2, the result is always exact.  If
>  OP is zero the return value is always 1.

IMHO, it's a bad thing to say that one returns something, and later
say that this can be inexact. It could be improved to something like:

  Return the size of OP measured in number of digits in the given
  BASE, or this size + 1.  BASE can vary from 2 to 62.  If BASE is
  a power of 2, the result is always the exact size.  The sign of
  OP is ignored, just the absolute value is used. If OP is zero the
  return value is always 1.

> If you want the exact size, use mpz_get_str() and strlen(),
> or mpz_ui_pow_ui() and mpz_cmp().

I would say that this is rather inefficient since the exact result
can generally be determined from the first few digits.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpz_sizeinbase() bug

[Paul Zimmermann]

   Dear Johannes,

if you read carefully the GMP documentation, you will see this is not a bug:

 -- Function: size_t mpz_sizeinbase (const mpz_t OP, int BASE)
 Return the size of OP measured in number of digits in the given
 BASE.  BASE can vary from 2 to 62.  The sign of OP is ignored, just
 the absolute value is used.  The result will be either exact or 1
 too big.  If BASE is a power of 2, the result is always exact.  If
 OP is zero the return value is always 1.

In this case mpz_sizeinbase(63, 10) is exact, and
mpz_sizeinbase(64, 10) is 1 too big.

If you want the exact size, use mpz_get_str() and strlen(),
or mpz_ui_pow_ui() and mpz_cmp().

Paul Zimmermann

> Date: Wed, 19 Aug 2020 02:21:51 +0200
> From: "Lebender, Johannes" 
> 
> Dear GMP maintainers,
> 
> i found a possible bug in the mpz_sizeinbase() function. e.g.
> mpz_sizeinbase(63, 10) returns 2
> mpz_sizeinbase(64, 10) returns 3
> 
> Attached to this mail you can find a detailed report with all 
> informations needed as described in 
> https://gmplib.org/manual/Reporting-Bugs
> 
> Many thanks for maintaining this library!
> best regards,
> Johannes Lebender
> 
> [2:application/x-gzip Show Save:GMP_mpz_sizeinbase_bugreport.tar (15kB)]
> 
> 
> [3:text/plain Hide]
> 
> ___
> 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: mpz_sizeinbase() bug

[Torbjörn Granlund]

"Lebender, Johannes"  writes:

  i found a possible bug in the mpz_sizeinbase() function. e.g.
  mpz_sizeinbase(63, 10) returns 2
  mpz_sizeinbase(64, 10) returns 3

Why do you think those values are wrong?  Which values do you expect
instead?

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

mpz_sizeinbase() bug

[Lebender, Johannes]

Dear GMP maintainers,

i found a possible bug in the mpz_sizeinbase() function. e.g.
mpz_sizeinbase(63, 10) returns 2
mpz_sizeinbase(64, 10) returns 3

Attached to this mail you can find a detailed report with all 
informations needed as described in 
https://gmplib.org/manual/Reporting-Bugs


Many thanks for maintaining this library!
best regards,
Johannes Lebender

GMP_mpz_sizeinbase_bugreport.tar
Description: GNU Zip compressed data
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug report - 2 tests fail in make check

[Elyassaf Loyfer]

Got it.
Thanks a lot

On Thu, Jul 30, 2020 at 11:36 AM Torbjörn Granlund  wrote:

> Elyassaf Loyfer  writes:
>
>   >>> uname -a
>   Darwin huji-132-64-28-195.xt.huji.ac.il 19.5.0 Darwin Kernel Version
>   19.5.0: Tue May 26 20:41:44 PDT 2020;
> root:xnu-6153.121.2~2/RELEASE_X86_64
>   x86_64
>   >>> ./config.guess
>   kabylake-apple-darwin19.5.0
>   >>> ./configfsf.guess
>   x86_64-apple-darwin19.5.0
>   >>> what `which cc`
>   /usr/bin/cc
>   >>> gcc -v
>   Configured with: --prefix=/Library/Developer/CommandLineTools/usr
>
> --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
>   Apple clang version 11.0.0 (clang-1100.0.33.8)
>   Target: x86_64-apple-darwin19.5.0
>   Thread model: posix
>   InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>
> These test suite failures smell compiler bug.  Unfortunately, while
> Apple is a large company, their compiler team does not seem to be able
> to produce a robust compiler.  Only every few "Xcode" release comes with
> a compiler which GMP does not trip up.
>
> I haven't kept a list of versions of the compiler which does not work.
> But I know for a fact that the first Xcode release which came with
> Catalina did not.  The first update was no better, but I think the third
> update actually worked.
>
> You might want to install a new Xcode version.
>
> --
> Torbjörn
> Please encrypt, key id 0xC8601622
>
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug report - 2 tests fail in make check

[Torbjörn Granlund]

Elyassaf Loyfer  writes:

  >>> uname -a
  Darwin huji-132-64-28-195.xt.huji.ac.il 19.5.0 Darwin Kernel Version
  19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64
  x86_64
  >>> ./config.guess
  kabylake-apple-darwin19.5.0
  >>> ./configfsf.guess
  x86_64-apple-darwin19.5.0
  >>> what `which cc`
  /usr/bin/cc
  >>> gcc -v
  Configured with: --prefix=/Library/Developer/CommandLineTools/usr
  
--with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
  Apple clang version 11.0.0 (clang-1100.0.33.8)
  Target: x86_64-apple-darwin19.5.0
  Thread model: posix
  InstalledDir: /Library/Developer/CommandLineTools/usr/bin

These test suite failures smell compiler bug.  Unfortunately, while
Apple is a large company, their compiler team does not seem to be able
to produce a robust compiler.  Only every few "Xcode" release comes with
a compiler which GMP does not trip up.

I haven't kept a list of versions of the compiler which does not work.
But I know for a fact that the first Xcode release which came with
Catalina did not.  The first update was no better, but I think the third
update actually worked.

You might want to install a new Xcode version.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Torbjörn Granlund]

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

  A crude test generator:

A slightly better variant.  It expects an argument, either "add" or
"sub", allowing it to test both add_ss and sub_ddmmss.

This version should work fine on 32-bit systems without modification.

This code is not well-defined (as Vincent might point out) as it
converts between signed and unsigned quantities in the range where the
signed number is negative.  But it does the job I intended it to do.

I will integrate this in some form in the GMP test facility.



gen-longlong.c
Description: Binary data


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Paul Zimmermann]

   Dear Torbjörn,

> A crude test generator: [...]

great! On gcc115 it fails with the longlong.h shipped with GMP 6.2.0:

zimmerma@gcc115:/tmp/gmp-6.2.0$ /opt/cfarm/gcc-latest/bin/gcc test.c
zimmerma@gcc115:/tmp/gmp-6.2.0$ ./a.out > test1.c
zimmerma@gcc115:/tmp/gmp-6.2.0$ /opt/cfarm/gcc-latest/bin/gcc test1.c -lgmp
zimmerma@gcc115:/tmp/gmp-6.2.0$ ./a.out 
error for f2(0x1,0x0): want (0x0,0x1) got (0x,0x1)
...
error for f4034(0x7fff,0x0): want (0x0,0x7fff) got 
(0x,0x7fff)

With the patch you sent it works:

zimmerma@gcc115:/tmp/gmp-6.2.0$ ./a.out
zimmerma@gcc115:/tmp/gmp-6.2.0$ 

Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Torbjörn Granlund]

Vincent Lefevre  writes:

  Note: in the tests, it is important to test the macro on constants
  in order to test the "if" case.

A crude test generator:

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

void
one (size_t ind, mp_limb_t m0, mp_limb_t s0)
{
  printf ("void f%zu(mp_limb_t* r1p, mp_limb_t* r0p) {\n", ind);
  printf ("mp_limb_t r1, r0;\n");
  printf ("sub_ddmmss (r1, r0, 0, %ld, 0, %ld);\n", (long) m0, (long) s0);
  printf ("*r1p = r1;  *r0p = r0;\n");
  printf ("}\n");
}

mp_limb_t ops[1000];
mp_limb_t res1[1000];
mp_limb_t res0[1000];

int
main ()
{
  size_t n_operands = 0;
  size_t n_functions = 0;

  for (int i = 0; i < 16; i++)
{
  ops[n_operands++] = 1 << i;
  ops[n_operands++] = -(1 << i);
  ops[n_operands++] = (1 << i) - 1;
  ops[n_operands++] = -(1 << i) - 1;
}

  printf ("#include \n");
  printf ("#include \n");
  printf ("#include \"gmp-impl.h\"\n");
  printf ("#include \"longlong.h\"\n");

  /* Generate functions and print them.  */
  for (int i = 0; i < n_operands; i++)
{
  for (int j = 0; j < n_operands; j++)
{
  one (n_functions++, ops[i], ops[j]);
}
}

#if 1
  /* Print out ops[] definition.  */
  printf ("int ops[%zu] = {\n", n_operands);
  for (int i = 0; i < n_operands; i++)
{
  printf ("%ld,", (long) ops[i]);
  if ((i + 1) % 4 == 0)
puts ("");
}
  printf ("};\n");
#endif

  /* Print out function pointer table.  */
  printf ("typedef void (*func_t) (mp_limb_t*, mp_limb_t*);\n");
  printf ("func_t funcs[%zu] = {\n", n_functions);
  for (size_t i = 0; i < n_functions; i++)
{
  printf ("f%zu,", i);
  if ((i + 1) % 16 == 0)
puts ("");
}
  printf ("};\n");

  /* Print out table of reference results.  */
  printf ("mp_limb_t ref[%zu][2] = {\n", n_functions);
  for (int i = 0; i < n_operands; i++)
{
  for (int j = 0; j < n_operands; j++)
{
  printf ("{0x%llx,0x%llx},\n", (unsigned long long) ( ops[i] - 
ops[j]), (unsigned long long) (-(mp_limb_t) (ops[i] < ops[j])));
}
}
  printf ("};\n");


  printf ("int main ()\n{\n");
  printf ("  mp_limb_t r1, r0;\n");
  printf ("  int err = 0;\n");
  printf ("  size_t ind = 0;\n");
  printf ("  for (size_t i = 0; i < %zu; i++)\n", n_functions);
  printf ("{\n");
  printf ("  int ii = i / %zu, jj = i %% %zu;\n", n_operands, n_operands);
  printf ("  funcs[i](, );\n");
  printf ("  if (r0 != ref[ind][0] || r1 != ref[ind][1]) {\n");
  printf (" gmp_printf (\"error for f%%zu(0x%%Mx,0x%%Mx): want 
(0x%%Mx,0x%%Mx) got (0x%%Mx,0x%%Mx)\\n\", i, ops[ii], ops[jj], ref[ind][1], 
ref[ind][0], r1, r0);\n");
  printf (" err++;\n");
  printf ("   }\n");
  printf ("  ind++;\n");
  printf ("}\n");


  printf ("  return err != 0;\n");
  printf ("}\n");
  return 0;
}


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
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

[Paul Zimmermann]

   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?

in MPFR we have 15 places where we call sub_ddmmss, among which 8 have bl=0:

$ grep sub_ddmmss *.[ch] | grep -v "mpfr-longlong" | grep -v "mpfr-gmp"
div.c:  sub_ddmmss (h, l, u0, 0, h, l);
div.c:sub_ddmmss (h, l, u0, 0, h, l);
div.c:sub_ddmmss (r3, r2, r3, r2, v1, v0);
div.c:  sub_ddmmss (s1, s0, s1, s0, v1, v0);
invsqrt_limb.h:sub_ddmmss (_h, _l, _u, 0, _h, _l); \
invsqrt_limb.h:sub_ddmmss (_h, _l, _h, _l, _r >> 60, _r << 4); \
invsqrt_limb.h:sub_ddmmss (_h, _l, _h, _l, 0, 64); \
invsqrt_limb.h:sub_ddmmss (_h, _l, _h, _l, _r >> 61, _r << 3); \
invsqrt_limb.h:sub_ddmmss (_h, _l, _h, _l, 0, 16); \
invsqrt_limb.h:sub_ddmmss (_h, _l, _h, _l, _r >> 62, _r << 2); \
invsqrt_limb.h:sub_ddmmss (_h, _l, _h, _l, 0, 4);  \
invsqrt_limb.h:sub_ddmmss (_h, _l, _h, _l, _r >> 63, (_r << 1) + 1);   \
rec_sqrt_limb.h:sub_ddmmss (_h, _l, 0x4000UL, 0, _h, _l);   
\
sqrt.c:  sub_ddmmss (rb, sb, u0, 0, rb, sb);
sqrt.c:  sub_ddmmss (rb, sb, u0, low, rb, sb);

Best regards,
Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Torbjörn Granlund]

ni...@lysator.liu.se (Niels Möller) writes:

  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.

The error we struck here for ARM and (one of the errors) for PPC was
that we added 0 instead of subtracting zero, the latter meaning adding
~0 + 1.

Using the ARM "subs rd,rm,imm12" instruction, we compute

{cout, rd} = rm + ~imm + 1

while the "adds rd,rm,imm12" instruction, we compute

{cout, rd} = rm + imm

.  which is quite different.  The former will for example always set
cout when rm = imm = 0 as in Vincent's example.  The latter will never
set carry when imm = 0 or rm = 0;


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
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

[Torbjörn Granlund]

Vincent Lefevre  writes:

  On 2020-06-17 11:04:26 +0200, Niels Möller wrote:
  > 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

  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.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Vincent Lefevre]

On 2020-06-17 11:04:26 +0200, Niels Möller wrote:
> 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

This is a - b - borrow, where the borrow is the complement of the
carry bit.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Torbjörn Granlund]

ni...@lysator.liu.se (Niels Möller) writes:

  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

Here we traded non-borrow subtract and non-carry addition on both ARM
and PPC.

Subtract is defined on both these architectures as

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

while addition is refined similarly as

{cout, r} = a + b

.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
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: bug in longlong.h for aarch64 sub_ddmmss

[Paul Zimmermann]

   Dear Torbjörn,

> This bug comes untimely for me.  I consider a major purge along the
> lines of the patch below. [...]

I confirm all MPFR 4.1.0-rc1 tests pass on gcc115 with this patch applied to
mpfr-longlong.h, both with GCC 9.1.0 and 10.1.0 (they failed with GCC 9.1.0),
where mpfr-longlong.h was copied from GMP 6.2.0, with minor changes.

If not already present, maybe some tests of the longlong.h routines that
use builtin_constant_p would be useful?

Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Torbjörn Granlund]

Vincent Lefevre  writes:

  Note: in the tests, it is important to test the macro on constants
  in order to test the "if" case.

Indeed, and one macro expansion per trivial function or else gcc might
get the idea cse constants.

This bug comes untimely for me.  I consider a major purge along the
lines of the patch below.

If you Vincent have the time to go through these cases to see what can
safely remain, that would be useful.

*** /tmp/extdiff.sqiwiR/gmp-main.89ed9376523e/longlong.hThu Jun 11 
15:53:20 2020
--- /home/tege/prec/gmp-main/longlong.h Tue Jun 16 15:59:10 2020
***
*** 436,453 
  && W_TYPE_SIZE == 32
  #define add_ss(sh, sl, ah, al, bh, bl) \
!   do {
\
! if (__builtin_constant_p (bl) && -(USItype)(bl) < 0x100)  \
!   __asm__ ("subs\t%1, %4, %5\n\tadc\t%0, %2, %3"  \
   : "=r" (sh), "=" (sl)  \
!  : "r" (ah), "rI" (bh),   \
!"%r" (al), "rI" (-(USItype)(bl)) __CLOBBER_CC);\
! else  \
!   __asm__ ("adds\t%1, %4, %5\n\tadc\t%0, %2, %3"  \
!  : "=r" (sh), "=" (sl)  \
!  : "r" (ah), "rI" (bh), "%r" (al), "rI" (bl) __CLOBBER_CC);   \
!   } while (0)
  /* FIXME: Extend the immediate range for the low word by using both ADDS and
!SUBS, since they set carry in the same way.  Note: We need separate
!definitions for thumb and non-thumb to to th absense of RSC under thumb.  
*/
  #if defined (__thumb__)
  #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
--- 436,445 
  && W_TYPE_SIZE == 32
  #define add_ss(sh, sl, ah, al, bh, bl) \
!   __asm__ ("adds\t%1, %4, %5\n\tadc\t%0, %2, %3"  \
   : "=r" (sh), "=" (sl)  \
!  : "r" (ah), "rI" (bh), "%r" (al), "rI" (bl) __CLOBBER_CC)
  /* FIXME: Extend the immediate range for the low word by using both ADDS and
!SUBS, since they set carry in the same way.  We need separate definitions
!for thumb and non-thumb since thumb lacks RSC.  */
  #if defined (__thumb__)
  #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
***
*** 564,592 
 ADDS and SUBS, since they set carry in the same way.  */
  #define add_ss(sh, sl, ah, al, bh, bl) \
!   do {
\
! if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000) \
!   __asm__ ("subs\t%1, %x4, %5\n\tadc\t%0, %x2, %x3"   
\
!  : "=r" (sh), "=" (sl)  \
!  : "rZ" ((UDItype)(ah)), "rZ" ((UDItype)(bh)),\
!"%r" ((UDItype)(al)), "rI" (-(UDItype)(bl)) __CLOBBER_CC);\
! else  \
!   __asm__ ("adds\t%1, %x4, %5\n\tadc\t%0, %x2, %x3"   
\
!  : "=r" (sh), "=" (sl)  \
!  : "rZ" ((UDItype)(ah)), "rZ" ((UDItype)(bh)),\
!"%r" ((UDItype)(al)), "rI" ((UDItype)(bl)) __CLOBBER_CC);\
!   } while (0)
  #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
!   do {
\
! if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000) \
!   __asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3"   
\
!  : "=r,r" (sh), "=," (sl) \
!  : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
!"r,Z"   ((UDItype)(al)), "rI,r" (-(UDItype)(bl)) 
__CLOBBER_CC);\
! else  \
!   __asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3"   
\
!  : "=r,r" (sh), "=," (sl) \
!  : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
!"r,Z"   ((UDItype)(al)), "rI,r"  ((UDItype)(bl)) 
__CLOBBER_CC);\
!   } while(0);
  #if __GMP_GNUC_PREREQ (4,9)
  #define umul_ppmm(w1, w0, u, v) \
--- 556,568 
 ADDS and SUBS, since they set carry in the same way.  */
  #define add_ss(sh

Re: bug in longlong.h for aarch64 sub_ddmmss

[Vincent Lefevre]

On 2020-06-16 16:11:53 +0200, Vincent Lefevre wrote:
> Note that I'm rather surprised to see that the issue disappears
> if I add unrelated code. For instance, in the following testcase,
> with GCC 9.1.0 -O2, I get "h = 0x", which is
> incorrect, but if I define V, I get the correct "h = 0x0".

Defining V apparently disables some optimization, so that only
the "else" case of sub_ddmmss is used.

Note: in the tests, it is important to test the macro on constants
in order to test the "if" case.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Vincent Lefevre]

On 2020-06-16 14:47:23 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre  writes:
> 
>   On 2020-06-16 13:40:14 +0200, Torbjorn Granlund wrote:
>   > Vincent Lefevre  writes:
>   > 
>   >   #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
>   > do {  
> \
>   >   if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000)   
> \
>   > __asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" 
> \
>   >  : "=r,r" (sh), "=," (sl) 
> \
>   >  : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  
> \
>   >"r,Z"   ((UDItype)(al)), "rI,r" (-(UDItype)(bl)) 
> __CLOBBER_CC);\
>   >   else
> \
>   > __asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" 
> \
>   >  : "=r,r" (sh), "=," (sl) 
> \
>   >  : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  
> \
>   >"r,Z"   ((UDItype)(al)), "rI,r"  ((UDItype)(bl)) 
> __CLOBBER_CC);\
>   > } while(0);
>   > 
>   > The two - signs ought to be ~, I think.  Let me think a buit more about 
> that.
> 
>   Note that the "else" case, which doesn't have a - sign in its
>   arguments is affected too, AFAIK.
> 
> I cannot follow you here.
> 
> Are you saying that the asm in the else clause is broken too?
> Please explain.

Sorry, it seems OK (I thought that on (0,0), subs and adds would
be equivalent, but the carry out is actually different).

Note that I'm rather surprised to see that the issue disappears
if I add unrelated code. For instance, in the following testcase,
with GCC 9.1.0 -O2, I get "h = 0x", which is
incorrect, but if I define V, I get the correct "h = 0x0".

typedef unsigned int UDItype __attribute__ ((mode (DI)));
typedef unsigned long UWtype;
#define W_TYPE_SIZE 64
#define __GMP_DECLSPEC
#define __GMP_GNUC_PREREQ(maj, min) \
  ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))
#include 
#include "longlong.h"

int v = 0;

int main (void)
{
  volatile unsigned long u0 = 0x4000, r0 = 0x7ffd;
  unsigned long u, r, h, l;
  u = u0;
  r = r0;
  if (r < 0x8000)
r = 0x8000;
#ifdef V
  if (v)
fflush (stdout);
#endif
  umul_ppmm (h, l, r, r);
  sub_ddmmss (h, l, u, 0, h, l);
  printf ("h = 0x%lx\n", h);
  return 0;
}

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Torbjörn Granlund]

Vincent Lefevre  writes:

  On 2020-06-16 13:40:14 +0200, Torbjorn Granlund wrote:
  > Vincent Lefevre  writes:
  > 
  >   #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
  > do {  \
  >   if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000)   \
  > __asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
  >  : "=r,r" (sh), "=," (sl) \
  >  : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
  >"r,Z"   ((UDItype)(al)), "rI,r" (-(UDItype)(bl)) 
__CLOBBER_CC);\
  >   else\
  > __asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
  >  : "=r,r" (sh), "=," (sl) \
  >  : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
  >"r,Z"   ((UDItype)(al)), "rI,r"  ((UDItype)(bl)) 
__CLOBBER_CC);\
  > } while(0);
  > 
  > The two - signs ought to be ~, I think.  Let me think a buit more about 
that.

  Note that the "else" case, which doesn't have a - sign in its
  arguments is affected too, AFAIK.

I cannot follow you here.

Are you saying that the asm in the else clause is broken too?
Please explain.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Torbjörn Granlund]

Vincent Lefevre  writes:

  #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
do {  \
  if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000)   \
__asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
 : "=r,r" (sh), "=," (sl) \
 : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
   "r,Z"   ((UDItype)(al)), "rI,r" (-(UDItype)(bl)) 
__CLOBBER_CC);\
  else\
__asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
 : "=r,r" (sh), "=," (sl) \
 : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
   "r,Z"   ((UDItype)(al)), "rI,r"  ((UDItype)(bl)) 
__CLOBBER_CC);\
} while(0);

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

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: bug in longlong.h for aarch64 sub_ddmmss

[Vincent Lefevre]

On 2020-06-16 12:55:07 +0200, Vincent Lefevre wrote:
> In longlong.h from GMP 6.2.0:
> 
> #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
>   do {  \
> if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000)   \
>   __asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
>: "=r,r" (sh), "=," (sl) \
>: "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
>  "r,Z"   ((UDItype)(al)), "rI,r" (-(UDItype)(bl)) 
> __CLOBBER_CC);\
> else\
>   __asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
>: "=r,r" (sh), "=," (sl) \
>: "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
>  "r,Z"   ((UDItype)(al)), "rI,r"  ((UDItype)(bl)) 
> __CLOBBER_CC);\
>   } while(0);
> 
> I don't understand this code. For instance, on ah=al=bh=bl=0, you
> do adds(0,0), which unsets the carry. And since borrow = not(carry),
> the sbc(0,0) will return -1.

Here's a test without using MPFR:

#define W_TYPE_SIZE 64
#define __GMP_DECLSPEC
#define __GMP_GNUC_PREREQ(maj, min) \
  ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))
#include 
#include "longlong.h"

int main (void)
{
  unsigned long sh, sl;

  sub_ddmmss (sh, sl, 0, 0, 0, 0);
  printf ("%lx\n", sh);
  return 0;
}

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

bug in longlong.h for aarch64 sub_ddmmss

[Vincent Lefevre]

Hi,

In longlong.h from GMP 6.2.0:

#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
  do {  \
if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000)   \
  __asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
   : "=r,r" (sh), "=," (sl) \
   : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
 "r,Z"   ((UDItype)(al)), "rI,r" (-(UDItype)(bl)) 
__CLOBBER_CC);\
else\
  __asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
   : "=r,r" (sh), "=," (sl) \
   : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
 "r,Z"   ((UDItype)(al)), "rI,r"  ((UDItype)(bl)) 
__CLOBBER_CC);\
  } while(0);

I don't understand this code. For instance, on ah=al=bh=bl=0, you
do adds(0,0), which unsets the carry. And since borrow = not(carry),
the sbc(0,0) will return -1.

This is consistent with what I observe in MPFR with

#define MPFR_NEED_LONGLONG_H
#include "mpfr-test.h"
#include "invsqrt_limb.h"

int main (void)
{
  mp_limb_t h, l;

  sub_ddmmss (h, l, 0x4000, 0, 0x4000, 0);
  printf ("%lx\n", h);
  return 0;
}

which outputs  instead of 0.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
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

[Torbjörn Granlund]

Syed Jafri  writes:

  Thank you for your help, I used the set macros and it works perfectly.

We appreciate that you follow up with this all-is-fine message!

  The initial point of confusion for me was that the exact same code
  worked in gmp but not mini-gmp.

The two might interpret the fields somewhat differently.  Only the
documented interfaces are designed to work the same.

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

[My apology to the reporter for receiving two copies if this reply.]

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpz_gcdext bug in mini-gmp

[Torbjörn Granlund]

ni...@lysator.liu.se (Niels Möller) writes:

  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.

I reacted about using Apple's infamous clang being used, but then I
hadn't understood that the reporter had played with GMP's internal
fields, setting up broken variable states.

Let's not spend time on this until we get a self-contained bug reports
as defined in the manual, which contains a well-defined test case.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
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: mpz_gcdext bug in mini-gmp

[Torbjörn Granlund]

Syed Jafri  writes:

  Thank you for the wonderful library, I have been using mini-gmp and I
  have run into a bug with the mpz_gcdext function. The full GMP version
  gives the correct output, while the mini-gmp version of the function
  fails at line 2911 of mini-gmp.c, at the code ```assert (mpz_even_p
  (t0) && mpz_even_p (s0));```

  I have created a full reproduction with both mini-gmp and gmp, using
  the mpz_gcdext function and sample inputs at [link to external site].

Please provide all reproduction information in a follow-up email.

  I am currently using unmodified GMP and mini-GMP version 6.2.0, with
  Apple clang version 11.0. Please let me know if you need any
  additional information, I will provide it to you promptly. Looking
  forward to solving this bug as quickly as possible.

Apple clang is notorious for miscompiling things.  Please ensure you're
at the latest version of "Xcode" and by all means avoid upgrading to any
new major Xcode release.  (The latest major release which arrived with
Catalina was no exception; it miscompiled about everything, including
GMP.)

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

mpz_gcdext bug in mini-gmp

[Syed Jafri]

Hello GMP Team,

Thank you for the wonderful library, I have been using mini-gmp and I have run 
into a bug with the mpz_gcdext function. The full GMP version gives the correct 
output, while the mini-gmp version of the function fails at line 2911 of 
mini-gmp.c, at the code ```assert (mpz_even_p (t0) && mpz_even_p (s0));```

I have created a full reproduction with both mini-gmp and gmp, using the 
mpz_gcdext function and sample inputs at https://github.com/jafri/gmp-bug

I am currently using unmodified GMP and mini-GMP version 6.2.0, with Apple 
clang version 11.0. Please let me know if you need any additional information, 
I will provide it to you promptly. Looking forward to solving this bug as 
quickly as possible.

Thank you,
Syed Jafri
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: efficiency bug in mpz_powm_ui?

[Torbjörn Granlund]

Marc Glisse  writes:

  I cannot see any recent snapshot at
  https://gmplib.org/download/snapshot/ , the most recent one appears to
  be from 17-Jan-2020.

Ah, they are broken in the sense that they don't exist.  :-)

(It was a boched disabling of ftp snapshot downloads; the sync to the
web server was disabled and the sync to the ftp server was left going.
Script edit distance = 2.  We want to disable inherently unsafe ftp
downloads of unsigned stuff like the snapshots.)

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: efficiency bug in mpz_powm_ui?

[Marc Glisse]

On Mon, 2 Mar 2020, Torbjörn Granlund wrote:


paul zimmermann  writes:

 PS: while trying the above change, I noticed the daily snapshots are broken
 since January 18...

Would you mind telling us what is "broken"?


I cannot see any recent snapshot at https://gmplib.org/download/snapshot/ 
, the most recent one appears to be from 17-Jan-2020.


--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: efficiency bug in mpz_powm_ui?

[Torbjörn Granlund]

paul zimmermann  writes:

  PS: while trying the above change, I noticed the daily snapshots are broken
  since January 18...

Would you mind telling us what is "broken"?

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: efficiency bug in mpz_powm_ui?

[paul zimmermann]

   Dear Marco,

> > it seems that mpz_powm_ui is highly inefficient when BASE^EXP has about 
> > the
> > same size as MOD, in which case it could first compute BASE^EXP 
> > exactly, then
> > perform only one reduction:
> 
> You are right, mpz_powm_ui does not implement an algorithm that is 
> optimal for every possible use-case. But I'd not consider this a bug :-)
> 
> >   mpz_ui_pow_ui (x, 2, e);
> >   mpz_mod (r1, x, y);
> 
> I'm not sure that mpz_ui_pow_ui (x, 2, e) is the more efficient way to 
> obtain a value x with only the bit e set to 1 :-)
> But of course, in this context, the following _mod dominates 
> asymptotically.
> 
> >   mpz_set_ui (x, 2);
> >   mpz_powm_ui (r2, x, e, y);
> 
> Thanks to a recent change, this function should be faster now, when base 
> is 2:
> https://gmplib.org/repo/gmp/rev/63e53ddfd210

thank you, this solves the issue I reported.

> Even if there is not jet any special code for the special case "BASE^EXP 
> has about the same size as MOD".

indeed, the same issue can happen for other small values of BASE (not only 2).

Best regards,
Paul

PS: while trying the above change, I noticed the daily snapshots are broken
since January 18...
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: efficiency bug in mpz_powm_ui?

[Marco Bodrato]

Ciao,

Il 2020-02-29 11:54 paul zimmermann ha scritto:
it seems that mpz_powm_ui is highly inefficient when BASE^EXP has about 
the
same size as MOD, in which case it could first compute BASE^EXP 
exactly, then

perform only one reduction:


You are right, mpz_powm_ui does not implement an algorithm that is 
optimal for every possible use-case. But I'd not consider this a bug :-)



  mpz_ui_pow_ui (x, 2, e);
  mpz_mod (r1, x, y);


I'm not sure that mpz_ui_pow_ui (x, 2, e) is the more efficient way to 
obtain a value x with only the bit e set to 1 :-)
But of course, in this context, the following _mod dominates 
asymptotically.



  mpz_set_ui (x, 2);
  mpz_powm_ui (r2, x, e, y);


Thanks to a recent change, this function should be faster now, when base 
is 2:

https://gmplib.org/repo/gmp/rev/63e53ddfd210
Even if there is not jet any special code for the special case "BASE^EXP 
has about the same size as MOD".


Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

RE: [Possible bug in __gmpz_powm]

[Gabriel Sturzu]

Hello again,

I tried to build 6.2.0 for powerpc750 and it gives the following
compiler error:

tmp-invert_limb.s: Assembler messages:
tmp-invert_limb.s:170: Internal error, aborting at 
/home/vlad/crosstool/build/powerpc-750-linux-gnu/gcc-4.2.4-glibc-2.3.3/binutils-2.16.1/gas/config/tc-ppc.c
 line 5769 in md_apply_fix3
Please report this bug.
Makefile:768: recipe for target 'invert_limb.lo' failed
make[2]: *** [invert_limb.lo] Error 1
make[2]: Leaving directory '/home/toni/Desktop/gmp-6.2.0/mpn'
Makefile:995: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/toni/Desktop/gmp-6.2.0'
Makefile:785: recipe for target 'all' failed
make: *** [all] Error 2

I used the same configure options as for 6.0.0 which compiles
without errors, ./configure --host=powerpc750-linux and
the same CC and CXX environment variables.
The output from configure is:
 Version:   GNU MP 6.2.0
  Host type: powerpc750-unknown-linux-gnu
  ABI:   32
  Install prefix:/usr/local
  Compiler:  
/opt/cegl-4.0/powerpc-750-linux-gnu/gcc-4.2.4-glibc-2.3.3/bin/powerpc-750-linux-gnu-gcc
 -std=gnu99
  Static libraries:  yes
  Shared libraries:  yes

Also for 6.1.0 it gives the same compiler error.

 Best regards,
  Antonio


-Original Message-
From: t...@gmplib.org  
Sent: Tuesday, January 28, 2020 9:15 PM
To: Gabriel Sturzu 
Cc: gmp-bugs@gmplib.org; Bogdan Cap-Bun 
Subject: Re: [Possible bug in __gmpz_powm]

[EXTERNAL]

Gabriel Sturzu  writes:

Version:   GNU MP 6.0.0

That is an obsolete GMP release.  Please try a current release, preferably 
6.2.0.

--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

[Possible bug in __gmpz_powm]

[Gabriel Sturzu]

Hello there,

My name is Antonio-Gabriel Sturzu and I work for Keysight.
Recently I found some invalid reads and writes by running our ikev1 
implementation with
valgrind on PowerPC hardware.
The source of the problem seems to be the mpz_powm function
for all the invalid reads and writes.
In order to be sure that the source of the invalid reads and writes is not our 
own software
I have written a sample test program , I ran it with valgrind on PowerPC and I 
have attached the output file
from valgrind.  I also ran the program with valgrind on other hardware like 
MIPS-64 or x86-64 and the output
file is clean. It doesn't have any invalid reads or writes.
In conclusion, the issue seems to be only on Power-Pc. The problem seems to 
appear when all the operands are really big numbers.
When I used a small modulo value it didn't give any invalid reads or writes. 
The result is correct even when I use valgrind , the same as in x86 or MIPS-64.
The compiler that I used was powerpc-750-linux-gnu-gcc version 4.2.4.
The GMP version that I used is 6.0.0.
The output from uname -a is ppc GNU/Linux 2.6.7.
The output from running ./config.guess is coreihwl-unknown-linux-gnu.
The output from running ./configfsf.guess is x86_64-unknown-linux-gnu.
The configure summary build options from running ./configure are :

  Version:   GNU MP 6.0.0
  Host type: coreihwl-unknown-linux-gnu
  ABI:   64
  Install prefix:/usr/local
  Compiler:  gcc
  Static libraries:  yes
  Shared libraries:  yes

After compiling and linking with the PowerPC gmp library you just run 
./executable_name. You don't need anything else.
I hope you have enough information to see if this is a real bug or not.

 Best 
regards,
   
Antonio -Gabriel Sturzu


#include 
#include 
#include 
#include "gmp.h"

uint8_t v1[] = {0x02};
uint8_t v2[] = { 
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xC9,0x0F,0xDA,0xA2,0x21,0x68,0xC2,0x34,

0xC4,0xC6,0x62,0x8B,0x80,0xDC,0x1C,0xD1,0x29,0x02,0x4E,0x08,0x8A,0x67,0xCC,0x74,

0x02,0x0B,0xBE,0xA6,0x3B,0x13,0x9B,0x22,0x51,0x4A,0x08,0x79,0x8E,0x34,0x04,0xDD,

0xEF,0x95,0x19,0xB3,0xCD,0x3A,0x43,0x1B,0x30,0x2B,0x0A,0x6D,0xF2,0x5F,0x14,0x37,

0x4F,0xE1,0x35,0x6D,0x6D,0x51,0xC2,0x45,0xE4,0x85,0xB5,0x76,0x62,0x5E,0x7E,0xC6,

0xF4,0x4C,0x42,0xE9,0xA6,0x3A,0x36,0x20,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF};

uint8_t v3[] = { 
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xC9,0x0F,0xDA,0xA2,0x21,0x68,0xC2,0x34,

0xC4,0xC6,0x62,0x8B,0x80,0xDC,0x1C,0xD1,0x29,0x02,0x4E,0x08,0x8A,0x67,0xCC,0x74,

0x02,0x0B,0xBE,0xA6,0x3B,0x13,0x9B,0x22,0x51,0x4A,0x08,0x79,0x8E,0x34,0x04,0xDD,

0xEF,0x95,0x19,0xB3,0xCD,0x3A,0x43,0x1B,0x30,0x2B,0x0A,0x6D,0xF2,0x5F,0x14,0x37,

0x4F,0xE1,0x35,0x6D,0x6D,0x51,0xC2,0x45,0xE4,0x85,0xB5,0x76,0x62,0x5E,0x7E,0xC6,

0xF4,0x4C,0x42,0xE9,0xA6,0x3A,0x36,0x20,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF};

int main()
{
mpz_t a, b, c, res;

mpz_init(a);
mpz_init(b);
mpz_init(c);
mpz_init(res);
mpz_import(a, sizeof(v1), 1, 1, 1, 0, v1);
mpz_import(b, sizeof(v2), 1, 1, 1, 0, v2);
mpz_import(c, sizeof(v3), 1, 1, 0, 0, v3);
mpz_powm(res, a, b, c);
printf("%s\n", mpz_get_str(NULL, 10, res));
return 0;
}
==904== Memcheck, a memory error detector
==904== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==904== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==904== Command: ./gmp-test
==904== Parent PID: 899
==904== 
==904== Invalid write of size 4
==904==at 0x10026F18: __gmpn_addmul_1 (in /shared/port/gmp-test)
==904==by 0x10004EE3: __gmpn_sqr_basecase (in /shared/port/gmp-test)
==904==by 0x100049D3: __gmpn_sqr (in /shared/port/gmp-test)
==904==by 0x10024D2B: __gmpn_powm (in /shared/port/gmp-test)
==904==by 0x10001CCB: __gmpz_powm (in /shared/port/gmp-test)
==904==by 0x170F: main (in /shared/port/gmp-test)
==904==  Address 0x7effe730 is on thread 1's stack
==904==  32 bytes below stack pointer
==904== 
==904== Invalid read of size 4
==904==at 0x10026FEC: __gmpn_addmul_1 (in /shared/port/gmp-test)
==904==by 0x10004EE3: __gmpn_sqr_basecase (in /shared/port/gmp-test)
==904==by 0x100049D3: __gmpn_sqr (in /shared/port/gmp-test)
==904==by 0x10024D2B: __gmpn_powm (in /shared/port/gmp-test)
==904==by 0x10001CCB: __gmpz_powm (in /shared/port/gmp-test)
==904==by 0x170F: main (in /shared/port/gmp-test)
==904==  Address 0x7effe730 is on thread 1's stack
==904==  

Re: [Possible bug in __gmpz_powm]

[Torbjörn Granlund]

Gabriel Sturzu  writes:

Version:   GNU MP 6.0.0

That is an obsolete GMP release.  Please try a current release,
preferably 6.2.0.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: possible bug

[Torbjörn Granlund]

David Joyner  writes:

  Errors are below. Just reporting this as requested.

Note that there is also a link displayed which points to the page on how
to create meaningful GMP bug reports.  Please read it.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

possible bug

[David Joyner]

Hi:

I'm trying to compile gcc using homebrew on mac 10,15.1
with Xcode 11.1 installed (xcode-select version 2370). This is on a
late 2013 macbook pro. It seems to fail on gmp.

Errors are below. Just reporting this as requested.

- David


jeeves:wodehouse wdj$ brew install gcc

Warning: You are using OS X 10.15.

We do not provide support for this pre-release version.

You may encounter build failures or other breakages.

Please create pull-requests instead of filing issues.

*==>** Installing dependencies for gcc: **gmp, mpfr, libmpc, isl*

*==>** Installing gcc dependency: **gmp*

*==>** Downloading https://gmplib.org/download/gmp/gmp-6.1.1.tar.xz
*

Already downloaded: /Users/wdj/Library/Caches/Homebrew/gmp-6.1.1.tar.xz

*==>** ./configure --prefix=/usr/local/Cellar/gmp/6.1.1 --enable-cxx*

*==>** make*

*==>** make check*

Last 15 lines from /Users/wdj/Library/Logs/Homebrew/gmp/03.make:

# SKIP:  0

# XFAIL: 0

# FAIL:  2

# XPASS: 0

# ERROR: 0



See tests/mpn/test-suite.log

Please report to gmp-bugs@gmplib.org, see
https://gmplib.org/manual/Reporting-Bugs.html



make[5]: *** [test-suite.log] Error 1

make[4]: *** [check-TESTS] Error 2

make[3]: *** [check-am] Error 2

make[2]: *** [check-recursive] Error 1

make[1]: *** [check-recursive] Error 1

make: *** [check] Error 2
___
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?

[Torbjörn Granlund]

ni...@lysator.liu.se (Niels Möller) writes:

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

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


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
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: bug in gmp_fprintf still in next release?

[paul zimmermann]

> From: t...@gmplib.org (Torbjörn Granlund)
> Date: Fri, 27 Sep 2019 14:06:34 +0200
> 
> Marc Glisse  writes:
> 
>   The report was also about mpz_get_str, which does not have this
>   limitation. And for printf, it should be possible to make it print
>   correctly and return a nonsense integer.
> 
> Maybe.
> 
> But we cannot make %* type arguments work, easily.  It will be limping
> unless we change int to size_t (or some such).

it would be a great progress if the limits of mpz_get_str/mpz_set_str were
raised, and if the limitations of gmp_*printf (if any) were documented.

Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs