Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240
Hi, gmp 6.3.0 does not compile on this machine: zimmerma@cfarm240:~/gmp-6.3.0 $ ./configure checking build system type... Invalid configuration 'aarch64c-unknown-freebsd14.0': machine 'aarch64c-unknown' not recognized configure: error: /bin/sh ./config.sub aarch64c-unknown-freebsd14.0 failed Should I try a specific ABI? Paul > Date: Wed, 23 Aug 2023 14:14:47 -0500 > From: CFarm Annoucements via cfarm-announces > > Cc: CFarm Annoucements > > The Compile Farm project is pleased to announce the immediate > availability of cfarm240, an Arm Morello SoC [1] prototype board > running CheriBSD (a FreeBSD derivative). > > This system-on-chip research platform [2] features a custom > quad-core aarch64 Neoverse N1-based CPU implementing CHERI [3] > (a memory protection model), and has 32GB system memory. Disk > space is limited (~200GB); be mindful of your resource usage. > > We are still in the process of transitioning to our new domain > name and website; please SSH to cfarm240.cfarm.net. > > Notes: > > * Morello boards are the only physical implementation of this > ISA; lessons learned will be carried to future Arm extensions, > so binary compatibility with Morello is not guaranteed. > > * You will want to read about packages [4]. > > * If you need help with CHERI-specific problems (not Compile > Farm issues), consider joining their Slack [5]. > > Thank you to the University of Cambridge for hosting > (and developing) this machine! > > > [1]: https://www.arm.com/architecture/cpu/morello > [2]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html > [3]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ > [4]: > https://ctsrd-cheri.github.io/cheribsd-getting-started/packages/index.html > [5]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-slack.html > ___ > cfarm-announces mailing list > cfarm-announ...@lists.tetaneutral.net > https://lists.tetaneutral.net/listinfo/cfarm-announces > ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
bug in __gmp_replacement_vsnprintf
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
Re: GMP Error Reporting
Hi, it appears the value of c3 before the call mpf_sqrt() is negative, and mpf_sqrt() does not allow negative inputs. Best regards, Paul Zimmermann > From: "posihydr" > Date: Sat, 19 Aug 2023 21:50:37 +0800 > > > [1:text/plain Hide] > > A description of the problem: > The problem occurs when the formula in GMP and < Picture 1 is used to > calculate PI, calculate the constant C to the 3/2 power, output "Floating > point exception" after running the program, and use GDB debugging to find > that the program receives signal SIGFPE when calling mpf_sqrt function. > The following is written according to the > https://gmplib.org/manual/Reporting-Bugs report: > 1. GMP Version number: 6.3.0 (not prepackaged and not patched) > 2. The test program is 3. The program crashes directly > 4. < Picture 2 > 5. None > 6../configure --prefix=/opt/gmp-6.3.0 > 7. I can't provide the information as it was built > 8. < Picture 3 > 9. < Picture 3 > 10. aarch64-unknown-linux-gnu > 11. None > 12. None > > > It was translated from Chinese by Youdao. > > [2:application/octet-stream Show Save:bug.c (975B)] > > > [3:application/octet-stream Show Save:Picture 1.jpg (140kB)] > > > [4:application/octet-stream Show Save:Picture 2.jpg (426kB)] > > > [5:application/octet-stream Show Save:Picture 3.jpg (466kB)] > > > [6: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
bug in __gmp_replacement_vsnprintf
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
IEEE P754
Hi, the reference manual mentions IEEE P754, which was the temporary name during the standard first version (Project 754 I guess). It should be replaced by IEEE 754, or better IEEE 754-2019 (the latest revision). Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: bug
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
(<https://www.mpfr.org/>) 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
issue with Microsoft compiler
Hi, someone reported to me the following issue: Microsoft (R) C/C++ Optimizing Compiler Version 19.34.31937 for x64 will not compile line 2230 in gmp.h: *__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK; giving error C4146: unary minus operator applied to unsigned type, result still unsigned. Just in case this warning can be avoided. Best regards, Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
bug in __gmp_replacement_vsnprintf
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
bug in __gmp_replacement_vsnprintf
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: GMP does not detect float exponent overflow while reading floating point numbers
Hi Eric,
> GMP version: gmp-6.2.1-2.fc36.x86_64, installed using dnf on Fedora 36.
> Test program: a.c and b.cpp, see attachment.
> To run a.c, use "gcc a.c -o a -lgmp && ./a". The output on my machine
> is "0.1e-3215911262793760767".
> To run b.cpp, use "g++ b.cpp -o b -lgmp -lgmpxx && ./b". The output on
> my machine is "1e+-1294967296".
> The results are wrong because I entered a very large number, but got a
> number between 0 and 1. I am expecting GMP to return an error in
> mpf_init_set_str() indicating that the exponent is too large.
on gmplib.org you can read:
High-level floating-point arithmetic functions (mpf). This is the GMP function
category to use if the C type `double' doesn't give enough precision for an
application. There are about 70 functions in this category. New projects should
strongly consider using the much more complete GMP extension library mpfr
instead of mpf.
Indeed with the following MPFR program you will get:
$ gcc -g /tmp/b.c -lmpfr
$ ./a.out
@Inf@
$ cat /tmp/b.c
#include
#include
#include
int main(void) {
mpfr_t f;
const char *s = "1e300";
mpfr_init_set_str(f, s, 10, MPFR_RNDN);
mpfr_out_str (stdout, 10, 100, f, MPFR_RNDN);
printf("\n");
}
Hope this helps,
Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mini-gmp mpz_powm incorrect result
thank you, I confirm the bug, here is a potential fix:
$ diff -u mini-gmp.c.orig mini-gmp.c
--- mini-gmp.c.orig 2022-08-29 10:28:20.700995412 +0200
+++ mini-gmp.c 2022-08-29 10:27:36.112191428 +0200
@@ -3060,6 +3060,7 @@
if (en == 0)
{
mpz_set_ui (r, 1);
+ mpz_tdiv_r (r, r, m);
return;
}
Paul
> From: Guido Vranken
> Date: Sun, 28 Aug 2022 16:22:40 +0200
>
> The following program computes 1^0 % 1:
>
> //#include
> #include "mini-gmp.c"
> #include
>
> #define CF_CHECK_EQ(expr, res) if ( (expr) != (res) ) { goto end; }
>
> int main(void)
> {
> mpz_t a, b, c, res;
> char* s = NULL;
> /* noret */ mpz_init(a);
> /* noret */ mpz_init(b);
> /* noret */ mpz_init(c);
> /* noret */ mpz_init(res);
>
> CF_CHECK_EQ(mpz_set_str(a, "1", 10), 0);
> CF_CHECK_EQ(mpz_set_str(b, "0", 10), 0);
> CF_CHECK_EQ(mpz_set_str(c, "1", 10), 0);
> CF_CHECK_EQ(mpz_set_str(res, "0", 10), 0);
>
> /* noret */ mpz_powm(res, a, b, c);
>
> printf("%s\n", mpz_get_str(NULL, 10, res));
> end:
> return 0;
> }
>
> The result should be 0, which is the case with regular libgmp, but with
> mini-gmp the result is 1, and this is incorrect.
>
> Tested on version 6.2.1 and the latest repository checkout, with recent
> clang and gcc, on x64 Linux.
> ___
> 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
mail archives are lost
Hi, not sure this is the best place to report. Since November 2021, the archives of the GMP mailing lists are no longer available. This is a pity since those archives contain a lot of useful information (except this mail of course). Best regards, Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Segmentation fault with mpz_inp_raw on gcc45
Hi Torbjörn, I confirm your fix works on gcc45: zimmerma@gcc45:~/ecm$ gcc -I$HOME/include test.c $HOME/lib/libgmp.a zimmerma@gcc45:~/ecm$ ./a.out XXX 2d65200d 0b594804 gmp: overflow in mpz type Aborted Thanks, Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Segmentation fault with mpz_inp_raw on gcc45
sorry the test_dummy2.save is attached. It was generated by (under /bin/sh, not /bin/bash): echo -e "\n\r\n\r# this is a comment line and should be ignored" > test_dummy2.save Paul test_dummy2.save Description: Binary data ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Segmentation fault with mpz_inp_raw on gcc45
> OK, so you deliberately sen d junk to mpz_inp_raw. That is fine, but it > was not clear from your report. it was not completely deliberate. The long story is that I tested "make check" of GMP-ECM on gcc45 with some recent merge request, and with /bin/sh the command echo -e "..." > xxx did put the '-e' into the file xxx, which produced the reported Seg fault. Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Segmentation fault with mpz_inp_raw on gcc45
Dear Torbjörn, > $ cat test_dummy2.save > -e > > # this is a comment line and should be ignored > > You do understand that mpz_inp_raw expects a binary file with a size > field followed by that many byytes of data, don't you? > > The file contents above make no sense. the documentation says: -- Function: size_t mpz_inp_raw (mpz_t ROP, FILE *STREAM) Input from stdio stream STREAM in the format written by 'mpz_out_raw', and put the result in ROP. Return the number of bytes read, or if an error occurred, return 0. I was thus expecting it to return 0 in case of an invalid file. Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Segmentation fault with mpz_inp_raw on gcc45
Hi,
with gmp-6.2.1 and the following program:
zimmerma@gcc45:~/ecm$ cat test.c
#include
#include
#include
main()
{
mpz_t s;
FILE *file;
int ret;
mpz_init (s);
file = fopen ("test_dummy2.save", "rb");
ret = mpz_inp_raw (s, file);
}
I get a Segmentation fault on gcc45 with the following file:
$ cat test_dummy2.save
-e
# this is a comment line and should be ignored
gdb says:
Program received signal SIGSEGV, Segmentation fault.
__mempcpy_ia32 () at ../sysdeps/i386/i686/multiarch/../mempcpy.S:50
50 ../sysdeps/i386/i686/multiarch/../mempcpy.S: No such file or directory.
(gdb) where
#0 __mempcpy_ia32 () at ../sysdeps/i386/i686/multiarch/../mempcpy.S:50
#1 0xb7e72388 in __GI__IO_file_xsgetn (fp=0x804a008, data=0x8a7b200a,
n=761596426) at fileops.c:1388
#2 0xb7e74138 in __GI__IO_sgetn (fp=fp@entry=0x804a008,
data=data@entry=0x8a7b200a, n=n@entry=761596426) at genops.c:495
#3 0xb7e67a19 in __GI__IO_fread (buf=0x8a7b200a, size=761596426, count=1,
fp=0x804a008) at iofread.c:42
#4 0x080486f4 in __gmpz_inp_raw ()
#5 0x08048602 in main () at test.c:12
I suspect the issue is due to "-e" in the first line, since there is no error
if I remove that line.
Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Rounding error
Dear Frank, > If I ever need correct rounding with GMP (I don't ATM), I think > I could add 0.5e-P, then (like above) multiply by 1eP, convert to > mpz_t and insert the decimal point manually. since there is no documented error bound in the mpf computations, there is no chance that this will (provably) work. The GMP manual says: 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. Of course you can add say 100 guard bits, then the probability to get an incorrect rounding is about 2^-100... Best regards, Paul Zimmermann ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: memory leak huge number of digits mpz_mul,mpf_sqrt_ui
Dear Susumu tsukamoto,
I tried valgrind with the following simplified program and it shows no memory
leak:
$ cat test_mul.c
#include "gmp.h"
int main()
{
long int num = 20; // 200,000,000
long int ik;
mpz_t DC;
printf(" start: num= %'ld \n", num);
mpz_init_set_str(DC, "1000",10); // DC=10^19
ik = 19;// DC=10^ik set num/2 <= ik < num
while (ik * 2 < num) {
mpz_mul(DC, DC, DC);
ik = ik * 2;
}
mpz_clear(DC);
}
$ /usr/bin/g++ -g -Wall test_mul.c -o test_mul01 -lgmp
$ valgrind ./test_mul01
...
==23406== HEAP SUMMARY:
==23406== in use at exit: 0 bytes in 0 blocks
==23406== total heap usage: 17 allocs, 17 frees, 231,296 bytes allocated
==23406==
==23406== All heap blocks were freed -- no leaks are possible
Does valgrind report a memory leak with your original value num=20000?
Best regards,
Paul Zimmermann
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Limitation of the mpz_get_str function
Hi Christophe, this issue is known since several years: https://gmplib.org/list-archives/gmp-bugs/2019-September/004633.html Paul > From: Christophe Clavier > Date: Tue, 16 Feb 2021 14:22:20 +0100 > > Dear GMP developers, > > I currently have to deal with huge numbers (several billions decimal > digits) which I need to convert in strings of digits with mpz_get_str. > I noticed that this function produces an incorrect result when the > number of digits exceeds 2^31. > The reason lies in the loop that scans the buffer computed by > mpn_get_str and transforms each digit from an integer to an ascii code : > > for (i = 0; i < str_size; i++) > res_str[i] = num_to_text[(int) res_str[i]]; > res_str[str_size] = 0; > > As i is of type int, when it is incremented from 2^31-1 to 2^31 it > becomes negative. > For the comparison with str_size, which is of type size_t (i.e. unsigned > long int), i is casted in unsigned long int and becomes a large positive > value near 2^64. > Thus the comparison is evaluated to false and the loop early terminates. > > I suggest to modify the type of i to long int or to unsigned long int. > > Regards > > Christophe > > > ___ > 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: A message bug. At least Version 6.2.0
> 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
Re: Debian Linux SPARC64 issue with FAIL t-printf (exit status: 139)
Dear Dennis, > With an old old Sun Nera server running very latest Debian sid I was > surprised to see : [...] does the same error occur with previous GMP versions, or is it specific to 6.2.1? Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: gmp 6.2.0 documentation bug
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
commits not available on the mercurial page
Hi, on https://gmplib.org/repo/gmp/shortlog when I click on a commit, I get an almost empty page, and I cannot see the corresponding diff. Am I the only one? Is that a temporary problem? Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mpz_sizeinbase() bug
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: bug in longlong.h for aarch64 sub_ddmmss
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
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
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: efficiency bug in mpz_powm_ui?
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: segmentation fault in t-toom53 test with MAC OS X Catalina (Clang 11.0)
Dear Juergen, > There are more problems in mpfr, and mpc does not even compile. > Is this already known? please report mpfr and mpc specific issues to the corresponding lists. Paul Zimmermann ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: bug in gmp_fprintf still in next release?
> 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
bug in gmp_fprintf still in next release?
Hi, 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. Will the next GMP release be still limited to less than 2^33 bits? Best regards, Paul Zimmermann [1] https://gmplib.org/list-archives/gmp-bugs/2015-November/003795.html ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: not really a bug but somewhat odd : checking compiler /usr/local/bin/gcc8 ... no, mpn_lshift_com
Hi Dennis,
> Dear gmp/mpfr folks :
this apparently has nothing to do with mpfr.
>From the error message in configure ("no, mpn_lshift_com optimization 2,
program does not run") you can conclude that your compiler is broken.
Please report to the compiler vendor.
Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
speed -P
Hi, there is a bug in the -P option of speed in GMP 6.1.2: $ ./speed -P foo -s 1-1000 mpn_mul_n $ gnuplot --persist foo.gnuplot If you look at the caption, the _ character in mpn_mul_n is interpreted as a subscript in Gnuplot (I have gnuplot 5.2 patchlevel 2), thus mpn_mul_n is not correctly printed. (See Section 1.14 Enhanced text mode of "info gnuplot".) A workaround is to add "set termoption noenhanced" in the foo.gnuplot file. Another workaround is to replace title "mpn_mul_n" by title "mpn\\_mul\\_n" (don't ask me why one \ does not work...) Best regards, Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: [MPFR] Mac OS X power pc issue with C99
Dear Arnold, the "duplicate symbol ___gmpz_abs" seems to be a frequent issue on Mac OS: http://mail-index.netbsd.org/pkgsrc-users/2008/11/20/msg008688.html https://groups.google.com/forum/#!topic/sage-devel/LVASCTPZnXw http://avr.2057.n7.nabble.com/Trouble-compiling-avr-gcc-gt-4-4-4-on-Mac-OS-X-Leopard-with-gcc-4-2-td8706i20.html The most useful answer I found is that one: https://gmplib.org/list-archives/gmp-bugs/2010-January/001747.html Hope this helps, Paul Zimmermann ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
rsblsh2_n.asm
Hi, in gmp-6.1.2 (and in the daily snapshot gmp-6.1.99-20180214), the head of mpn/rsblsh2_n.asm on x86_64 says: dnl AMD64 mpn_addlsh2_n -- rp[] = up[] + (vp[] << 1) dnl AMD64 mpn_rsblsh2_n -- rp[] = (vp[] << 1) - up[] I guess it should be: dnl AMD64 mpn_addlsh2_n -- rp[] = up[] + (vp[] << 2) dnl AMD64 mpn_rsblsh2_n -- rp[] = (vp[] << 2) - up[] Best regards, Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: printf/repl-vsnprintf.c bug (was: GMP|MPIR|MPFR assertions)
it should be noted that this bug was not found by GMP's "make check" (to my best knowledge), but only by MPFR's test suite. Before fixing the bug, it would be nice to fix the GMP test suite. Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Issue related to mpf_set_default_prec()
Hi, I could not reproduce your problem. Please could you send the exact modified program you use? Paul Zimmermann ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
issues on gcc202
I find several issues on gcc202.fsffrance.org:
1) gmp-6.1.2 configured with --disable-shared and gcc 7.2.0: libgmp.a
contains an undefined symbol __gmpn_addlsh1_n_ip1:
zimmerma@gcc202:/tmp/gmp-6.1.2$ cat e.c
#include "gmp.h"
int main()
{
mpz_t x;
mpz_init_set_str (x, "1234567890", 10);
mpz_sqrt (x, x);
}
zimmerma@gcc202:/tmp/gmp-6.1.2$ gcc -I/tmp/include e.c /tmp/lib/libgmp.a
/tmp/lib/libgmp.a(lt86-sqrtrem.o): In function `mpn_dc_sqrtrem':
sqrtrem.c:(.text+0x4b8): undefined reference to `__gmpn_addlsh1_n_ip1'
/tmp/lib/libgmp.a(lt86-sqrtrem.o): In function `mpn_dc_sqrt':
sqrtrem.c:(.text+0xa1c): undefined reference to `__gmpn_addlsh1_n_ip1'
collect2: error: ld returned 1 exit status
2) still with the same configuration, t-constants fails:
zimmerma@gcc202:/tmp/gmp-6.1.2$ tests/t-constants
PP_INVERTED == 21cfe6cfc938b36b, but pp_inverted_calc == 1dde20a605db167d
...
With the latest snapshot (gmp-6.1.99-20170829), issue 1) is fixed, but not
issue 2).
Paul
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Jacobi Symbol
Dear Niels, > I'm attaching my draft paper explaining the algorithm used in GMP. This > was written back in 2010, do you know if the algorithm has been > published elsewhere in the meantime? The trick (i.e., using part (v) and > (vi) of Proposition 1) dates back at least to work by Schönhage in the > 80s, and I implemented it after it was explained to me by Richard Brent. to my best knowledge, this was not published. It would be great to publish this nice work. A possible target would be Arith25 next summer. > For the GMP manual, ideally there should be a brief description and a > pointer to a published book or paper. indeed. Best regards, Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Jacobi Symbol
Hi, since GMP 5.1.0, i.e., 8 versions of GMP, the documentation says: 15.3.5 Jacobi Symbol [This section is obsolete. The current Jacobi code actually uses a very efficient algorithm.] I just checked the latest daily snapshot, it is still the same. When will this section be updated? Best regards, Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
documentation bug
reported to me by Bob Baillie (through Sam Wagstaff): >Anyway, on page 111 of the manual (section 15.7.1, Prime Testing) >https://gmplib.org/gmp-man-6.1.2.pdf >where it describes the algorithm for mpz_probab_prime_p, it says, > >"For an odd input n, and with n = q*2^k + 1 where q is odd, this algorithm >selects a random base x and tests whether > x^q mod n is 1 or -1, >or an > x^(q2^j) mod n is 1, for 1 <= j <= k. >If so then n is probably prime, if not then n is definitely composite." > >It looks like they are trying to describe the strong probable prime test. >However, in a strong probable prime test, the second check should be > x^(q2^j) mod n is -1, for 1 <= j < k. > >The manual is wrong, right? Do you know if the code is correctly written? Paul Zimmermann ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: mpf_get_d_2exp ignores sign of input
Torbjörn, > mpf_get_d_2exp() always returns a non-negative value, even for negative > input. I think this is a bug. > > The function works as documented. No bug. I disagree. The fine manual says "D * 2^EXP is the (truncated) OP value", which is wrong if say OP = -0.5. And why bother write 0.5<=abs(D)<1 instead of 0.5<=D<1 if D is always >= 0? Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
critical bug
Hi, I found a critical bug in gmp-6.1.0/mpn/s390_64/README: There are 5 generations of 64-but s390 processors, [...] It should be "64-bit" instead. Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
