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

[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

Re: bug in __gmp_replacement_vsnprintf

[Niels Möller]

Paul Zimmermann  writes:

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

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

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

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

Regards,
/Niels

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

Re: 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, sl, ah, al, bh, bl) \
!   __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)
  #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
!   __asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3"   \
!  : "=r,r" (sh), "=," (sl) \
!  : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" 

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

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

Re: bug in gmp_fprintf still in next release?

[Marc Glisse]

On Fri, 27 Sep 2019, Torbjörn Granlund wrote:


paul zimmermann  writes:

 four years ago [1] I reported an issue with gmp_fprintf in GMP 6.1.0,
 which cannot print correcly a number of 8589934589 bits (less than 2^33).

 I just checked with today's snapshot: the issue is still there.

Yikes!

 Will the next GMP release be still limited to less than 2^33 bits?

Probably.

I believe the issue is the printf family's use of 'int' for sizes.  We
cannot really get around that in gmp_*printf* while staying compatible.
(I assume it was poor design by us in the first place not to use some
wider signed type.)


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.


--
Marc Glisse
___
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]

paul zimmermann  writes:

  four years ago [1] I reported an issue with gmp_fprintf in GMP 6.1.0,
  which cannot print correcly a number of 8589934589 bits (less than 2^33).

  I just checked with today's snapshot: the issue is still there.

Yikes!

  Will the next GMP release be still limited to less than 2^33 bits?

Probably.

I believe the issue is the printf family's use of 'int' for sizes.  We
cannot really get around that in gmp_*printf* while staying compatible.
(I assume it was poor design by us in the first place not to use some
wider signed type.)

-- 
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/mpfr/mpc, never ending ctan computation

[Vincent Lefevre]

On 2018-11-19 15:26:00 +0100, Richard Biener wrote:
> On Mon, 19 Nov 2018, Vincent Lefevre wrote:
> > AFAIK, GCC already changes the exponent range to the binary64 one
> > (the lack of subnormals is not an issue, because in case of underflow,
> > GCC ignores the computations done with MPFR).
> 
> GCC does ignore results in case of overflow or underflow but it
> doesn't currently limit mpfrs exponent range.  Or rather most
> languages don't - I do see mpfr_set_e{min,max} calls being
> done in the Fortran frontend only, but only temporarily and
> seemingly only to call mpfr_subnormalize.

Thanks for the clarification. FYI, mpfr_subnormalize was added
for gfortran.

> > But for its internal computations, I assume that mpc extends the
> > exponent range (if it didn't you would have the same kind of problem,
> > but much more often). Here it seems that the issue is that the maximum
> > supported exponent range is not large enough for the chosen algorithm
> > (which may not be the right one for this kind of input).
> 
> It happens that limiting the range makes the CPOW computation fast.

Yes, because for some functions, underflow or overflow can be detected
before the actual computation.

-- 
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 gmp/mpfr/mpc, never ending ctan computation

[Dennis Clarke]

On 11/19/18 5:40 AM, Torbjörn Granlund wrote:

Richard Biener  writes:

   > __real x = 3.09126495087690770626068115234375e+8;
   > __imag x = -4.045689747817175388336181640625e+8;
   > volatile _Complex double y = ctan (x);
   > return 0;
   >   }
   >
   > If we get a test case somewhat closer to GMP, then it is likely
   > somebody will look at it.
   >
   > I expect the maintainers of library called by gcc (mpc?) would be helped
   > by seeing the actual call to their library.

   OK, I can reproduce the issue with mpc 1.1.0, mpfr 3.1.4 and gmp 6.1.0
   using

   #include 
   #include 

   int main()
   {
 mpc_t m;
 mpc_init2 (m, 53);
 mpfr_set_str (mpc_realref (m), "3.09126495087690770626068115234375e+8",
   10, GMP_RNDN);
 mpfr_set_str (mpc_imagref (m), "-4.045689747817175388336181640625e+8",
   10, GMP_RNDN);
 mpfr_clear_flags ();
 mpc_tan (m, m, 0);
 return 0;
   }


using that test I see 100% cpu and slowly growing RSS with a lot of time 
being spent inside mpn_fft_fft and then mpn_fft_mul_2exp_modF :


