On 2024-03-25 18:13:22 +0100, marco.bodr...@tutanota.com wrote:
> Vincent, you did not confirm that this code worked for you, but I
> pushed it anyway.
> https://gmplib.org/repo/gmp/rev/4ac76064639e
Thanks. I'll look at it when I have some time.
--
Vincent Lefèvre - Web:
Ciao,
18 feb 2024, 12:29 da marco.bodr...@tutanota.com:
> 15 dic 2023, 13:26 da vinc...@vinc17.net:
>
>> Note that there are similar issues in printf/repl-vsnprintf.c, and I
>>
>
> I finally had the time to examine the code and test it. I attach a proposed
> patch.
>
Vincent, you did not
Ciao Vincent,
15 dic 2023, 13:26 da vinc...@vinc17.net:
> Note that there are similar issues in printf/repl-vsnprintf.c, and I
>
I finally had the time to examine the code and test it. I attach a proposed
patch.
I changed the 3 files: printf/doprntf.c, printf/repl-vsnprintf.c,
On 29 November 2023 I reported a bug with the title: "GMP 6.3.0 fails "make
check" on Mac Pro 2019 (Intel) running macOS Ventura 13.6.1".
I can now report that GMP 6.3.0 passed "make check" with no errors after
downloading, configuring, and installing on a 2023 2
Hi,
On 2023-12-13 20:03:13 +0100, marco.bodr...@tutanota.com wrote:
> It was changed in 2001, probably a workaround, because the comment was
> "Don't use sprintf return value (it's a pointer on SunOS 4)"
> https://gmplib.org/repo/gmp/rev/0889877bb94a
Note that there are similar issues in
Ciao,
13 dic 2023, 15:53 da vinc...@vinc17.net:
> On 2023-12-03 20:19:10 +0100, Vincent Lefevre wrote:
>
>> With GMP 6.3.0, the formatted output functions do not handle %c
>> with the value 0 correctly. For gmp_sprintf, the return value is
>> incorrect.
>>
> In printf/sprintffuns.c, function
On 2023-12-03 20:19:10 +0100, Vincent Lefevre wrote:
> With GMP 6.3.0, the formatted output functions do not handle %c
> with the value 0 correctly. For gmp_sprintf, the return value is
> incorrect.
In printf/sprintffuns.c, function gmp_sprintf_format(), I suppose that
vsprintf (buf, fmt, ap);
With GMP 6.3.0, the formatted output functions do not handle %c
with the value 0 correctly. For gmp_sprintf, the return value is
incorrect. For gmp_asprintf and gmp_vasprintf, this is either a
buffer overflow (according to the GMP manual: "The block will be
the size of the string and
"Vincent Lefevre"
To: "marco bodrato"
Cc: "Brett Kuntz" , gmp-bugs@gmplib.org
Sent: Thursday, August 31, 2023 11:06:51 AM
Subject: Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c
On 2023-08-31 17:03:12 +0200, marco.bodr...@tutanota.com wrote:
each one with its couple
> of functions.
I concluded the same just now.
-Brett Kuntz
From: "marco bodrato"
To: "Vincent Lefevre"
Cc: "Brett Kuntz" , gmp-bugs@gmplib.org
Sent: Thursday, August 31, 2023 12:33:46 PM
Subject: Re: Uninitialized memory bug fo
Ciao,
31 ago 2023, 18:06 da vinc...@vinc17.net:
> I don't think that this is sufficient for the test.
> The code Brett mentioned is for MOD_1_1P_METHOD = 2.
>
The code Brett mentioned is mixed, I fear.
Looking at mpn/generic/mod_1_1.c,if MOD_1_1P_METHOD == 1, the value[2] in the
array is
On 2023-08-31 17:03:12 +0200, marco.bodr...@tutanota.com wrote:
> Ciao,
>
> 31 ago 2023, 16:30 da ku...@shaw.ca:
>
> > 1) Edit line 248 mpn/generic/mp_limb_t pre[4]; into:
> >
> ~/src/gmp$ hg diff mpn/generic/
> diff -r 3ac5afa36be5 mpn/generic/mod_1.c
> --- a/mpn/generic/mod_1.c Wed Nov
===
Even the modified library passes the tests.
Sorry, I'm not able to reproduce your bug report, not even with an arbitrarily
modified source code.
~/src/gmp$ hg revert mpn/generic/
sto ripristinando mpn/generic/mod_1.c
I'd say that when the limb you are looking at is not initialized, t
actually claim that an unedited GMP has a bug here, please
construct a test case which uses documented interfaces, and which
demonstrates the claimed bug.
1) Edit line 248 mpn/generic/mp_limb_t pre[4]; into:
There is no file with that name.
mp_limb_t pre[4] = { -1, -1, -1, -1 };
2
e[2].
The final line:
return mpn_mod_1_1p (ap, n, b, pre);
Reads from pre[2] erroneously and gives incorrect results if your stack memory
has anything other than a 0 there.
> But if you actually claim that an unedited GMP has a bug here, please
construct a test case which uses documented inte
ings will be bad if
you use one variant of the internal _cps function with another variant
of the corresponding internal mod function. If that's what you're
trying to say, then you're right. GMP is not edit proof, local user
edits might break it in all sorts of ways,
But if you actually claim that
Hello, today I found a bug in the latest GMP (6.3) using uninitialized memory
in /mpn/generic/mod_1_1.c while trying to understand some functions like
mpn_mod_1_1p_cps.
Take a look at function mpn_mod_1() in /mpn/generic/ mod_1.c on lines 248 - 250
mp_limb_t pre[4];
mpn_mod_1_1p_cps (pre, b
On 2023-08-21 10:59:13 +0200, Paul Zimmermann wrote:
> here is a small program that exhibits the bug (for example on gcc231):
[...]
An OpenBSD 7 machine, and this is due to the fact that %n is
no longer supported by the system *printf functions, so that
GMP uses __gmp_replacement_vsnprintf.
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
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,
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
赵世忠 writes:
The last digit should be '8', but mpf_get_str outputs '7'.
"Should be"?
Please read the GMP documentation, and if you still think there is a
bug, please write a bug report where you motivate what you think is not
right with GMP's current behaviour.
--
Torbjörn
Plea
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
Dear Sir/Madame,
I am here to report a bug in GMP, in particular, make check fails 31 tests out
of 50.
Please find attached the test-suite.log and the report, hopefully as detailed
as needed.
Best,
Eleonora Vercesi

___
gmp-bugs mailing list
Paul Zimmermann writes:
> this bug report got no feedback so far:
>
> https://gmplib.org/list-archives/gmp-bugs/2022-October/005200.html
>
> Do the GMP developers acknowledge it?
I'm not so familiar with this part of GMP, but it looks like a bug to
me.
I would suggest first chan
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
Ciao,
Il 2022-10-26 13:40 ni...@lysator.liu.se ha scritto:
jy l writes:
It seems like in `mpz_nextprime` this line (
https://gmplib.org/repo/gmp/file/tip/mpz/nextprime.c#l204), when `n`
is
very large, it doesn't restrict the value of `odds_in_composite_sieve`
which leads to the `alloca`
jy l writes:
> It seems like in `mpz_nextprime` this line (
> https://gmplib.org/repo/gmp/file/tip/mpz/nextprime.c#l204), when `n` is
> very large, it doesn't restrict the value of `odds_in_composite_sieve`
> which leads to the `alloca` below crash and might cause more buffer
> overflow.
I
://gmplib.org/repo/gmp/file/tip/mpz/nextprime.c#l204), when `n` is
very large, it doesn't restrict the value of `odds_in_composite_sieve`
which leads to the `alloca` below crash and might cause more buffer
overflow.
Could you please help us to verify this bug? Looking forward to your reply,
thanks
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
t; On 2021-01-22 11:59:43 +0100, Titouan Coladon wrote:
>> it's indeed, gcc that must have a bug.
>>
>> The older bare metal version: gcc-arm-none-eabi-7-2017-q4-major-linux is
>> working properly.
>>
>> Then the latest version : gcc-arm-none-eabi-8-2018-q4-ma
On 2021-01-22 13:29:13 +0100, Titouan Coladon wrote:
> I cannot run make check because of the cross-compilation.
I think that it would be a good idea to use an emulator to check the
GMP build. This should always be done. Compiler bugs are common.
--
Vincent Lefèvre - Web:
Hi,
On 2021-01-22 11:59:43 +0100, Titouan Coladon wrote:
> it's indeed, gcc that must have a bug.
>
> The older bare metal version: gcc-arm-none-eabi-7-2017-q4-major-linux is
> working properly.
>
> Then the latest version : gcc-arm-none-eabi-8-2018-q4-major-linux,
> gcc-ar
but ttt should be
>
> 5247183143879283565064056089869553515440215252945038779070795247972433237341511292686962488915110675351673985513318500576097977116134885013371639187873069514
>
> I give the code to reproduce the bug in attachment.
>
> GMP is built with the options:
>
> CC=/home/titouan/Softs/gcc-arm-none-eabi-10-
be
5247183143879283565064056089869553515440215252945038779070795247972433237341511292686962488915110675351673985513318500576097977116134885013371639187873069514
I give the code to reproduce the bug in attachment.
GMP is built with the options:
CC=/home/titouan/Softs/gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux/gcc-arm-none-eabi-10-2020-q4-major/bin/arm-none-eabi-gcc
../configure CFLAGS
Ciao,
Il 2020-12-22 15:55 Guillermo Monguia ha scritto:
In mini-gmp.c function mpz_export, when calling gmp_die("mpz_import:
...") instead of gmp_die("mpz_export: ...")
Corrected, thanks!
https://gmplib.org/repo/gmp/rev/6fed56750f6f
Ĝis,
m
___
> 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:
In mini-gmp.c function mpz_export, when calling gmp_die("mpz_import: ...")
instead of gmp_die("mpz_export: ...")
Sent from my iPhone
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
e #5: 0x0001019b5678 PEPObjCAdapterFramework`__gmpz_powm +
> 2432
>
>Let me know if and how to provide more useful information if needed.
>
> Your report is scarce of detail. Perhaps there is a bug in your
> program?
>
> Another possibility is that GMP does not work
Hi Marco,
thanks to your help, its building fine now without --disable-assembly,
but it crashes using it.
I am totally not into ASM, so forgive unqualified report(s).
Here is the backtrace:
* thread #8, queue = 'PEPAsyncSession.queue', stop reason =
EXC_BAD_ACCESS (code=2,
is scarce of detail. Perhaps there is a bug in your
program?
Another possibility is that GMP does not work right on Ios. Since that
is a closed platform where developers need to pay Apple for programming,
you cannot excpect any effort from the GMP team with regards to
development or testing of GMP
Hi Marco,
Am 14.10.20 um 22:21 schrieb Torbjörn Granlund:
> Marco Bodrato writes:
>
>Look for a filename starting with gmp-6.2.0-202010...
>
>Then please follow up here!
>
> I changed how snapshots are managed.
>
> 1. There are now subdirs for each release series, plus "gmp-next". The
Am 14.10.20 um 15:38 schrieb Marc Glisse:
> On Wed, 14 Oct 2020, Andreas Buff wrote:
>
>> Using host `aarch64-apple-darwin` gives me "unknown AArch64 fixup kind!"
>> errors.
>
> There was a discussion related to arm64 and apple in july, did you try
> with a recent snapshot from
> On 14 Oct 2020, at 12:59, Andreas Buff wrote:
>
> We are cross building GMP for use on ARM64 iOS devices using this command:
> …
This link suggests using the -target option for makefiles outside Xcode.
https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary
Marco Bodrato writes:
Look for a filename starting with gmp-6.2.0-202010...
Then please follow up here!
I changed how snapshots are managed.
1. There are now subdirs for each release series, plus "gmp-next". The
latter is made from the bleeding edge repo.
2. We have had an idea of an
Il 2020-10-14 21:28 t...@gmplib.org ha scritto:
Andreas Buff writes:
Latest snapshot is from may though
There is one made every day.
Look for a filename starting with gmp-6.2.0-202010...
Then please follow up here!
Ĝis,
m
___
gmp-bugs
Andreas Buff writes:
Latest snapshot is from may though
Not quite. Look better.
There is one made every day.
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Hi,
thanks (!) for useful and fast response.
See below.
Best,
Andreas
Am 14.10.20 um 14:50 schrieb Marc Glisse:
> On Wed, 14 Oct 2020, Andreas Buff wrote:
>
>> We are cross building GMP for use on ARM64 iOS devices using this
>> command:
>>
>> ```
>> export CFLAGS="-arch ${ARCH} -isysroot
Hi,
We are cross building GMP for use on ARM64 iOS devices using this command:
```
export CFLAGS="-arch ${ARCH} -isysroot ${SDK_PATH}
-miphoneos-version-min=${MIN_IOS_VERSION} -std=c99"
export LDFLAGS="-arch ${ARCH}"
export CC="$(whereis gcc) -arch ${ARCH} -isysroot ${SDK_PATH}"
On Wed, 14 Oct 2020, Andreas Buff wrote:
Using host `aarch64-apple-darwin` gives me "unknown AArch64 fixup kind!"
errors.
There was a discussion related to arm64 and apple in july, did you try
with a recent snapshot from https://gmplib.org/download/snapshot/ ?
--
Marc Glisse
On Wed, 14 Oct 2020, Andreas Buff wrote:
We are cross building GMP for use on ARM64 iOS devices using this command:
```
export CFLAGS="-arch ${ARCH} -isysroot ${SDK_PATH}
-miphoneos-version-min=${MIN_IOS_VERSION} -std=c99"
export LDFLAGS="-arch ${ARCH}"
export CC="$(whereis gcc) -arch ${ARCH}
> On 29 Sep 2020, at 19:17, Marco Bodrato wrote:
>
> Il 2020-09-29 16:09 TonyMcC ha scritto:
>> 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
Hi,
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"?
Best wishes,
Tony
Ciao,
Il 2020-09-29 16:09 TonyMcC ha scritto:
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
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
On 2020-08-19 10:39:01 +0200, Paul Zimmermann wrote:
>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 d
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
"Lebender, Johannes" writes:
i found a possible bug in the mpz_sizeinbase() function. e.g.
mpz_sizeinbase(63, 10) returns 2
mpz_sizeinbase(64, 10) returns 3
Why do you think those values are wrong? Which values do you expect
instead?
--
Torbjörn
Please encrypt, key id
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
r/CommandLineTools/usr
>
> --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
> Apple clang version 11.0.0 (clang-1100.0.33.8)
> Target: x86_64-apple-darwin19.5.0
> Thread model: posix
> InstalledDir: /Library/Developer/Command
.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
These test suite failures smell compiler bug. Unfortunately, while
Apple is a large company, their compiler team does not seem to be able
to produce a robust co
t...@gmplib.org (Torbjörn Granlund) writes:
A crude test generator:
A slightly better variant. It expects an argument, either "add" or
"sub", allowing it to test both add_ss and sub_ddmmss.
This version should work fine on 32-bit systems without modification.
This code is not
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$
Vincent Lefevre writes:
Note: in the tests, it is important to test the macro on constants
in order to test the "if" case.
A crude test generator:
#include
#include
#include "gmp-impl.h"
void
one (size_t ind, mp_limb_t m0, mp_limb_t s0)
{
printf ("void f%zu(mp_limb_t* r1p, mp_limb_t*
Paul Zimmermann writes:
>Dear Niels,
>
>> The excluded case,
>>
>> sub_ddmmss(ah, al, bh, /*compile time constant*/0)
>>
>> could clearly be optimized, in a different way, but I'd guess it's rare
>> enough in real code to not be worth the effort?
Sorry for being unclear, sub_ddmmss
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
ni...@lysator.liu.se (Niels Möller) writes:
And, which I guess is more relevant in the sub_ddmmss context, it also
means that there's little need for separate instructions for adding and
subtracting constants.
The error we struck here for ARM and (one of the errors) for PPC was
that we
t...@gmplib.org (Torbjörn Granlund) writes:
> > {cout, r} = a + ~b + cin
>
> This is a - b - borrow, where the borrow is the complement of the
> carry bit.
>
> Niels' definition is important as it captures the similarity with
> addition. It is indeed how the instructions are described in
Vincent Lefevre writes:
On 2020-06-17 11:04:26 +0200, Niels Möller wrote:
> t...@gmplib.org (Torbjörn Granlund) writes:
>
> > The two - signs ought to be ~, I think. Let me think a buit more about
that.
>
> If I remember ARM conventions correctly, subtract with carry is defined
On 2020-06-17 11:04:26 +0200, Niels Möller wrote:
> t...@gmplib.org (Torbjörn Granlund) writes:
>
> > The two - signs ought to be ~, I think. Let me think a buit more about
> > that.
>
> If I remember ARM conventions correctly, subtract with carry is defined
> as
>
> {cout, r} = a + ~b +
ni...@lysator.liu.se (Niels Möller) writes:
t...@gmplib.org (Torbjörn Granlund) writes:
> The two - signs ought to be ~, I think. Let me think a buit more about
that.
If I remember ARM conventions correctly, subtract with carry is defined
as
{cout, r} = a + ~b + cin
Here we
t...@gmplib.org (Torbjörn Granlund) writes:
> The two - signs ought to be ~, I think. Let me think a buit more about that.
If I remember ARM conventions correctly, subtract with carry is defined
as
{cout, r} = a + ~b + cin
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred.
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),
wher
Vincent Lefevre writes:
Note: in the tests, it is important to test the macro on constants
in order to test the "if" case.
Indeed, and one macro expansion per trivial function or else gcc might
get the idea cse constants.
This bug comes untimely for me. I consider a major p
On 2020-06-16 16:11:53 +0200, Vincent Lefevre wrote:
> Note that I'm rather surprised to see that the issue disappears
> if I add unrelated code. For instance, in the following testcase,
> with GCC 9.1.0 -O2, I get "h = 0x", which is
> incorrect, but if I define V, I get the
On 2020-06-16 14:47:23 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre writes:
>
> On 2020-06-16 13:40:14 +0200, Torbjorn Granlund wrote:
> > Vincent Lefevre writes:
> >
> > #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
> > do {
Vincent Lefevre writes:
On 2020-06-16 13:40:14 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre writes:
>
> #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
> do { \
> if (__builtin_constant_p (bl) &&
Vincent Lefevre writes:
#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
do { \
if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000) \
__asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3"
On 2020-06-16 12:55:07 +0200, Vincent Lefevre wrote:
> In longlong.h from GMP 6.2.0:
>
> #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
> do { \
> if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000) \
>
Hi,
In longlong.h from GMP 6.2.0:
#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
do { \
if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000) \
__asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3"
t...@gmplib.org (Torbjörn Granlund) writes:
> (I am not sure why MiniGMP uses the same internal field names as the
> full GMP. Perhaps it should use different names to discourage
> non-complying code?)
I think the definition of mpz_t and struct __mpz_struct were simply
copied verbatim. Renaming
Syed Jafri writes:
Thank you for your help, I used the set macros and it works perfectly.
We appreciate that you follow up with this all-is-fine message!
The initial point of confusion for me was that the exact same code
worked in gmp but not mini-gmp.
The two might interpret the fields
hadn't understood that the reporter had played with GMP's internal
fields, setting up broken variable states.
Let's not spend time on this until we get a self-contained bug reports
as defined in the manual, which contains a well-defined test case.
--
Torbjörn
Please encrypt, key id 0xC8601622
Syed Jafri writes:
> https://github.com/jafri/gmp-bug
To make it easy to follow the example, I would suggest simplifying it to
something like
#include
#include /* or #include "mini-gmp.c" */
int main (int argc, char **argv)
{
mpz_t a, b, g, s;
mpz
Syed Jafri writes:
Thank you for the wonderful library, I have been using mini-gmp and I
have run into a bug with the mpz_gcdext function. The full GMP version
gives the correct output, while the mini-gmp version of the function
fails at line 2911 of mini-gmp.c, at the code ```assert
Hello GMP Team,
Thank you for the wonderful library, I have been using mini-gmp and I have run
into a bug with the mpz_gcdext function. The full GMP version gives the correct
output, while the mini-gmp version of the function fails at line 2911 of
mini-gmp.c, at the code ```assert (mpz_even_p
Marc Glisse writes:
I cannot see any recent snapshot at
https://gmplib.org/download/snapshot/ , the most recent one appears to
be from 17-Jan-2020.
Ah, they are broken in the sense that they don't exist. :-)
(It was a boched disabling of ftp snapshot downloads; the sync to the
web
On Mon, 2 Mar 2020, Torbjörn Granlund wrote:
paul zimmermann writes:
PS: while trying the above change, I noticed the daily snapshots are broken
since January 18...
Would you mind telling us what is "broken"?
I cannot see any recent snapshot at https://gmplib.org/download/snapshot/
,
paul zimmermann writes:
PS: while trying the above change, I noticed the daily snapshots are broken
since January 18...
Would you mind telling us what is "broken"?
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
m_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 wi
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
line 5769 in md_apply_fix3
Please report this bug.
Makefile:768: recipe for target 'invert_limb.lo' failed
make[2]: *** [invert_limb.lo] Error 1
make[2]: Leaving directory '/home/toni/Desktop/gmp-6.2.0/mpn'
Makefile:995: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make
: yes
Shared libraries: yes
After compiling and linking with the PowerPC gmp library you just run
./executable_name. You don't need anything else.
I hope you have enough information to see if this is a real bug or not.
Best
Gabriel Sturzu writes:
Version: GNU MP 6.0.0
That is an obsolete GMP release. Please try a current release,
preferably 6.2.0.
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
David Joyner writes:
Errors are below. Just reporting this as requested.
Note that there is also a link displayed which points to the page on how
to create meaningful GMP bug reports. Please read it.
--
Torbjörn
Please encrypt, key id 0xC8601622
Hi:
I'm trying to compile gcc using homebrew on mac 10,15.1
with Xcode 11.1 installed (xcode-select version 2370). This is on a
late 2013 macbook pro. It seems to fail on gmp.
Errors are below. Just reporting this as requested.
- David
jeeves:wodehouse wdj$ brew install gcc
Warning: You are
t...@gmplib.org (Torbjörn Granlund) writes:
> IIRC, the size field counts bytes for these functions. The size in mpz
> counts limbs.
You're right. So then for positive numbers, mpz_out_raw can deal with
numbers of at most 2^34 - 8 bits. And negative numbers of at most 2^34
bits (absolute
ni...@lysator.liu.se (Niels Möller) writes:
Another limit that was pointed out to me the other day is mpz_out_raw,
with a 32-bit length field (matching the current mpz_t limit, though).
IIRC, the size field counts bytes for these functions. The size in mpz
counts limbs.
--
Torbjörn
t...@gmplib.org (Torbjörn Granlund) writes:
> But we cannot make %* type arguments work, easily. It will be limping
> unless we change int to size_t (or some such).
Another limit that was pointed out to me the other day is mpz_out_raw,
with a 32-bit length field (matching the current mpz_t
> 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.
>
1 - 100 of 164 matches
Mail list logo
