Re: bug in __gmp_replacement_vsnprintf

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. See

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

Re: bug

赵世忠 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 Please encrypt,

Re: bug in __gmp_replacement_vsnprintf

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 changing the ASSERT

Re: bug report - 2 tests fail in make check

Got it. Thanks a lot On Thu, Jul 30, 2020 at 11:36 AM Torbjörn Granlund wrote: > Elyassaf Loyfer writes: > > >>> uname -a > Darwin huji-132-64-28-195.xt.huji.ac.il 19.5.0 Darwin Kernel Version > 19.5.0: Tue May 26 20:41:44 PDT 2020; > root:xnu-6153.121.2~2/RELEASE_X86_64 > x86_64 >

Re: bug report - 2 tests fail in make check

Elyassaf Loyfer writes: >>> uname -a Darwin huji-132-64-28-195.xt.huji.ac.il 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64 >>> ./config.guess kabylake-apple-darwin19.5.0 >>> ./configfsf.guess

Re: bug in longlong.h for aarch64 sub_ddmmss

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

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$

Re: bug in longlong.h for aarch64 sub_ddmmss

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*

Re: bug in longlong.h for aarch64 sub_ddmmss

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

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

Re: bug in longlong.h for aarch64 sub_ddmmss

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

Re: bug in longlong.h for aarch64 sub_ddmmss

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

Re: bug in longlong.h for aarch64 sub_ddmmss

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

Re: bug in longlong.h for aarch64 sub_ddmmss

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 +

Re: bug in longlong.h for aarch64 sub_ddmmss

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

Re: bug in longlong.h for aarch64 sub_ddmmss

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.

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

Re: bug in longlong.h for aarch64 sub_ddmmss

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 purge along the

Re: bug in longlong.h for aarch64 sub_ddmmss

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

Re: bug in longlong.h for aarch64 sub_ddmmss

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 {

Re: bug in longlong.h for aarch64 sub_ddmmss

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) &&

Re: bug in longlong.h for aarch64 sub_ddmmss

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"

Re: bug in longlong.h for aarch64 sub_ddmmss

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) \ >

Re: bug in gmp_fprintf still in next release?

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

Re: bug in gmp_fprintf still in next release?

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

Re: bug in gmp_fprintf still in next release?

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

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. >

Re: bug in gmp_fprintf still in next release?

On Fri, 27 Sep 2019, Torbjörn Granlund wrote: paul zimmermann writes: 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. Yikes!

Re: bug in gmp_fprintf still in next release?

paul zimmermann writes: 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. Yikes! Will the next GMP release be still limited to

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

On 2018-11-19 15:26:00 +0100, Richard Biener wrote: > On Mon, 19 Nov 2018, Vincent Lefevre wrote: > > AFAIK, GCC already changes the exponent range to the binary64 one > > (the lack of subnormals is not an issue, because in case of underflow, > > GCC ignores the computations done with MPFR). > >

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

On 11/19/18 5:40 AM, Torbjörn Granlund wrote: Richard Biener writes: > __real x = 3.09126495087690770626068115234375e+8; > __imag x = -4.045689747817175388336181640625e+8; > volatile _Complex double y = ctan (x); > return 0; > } > > If we get a test case

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

On Mon, 19 Nov 2018, Vincent Lefevre wrote: > On 2018-11-19 14:17:13 +0100, Niels Möller wrote: > > You might want to add an entry for "Exponent range" to the concept index > > in the manual. > > The concept index already has "Exponent", and the corresponding > paragraph is: > >An

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

On Mon, 19 Nov 2018, Niels Möller wrote: > Vincent Lefevre writes: > > > MPFR has a bounded (user configurable) exponent range, with underflow > > and overflow exceptions for out-of-range results, like in IEEE 754. > > Good! I didn't find that in the manual until I knew the phrase to search >

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

On 2018-11-19 12:49:12 +0100, Richard Biener wrote: > I see. So I guess one issue might be that mpfr numbers have a > precision (mantissa bits?) but no restriction on the exponent? MPFR has a bounded (user configurable) exponent range, with underflow and overflow exceptions for out-of-range

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

On Mon, 19 Nov 2018, Torbjörn Granlund wrote: > Richard Biener writes: > > :/ But then with GCC we want deterministic behavior -- ISL > added some "computation budget" and error reporting if that was > taken up. Maybe gmp/mpfr/mpc could consider adding such a thing > (reporting budget

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

Richard Biener writes: :/ But then with GCC we want deterministic behavior -- ISL added some "computation budget" and error reporting if that was taken up. Maybe gmp/mpfr/mpc could consider adding such a thing (reporting budget overruns via a signal could be acceptable if the API

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

t...@gmplib.org (Torbjörn Granlund) writes: I simplified your test case using 1 as the real part and an integer for the imaginary part. With the real part set to 1, the computation finishes in about 10 seconds, with every doubling of it the runtime almost triples. (If my observation

Re: BUG REPORT

Vaibhav Gautam writes: PLEASE HELP! The GMP developers cannot handle Microsoft's proprietary file formats, and thus cannot read your attachments. Plain old text is what you need to send in your message and in your attachments. Make sure you spell out what you

Re: Bug Upon Make Check

Ciao, Il Dom, 19 Marzo 2017 6:41 pm, David Hadaller ha scritto: > 1 of 58 tests failed With test? You are not giving any information... > make[4]: Leaving directory '/home/david/Downloads/gmp-4.3.2/tests/mpz' ... anyway, the last release is GMP-6.1.2, please try that. Have a nice GMP