Program received signal SIGINT, Interrupt.
0x0008002dcd04 in __gmpn_copyi () from 
/home/dclarke/local/lib/libgmp.so.10

(gdb) where
#0  0x0008002dcd04 in __gmpn_copyi ()
   from /home/dclarke/local/lib/libgmp.so.10
#1  0x00080029a021 in mpn_fft_mul_2exp_modF (r=0x800e47610, 
a=0x80150bcb0,

d=1600, n=40) at mul_fft.c:267
#2  0x00080029a3f0 in mpn_fft_fft (Ap=0x800e8e130, K=32, 
ll=0x800e00098,

omega=160, n=40, inc=16, tp=0x800e47610) at mul_fft.c:391
#3  0x00080029a351 in mpn_fft_fft (Ap=0x800e8dc30, K=64, 
ll=0x800e000a0,

omega=80, n=40, inc=8, tp=0x800e47610) at mul_fft.c:383
#4  0x00080029a3b2 in mpn_fft_fft (Ap=0x800e8dc10, K=128, 
ll=0x800e000a8,

omega=40, n=40, inc=4, tp=0x800e47610) at mul_fft.c:384
#5  0x00080029a351 in mpn_fft_fft (Ap=0x800e8dc10, K=256, 
ll=0x800e000b0,

omega=20, n=40, inc=2, tp=0x800e47610) at mul_fft.c:383
#6  0x00080029a351 in mpn_fft_fft (Ap=0x800e8dc10, K=512, 
ll=0x800e000b8,

omega=10, n=40, inc=1, tp=0x800e47610) at mul_fft.c:383
#7  0x0008002995ff in mpn_mul_fft_internal (op=0x8014d4150, pl=9728, 
k=9,
Ap=0x800e8dc10, Bp=0x800e8b410, A=0x8014fd610, B=0x801060950, 
nprime=40,

l=19, Mp=5, fft_l=0x800e00070, T=0x800e47610, sqr=1) at mul_fft.c:738
#8  0x000800298ef8 in __gmpn_mul_fft (op=0x8014d4150, pl=9728,
n=0x801336980, nl=9475, m=0x801336980, ml=9475, k=9) at mul_fft.c:904
#9  0x0008002cc6d6 in __gmpn_sqrmod_bnm1 (rp=0x8014a8500, rn=19456,
ap=0x801336980, an=9475, tp=0x8014d4150) at sqrmod_bnm1.c:194
#10 0x00080029c568 in __gmpn_nussbaumer_mul (pp=0x8014a8500,
ap=0x801336980, an=9475, bp=0x801336980, bn=9475) at 
nussbaumer_mul.c:61

--Type  for more, q to quit, c to continue without paging--
#11 0x00080029b80f in __gmpn_sqr (p=0x8014a8500, a=0x801336980, n=9475)
at sqr.c:97
#12 0x000800371726 in mpfr_sqrhigh_n (rp=0x801483500, np=0x801324180,
n=18947) at mulders.c:180
#13 0x00080031c0ab in mpfr_mul (a=0x7fffde50, b=0x7fffde50,
c=0x7fffde50, rnd_mode=MPFR_RNDD) at mul.c:968
#14 0x00080036b2c0 in mpfr_sqr (a=0x7fffde50, b=0x7fffde50,
rnd_mode=MPFR_RNDD) at sqr.c:561
#15 0x000800312bd0 in mpfr_exp_3 (y=0x7fffe350, x=0x7fffe380,
rnd_mode=MPFR_RNDD) at exp3.c:232
#16 0x00080031487f in mpfr_exp (y=0x7fffe350, x=0x7fffe380,
rnd_mode=MPFR_RNDD) at exp.c:176
#17 0x00080033a525 in mpfr_sinh_cosh (sh=0x7fffe550,
ch=0x7fffe530, xt=0x7fffe880, rnd_mode=MPFR_RNDN)
at sinh_cosh.c:108
#18 0x0008003bf37b in mpc_sin_cos (rop_sin=0x7fffe7e0,
rop_cos=0x7fffe7a0, op=0x7fffe860, rnd_sin=17, rnd_cos=17)
at sin_cos.c:390
#19 0x0008003c3756 in mpc_tan (rop=0x7fffe860, op=0x7fffe860,
rnd=0) at tan.c:196
#20 0x002013c0 in main () at test_case.c:19
(gdb) quit
A debugging session is active.

