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 fai
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
gmp-bugs@
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
gm
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
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,
resul
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/lis
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)
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, 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
gmp
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
gm
> 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 t
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 document
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 t
f 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
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
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 billion
> 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_
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
h
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
https:/
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$ /opt/cfarm/gcc-latest
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 =
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 mpfr-longl
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
>
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
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.
>
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
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
_
> 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). Y
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 correc
t-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[] + (vp[
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://gm
> > 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 broke
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
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 i
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, "1234
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: INTERP
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önhag
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
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,
> 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
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 bot
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
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 th
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 ad
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
54 matches
Mail list logo
