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
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
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 descriptio
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
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
et_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
&g
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,
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
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
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 &&
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,
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
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
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
> 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
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
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
n 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
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
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
> 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:
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
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
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
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.
> m
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$
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
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
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
>
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
> 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.
>
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
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
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
c-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://
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[] +
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
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
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,
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
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.
he 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
__
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
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
44 matches
Mail list logo