Inferior 1 [process 58829] will be killed.

Quit anyway? (y or n) y
titan$

This is gmp 6.1.2 and mpfr-4.0.1-p13 and mpc-1.1.0 on FreeBSD 12.0RC1
 and I also see similar behavior on Solaris SPARC.



I simplified your test case using 1 as the real part and an integer for
the imaginary part.  With the real part set to 1, the computation
finishes in about 10 seconds, with every doubling of it the runtime
almost triples.  (If my observation generalises to an extended real part
range, the compilation for your test case should terminate in about
10*3^log2(4.045689747817175388336181640625e+8/1)/3600/24/365 years.)



Well the test case provided merely packs up and goes away with no
indication that it will return anytime soon.

I am just going to watch this thread closely.

Dennis

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

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

[Richard Biener]

On Mon, 19 Nov 2018, Vincent Lefevre wrote:

> On 2018-11-19 14:17:13 +0100, Niels Möller wrote:
> > You might want to add an entry for "Exponent range" to the concept index
> > in the manual.
> 
> The concept index already has "Exponent", and the corresponding
> paragraph is:
> 
>An “exponent” is a component of a regular floating-point number.  Its
> C data type is ‘mpfr_exp_t’.  Valid exponents are restricted to a subset
> of this type, and the exponent range can be changed globally as
> described in *note Exception Related Functions::.  Special values do not
> have an exponent.
> 
> I think that this is quite explicit.
> 
> > I guess gcc should set things up similarly to the example on that page,
> > "This is an example of how to emulate binary double IEEE 754
> > arithmetic", with the caveat "This emulates a double IEEE 754 arithmetic
> > with correct rounding in the subnormal range, which may not be the case
> > for your hardware".
> 
> AFAIK, GCC already changes the exponent range to the binary64 one
> (the lack of subnormals is not an issue, because in case of underflow,
> GCC ignores the computations done with MPFR).

GCC does ignore results in case of overflow or underflow but it
doesn't currently limit mpfrs exponent range.  Or rather most
languages don't - I do see mpfr_set_e{min,max} calls being
done in the Fortran frontend only, but only temporarily and
seemingly only to call mpfr_subnormalize.

> But for its internal computations, I assume that mpc extends the
> exponent range (if it didn't you would have the same kind of problem,
> but much more often). Here it seems that the issue is that the maximum
> supported exponent range is not large enough for the chosen algorithm
> (which may not be the right one for this kind of input).

It happens that limiting the range makes the CPOW computation fast.

Richard.

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

[Richard Biener]

On Mon, 19 Nov 2018, Niels Möller wrote:

> Vincent Lefevre  writes:
> 
> > MPFR has a bounded (user configurable) exponent range, with underflow
> > and overflow exceptions for out-of-range results, like in IEEE 754.
> 
> Good! I didn't find that in the manual until I knew the phrase to search
> for. It's in
> https://www.mpfr.org/mpfr-current/mpfr.html#Exception-Related-Functions,
> and relevant functions are mpfr_set_emin, mpfr_set_emax and mpfr_subnormalize.
> 
> You might want to add an entry for "Exponent range" to the concept index
> in the manual.

Indeed I didn't find these functions either ...

> I guess gcc should set things up similarly to the example on that page,
> "This is an example of how to emulate binary double IEEE 754
> arithmetic", with the caveat "This emulates a double IEEE 754 arithmetic
> with correct rounding in the subnormal range, which may not be the case
> for your hardware".

OK, GCC doesn't use those, for the testcase if I set emax/emin to the
range from 128bit IEEE then the folding finishes quickly.

It looks like emin/emax is global and not per mpfr_t so for GCC we
have to jump through some additional hoops.  I'll see to adjust
GCC to set the limits based on the maximum range ever needed
(largest FP mode supported by the target) and look for fallout.

Richard.

> Regards,
> /Niels
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

[Vincent Lefevre]

On 2018-11-19 12:49:12 +0100, Richard Biener wrote:
> I see.  So I guess one issue might be that mpfr numbers have a
> precision (mantissa bits?) but no restriction on the exponent?

