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, &myexp, 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, &myexp, 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=2? 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, > 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. sorry I mixed al and bl. After looking at the MPFR code that hit the bug: if (MPFR_UNLIKELY(_r < MPFR_LIMB_HIGHBIT)) \ _r = MPFR_LIMB_HIGHBIT; \ umul_ppmm (_h, _l, _r, _r); \ sub_ddmmss (_h, _l, _u, 0, _h, _l); \ I guess the compiler did optimize separately the _r < MPFR_LIMB_HIGHBIT case, in which case it did deduce _r = MPFR_LIMB_HIGHBIT, thus _l=0 after umul_ppmm, and the special code for bl=0 was used in longlong.h. 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
efficiency bug in mpz_powm_ui?
Hi, 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: zimmerma@tomate:/tmp$ ./a.out 10 GMP version: 6.2.0 mpz_ui_pow_ui+mpz_mod took 100ms set_ui+mpz_powm_uitook 2048ms zimmerma@tomate:/tmp$ ./a.out 100 GMP version: 6.2.0 mpz_ui_pow_ui+mpz_mod took 1005ms set_ui+mpz_powm_uitook 31138ms This was detected in the mpfr_remainder function, which is called from mpfr_sin to reduce huge arguments modulo Pi. Paul #include #include #include #include #include #include int cputime () { struct rusage rus; getrusage (0, &rus); return rus.ru_utime.tv_sec * 1000 + rus.ru_utime.tv_usec / 1000; } int main (int argc, char *argv[]) { unsigned long n = atoi (argv[1]), e; mpz_t x, y, r1, r2; int t; printf ("GMP version: %s\n", gmp_version); /* compute x mod y in two ways, where x=2^e is twice as large as y */ mpz_init (x); mpz_init (y); mpz_init (r1); mpz_init (r2); mpz_random (y, n); e = 2 * mpz_size (y) * mp_bits_per_limb; t = cputime (); mpz_ui_pow_ui (x, 2, e); mpz_mod (r1, x, y); t = cputime () - t; printf ("mpz_ui_pow_ui+mpz_mod took %dms\n", t); t = cputime (); mpz_set_ui (x, 2); mpz_powm_ui (r2, x, e, y); t = cputime () - t; printf ("set_ui+mpz_powm_uitook %dms\n", t); assert (mpz_cmp (r1, r2) == 0); mpz_clear (x); mpz_clear (y); mpz_clear (r1); mpz_clear (r2); return 0; } ___ 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
Re: possible bug in mpz_cmp_d
> On Mon, Jul 09, 2018 at 11:04:57PM -0600, Tom Tromey wrote: > [...] > > double d = -2305843009213693953.0; > [...] > > I expect this to print 0, because the numbers are the same, and because > > the number can be exactly represented as a double. > > I don't think so. > > d is -(2^61+1). You only have 56 bits of mantissa in a double. No way you > can tell apart -(2^61+1) and -(2^61+2). You would need a larger mantissa > for that. more precisely the literal -2305843009213693953.0 has 62 bits, and thus cannot be represented exactly in a double, which (usually) has a significand of 53 bits (IEEE 754 binary64). If the rounding mode is to nearest-even, then the value -2^61 is put into d, which is the closest representable value to the literal. Best regards, 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: printf/repl-vsnprintf.c bug (was: GMP|MPIR|MPFR assertions)
> > printf/repl-vsnprintf.c seems buggy for floating-point specifiers > > (EeGgFf). Replace "break" by "goto next" (2 occurrences)? > > Proposed patch attached. Not tested. here is a test case to reproduce the issue (you have to test it on a system that doesn't have vsnprintf, or only has a broken one, or define HAVE_VSNPRINTF to 0 in config.h): #define _GNU_SOURCE #include #include #include #include int test(const char *fmt,...) { va_list args; char *s = NULL; int size; va_start(args,fmt); size = gmp_vasprintf(&s, fmt, args); printf("size=%d s='%s'\n", size, s); return 0; } int main(void) { char *fmt = "%f %Zd"; mpz_t z; float f = 17.0; mpz_init_set_ui (z, 42); test(fmt, f, z); mpz_clear (z); } $ ./a.out repl-vsnprintf.c:358: GNU MP assertion failed: 0 Aborted (core dumped) 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
Re: issues on gcc202
Dear Torbjörn, > This is not yet isolated. It looks like a compiler or perhaps more > likely a linker bug. Last night I reverted another change which > benefited gcc202, so now there will be more errors. > > I am not actively working on this issue, but I will probably isolate it > at some point. > > Alas, I got around to this now. > > There were a number of problems: > > 1. The pseudo-insn setx didn't work on gcc202. I worked around this by >expanding the needed insn, and also to go with the 44-bit addressing >model (instead of the expensive 64bit). 44-bit addrs is the default >on both gcc202 and NetBSD 7.x at least. (I suppose we should allow >an configure option for this, but since my SPARC access is extremely >limited I cannot test any such features. Besides, SPARC is not in >much use.) > > 2. The relocs used for PIC in sparc32/sparc-defs.m4 fails on gcc202. I >updated with PICkier choices. > > 3. The C sec_invert and the Sparc T3 asm cnd_add_n/cnd_sub_n did not >agree about how to specify the condition. Should true be 1 or any >non-zero value? I decided for the latter and updated the asm. thank you, I confirm make check runs with the gmp-6.1.99-20170831 snapshot on gcc202. However I had to define INTERPRETER= in test-driver. Also the "Testsuite summary" is still not very informative: Testsuite summary for GNU MP 6.1.99 # TOTAL: 0 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 Paul ___ 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: Assertion failure in mpz_divexact()
I can reproduce this on my laptop, with the gmp-6.1.99-20170821 snapshot, and gcc 5.4.0, Ubuntu 16.04. Moreover with that snapshot, make check fails: zimmerma@mure:/tmp/gmp-6.1.99-20170821$ make check ... make[5]: Entering directory '/tmp/gmp-6.1.99-20170821/tests' ../test-driver: line 107: INTERPRETER: unbound variable Makefile:1057: recipe for target 't-bswap.log' failed 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: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)
Torbjörn, > Should we pass this option for mingw on GMP's configure.ac? > Or do people expect broken libc on this platform...? note we have this in MPFR INSTALL file: 3 - To avoid using the Microsoft runtime (which might not be conform to ISO C), you can use the MinGW runtime package (which is an integral part of MinGW). For example, with MinGW versions 3.15 and later you can get an ISO-compliant printf() if you compile your application with either '-ansi', '-posix' or '-D__USE_MINGW_ANSI_STDIO'. In order to have the MPFR formatted output functions based on ISO-compliant printf(), you need to compile GMP (not MPFR) with CC="gcc -D__USE_MINGW_ANSI_STDIO" (since the standard printf modifiers %e, %Ld and %td are passed to GMP). Not doing so may result in failures of some of the printf-related tests. For instance, the following error on some Windows machine has been reported: https://sympa.inria.fr/sympa/arc/mpfr/2016-02/msg00053.html Error in mpfr_vsprintf (s, "%e", ...); expected: "-1.25e+000" got: "-1.25e+00" FAIL tsprintf.exe (exit status: 1) The cause is that here the C functions vsnprintf and vsprintf used internally in GMP do not produce the same output: https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00045.html https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00051.html https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00053.html Building MPFR with -D__USE_MINGW_ANSI_STDIO is currently useless except for some error messages in the test suite. Paul ___ 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
Dear GMP developers, I've found a critical bug in gmp-6.1.2, file mpn/x86_64/invert_limb.asm, line 91: C v3 = (v2 << 31) + (v2 * (2^96 - v2 * d63 + ((v2 >> 1) & mask)) >> 65 A closing parenthesis is missing. Happy end of 2016 to all of you! Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: building gmp-6.1 for s390 (31-bit) w/asm disabled failing with undefined sdiv_qrnnd
Torbjörn, > From: t...@gmplib.org (Torbjörn Granlund) > Date: Wed, 14 Dec 2016 21:33:10 +0100 > > Vincent Lefevre writes: > > I suppose that if one doesn't use the macros that depend on > GMP internals, there should be no problems. In particular, > udiv_qrnnd is not used, unless the user configured MPFR to use > the GMP internals, but then that's the user's own problems. > > There is a symbol LONGLONG_STANDALONE which mpfr might want to use. > It is documented in longlong.h's header. it is already included in mpfr-impl.h: $ grep -C 3 LONGLONG_STANDALONE src/mpfr-impl.h # include "mpfr.h" # include "mpfr-gmp.h" # ifdef MPFR_NEED_LONGLONG_H # define LONGLONG_STANDALONE # include "mpfr-longlong.h" # endif Therefore the issue with undefined sdiv_qrnnd was because the corresponding code was not protected by #ifdef LONGLONG_STANDALONE? Paul ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: building gmp-6.1 for s390 (31-bit) w/asm disabled failing with undefined sdiv_qrnnd
Hi Torbjörn, > We're probably going to create many more problems for extension libs for > GMP 7. It will be the first release to support symbol hiding, and while > we're not going to be fascist about our "private" symbols, we're going > to make truly internal things hidden. then please add in the interface symbols which are useful to extension libs, see for example https://gmplib.org/list-archives/gmp-devel/2016-July/004306.html. 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