MPFR has a bounded (user configurable) exponent range, with underflow
and overflow exceptions for out-of-range results, like in IEEE 754.

-- 
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 gmp/mpfr/mpc, never ending ctan computation

[Richard Biener]

On Mon, 19 Nov 2018, Torbjörn Granlund wrote:

> Richard Biener  writes:
> 
>   :/  But then with GCC we want deterministic behavior -- ISL
>   added some "computation budget" and error reporting if that was
>   taken up.  Maybe gmp/mpfr/mpc could consider adding such a thing
>   (reporting budget overruns via a signal could be acceptable if
>   the API churn would be too bad for another way).
> 
> I'll leave this up to the mpc maintainers.
> 
>   > I simplified your test case using 1 as the real part and an integer for
>   > the imaginary part.  With the real part set to 1, the computation
>   > finishes in about 10 seconds, with every doubling of it the runtime
>   > almost triples.  (If my observation generalises to an extended real part
>   > range, the compilation for your test case should terminate in about
>   > 10*3^log2(4.045689747817175388336181640625e+8/1)/3600/24/365 years.)
> 
>   Ick.  I wonder if the actual ctan result is infinite or we just
>   fail to compute it in an efficient manner...
> 
> The result should be extremely small, so returning Inf would be
> quite inaccurate.  :-)

I see.  So I guess one issue might be that mpfr numbers have a
precision (mantissa bits?) but no restriction on the exponent?
That is, for ctan eventually zero _is_ a validly rounded result
and the computation should simply terminate...

Richard.

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

[Torbjörn Granlund]

Richard Biener  writes:

  :/  But then with GCC we want deterministic behavior -- ISL
  added some "computation budget" and error reporting if that was
  taken up.  Maybe gmp/mpfr/mpc could consider adding such a thing
  (reporting budget overruns via a signal could be acceptable if
  the API churn would be too bad for another way).

I'll leave this up to the mpc maintainers.

  > I simplified your test case using 1 as the real part and an integer for
  > the imaginary part.  With the real part set to 1, the computation
  > finishes in about 10 seconds, with every doubling of it the runtime
  > almost triples.  (If my observation generalises to an extended real part
  > range, the compilation for your test case should terminate in about
  > 10*3^log2(4.045689747817175388336181640625e+8/1)/3600/24/365 years.)

  Ick.  I wonder if the actual ctan result is infinite or we just
  fail to compute it in an efficient manner...

The result should be extremely small, so returning Inf would be
quite inaccurate.  :-)

-- 
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/mpfr/mpc, never ending ctan computation

[Torbjörn Granlund]

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

  I simplified your test case using 1 as the real part and an integer for
  the imaginary part.  With the real part set to 1, the computation
  finishes in about 10 seconds, with every doubling of it the runtime
  almost triples.  (If my observation generalises to an extended real part
  range, the compilation for your test case should terminate in about
  10*3^log2(4.045689747817175388336181640625e+8/1)/3600/24/365 years.)

I meant to write:

I simplified your test case using 1 as the real part and an integer for
the imaginary part.  With the imaginary part set to 1, the computation
finishes in about 10 seconds, with every doubling of it the runtime almost
triples.  (If my observation generalises to an extended imaginary part
range, the compilation for your test case should terminate in about
10*3^log2(4.045689747817175388336181640625e+8/1)/3600/24/365 years.)

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

[Torbjörn Granlund]

Vaibhav Gautam  writes:

  PLEASE HELP!
  
The GMP developers cannot handle Microsoft's proprietary file formats,
and thus cannot read your attachments.

Plain old text is what you need to send in your message and in your
attachments.  Make sure you spell out what you think it wrong, a bunch
of attachments (even readable ones) might not immediately reveal the
perceived problem.


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

Re: Bug Upon Make Check

[Marco Bodrato]

Ciao,

Il Dom, 19 Marzo 2017 6:41 pm, David Hadaller ha scritto:

> 1 of 58 tests failed

With test? You are not giving any information...

> make[4]: Leaving directory '/home/david/Downloads/gmp-4.3.2/tests/mpz'

... anyway, the last release is GMP-6.1.2, please try that.

Have a nice GMP experience :-)
m

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