Re: Compile warnings

On 2016-02-06 17:03:34 +, Junges, Sebastian wrote: > Dear developers, > > We are successfully using gmp in several of our projects. Thanks for all the > efforts you put into the project. > I’m fully aware that compilation time warnings are not the same as bugs, > however, I still would like

Re: mpz reuse test takes too much time

On 2016-09-28 16:24:15 +0200, Torbjörn Granlund wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > But there may have been a temporary problem, as I now get: > > ./reuse 27.56s user 0.15s system 100% cpu 27.698 total > > That's more in the expe

Re: building gmp-6.1 for s390 (31-bit) w/asm disabled failing with undefined sdiv_qrnnd

On 2016-12-09 22:29:18 +0100, Torbjörn Granlund wrote: > Right. The longlong.h file is shared among several GNU programs, but I > long ago stopped trying to keep GMP's version easily usable outside of > GMP. > > In particular, GMP's longlong.h requires various external functions, and > the

Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

On 2017-03-30 10:52:33 +0100, Claude Heiland-Allen wrote: > The failing source code is: > > /* EOF for no matching */ > { > char buf[128]; > ret = gmp_sscanf (" ", "%s", buf); > ASSERT_ALWAYS (ret == EOF); > ret = fromstring_gmp_fscanf (" ", "%s", buf); > ASSERT_ALWAYS

Re: FreeBSD links wrong library for tests if one is installed in $prefix

On 2017-06-28 13:55:41 +0200, Torbjorn Granlund wrote: > Emmanuel Thomé writes: > > freebsd's ld, which is a venerable GNU binutils 2.17.50 dated 2007-07-50 > (yes, I'm talking about the current freebsd), does not emit new dtags > (runpath vs rpath) by default. >

Re: "make check" fails: undefined reference to `__gmpn_compute_powtab'

After a closer look, problem solved with "autoreconf". IMHO, maintainer mode should be enabled by default. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC

gmp_snprintf tries to allocate 18 EB on long strings

Consider the following program: #include #include int main(void) { int r; long n = -1; r = gmp_snprintf (NULL, 0, "%2147483600s%100s%ln", "", "", ); printf ("%d %ld\n", r, n); return 0; } On my Debian/unstable x86_64 machine (GMP 6.1.2 provided by the Debian package), I get after

Re: FreeBSD links wrong library for tests if one is installed in $prefix

On 2017-06-27 23:11:02 +0200, Emmanuel Thome wrote: > On Tue, Jun 27, 2017 at 08:01:50PM +0200, Vincent Lefevre wrote: > > On 2017-06-27 19:21:00 +0200, Emmanuel Thome wrote: > > > gf2x-freebsd-110-amd64-test2 ~/gmp-6.1.2 $ objdump -x > > > ./tests/mpn/.libs/t-m

Re: GNU MP 6.1.2 error undefined symbol __gmpn_invert_limb in test t-constants

On 2017-08-28 23:33:03 +0200, Niels Möller wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > This only works if the user is root. If a non-root user wants to > > install libraries in his home directory, the right solution is to > > use LD_LIBRARY_PATH (since

Re: GNU MP 6.1.2 error undefined symbol __gmpn_invert_limb in test t-constants

On 2017-08-28 22:50:23 +0200, Niels Möller wrote: > Dennis Clarke writes: > > > In some manner the pre-existing libs were getting in the way likely > > because LD_LIBRARY_PATH=/usr/local/lib and thus the new libs in the > > build_dir/.libs were not used. > >

Re: register corruption under MS Windows / x86-64

On 2017-12-15 00:00:40 +0100, Torbjorn Granlund wrote: > It is a flaw in our testing setup that this calling convention breach is > not caught by the automated testing. I will fix both bugs. :-) > > I have now pushed a fix for the mainline repo. Testing would be > appreciated! One of

register corruption under MS Windows / x86-64

There appears to be a bug in mpn/x86_64/fastsse/com-palignr.asm, which is now used by the GMP trunk. If I understand correctly, the optimized loop uses xmm6 and xmm7 without restoring their values. This is correct under Linux, but not under MS Windows, according to:

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

On 2017-12-27 17:15:43 +0100, Niels Möller wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > >> diff -r 20cf1131dc94 longlong.h > >> --- a/longlong.h Thu Aug 31 01:00:02 2017 +0200 > >> +++ b/longlong.h Tue Dec 26 10:59:24 2017 +0100 >

printf/repl-vsnprintf.c bug (was: GMP|MPIR|MPFR assertions)

[Cc to gmp-bugs] On 2018-01-18 23:14:12 +1100, sisyph...@optusnet.com.au wrote: > Just had a reply on the mingw64 mailing list. > Apparently, the test programs are not crashing - abort() is being called > following an assertion failure. > And this calls for a "break abort" prior to "run" being

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

On 2018-01-17 17:23:02 +0100, Marc Glisse wrote: > Indeed, it doesn't make sense to have both the assertion and > COUNT_LEADING_ZEROS_0. Would it work to remove the assertion instead? Yes, this works too (assuming that 0 will always be converted to +0). -- Vincent Lefèvre -

Re: Configure fails on 32-bit platform

On 2018-02-12 10:31:23 +0100, Torbjorn Granlund wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > As written above, this is for C compilers. But GMP also has assembler > code. So, you need to provide an option that will affect the assembler > c

Re: Configure fails on 32-bit platform

On 2018-02-11 19:21:33 -0500, Jeffrey Walton wrote: > That's not true. In fact, Stallman specifically tells the project to > adds the flags it needs. Below is from Section 7.2.3 of > https://www.gnu.org/prep/standards/standards.html. This would fix the > ARM compile problem, too: > > > > If

Re: Configure fails on 32-bit platform

On 2018-02-12 12:52:49 +0100, Torbjorn Granlund wrote: > It is less common that people set CC/CFLAGS to bad values (or at least > we don't hear about that very often). I don't think we should try to > accomodate that since it would result in lots of fragile complexity. > (If you don't agree,

Re: repl-vsnprintf.c:396:0: error: ISO C forbids an empty translation unit

On 2018-02-11 10:40:55 +0100, Torbjorn Granlund wrote: > Dennis Clarke writes: > > repl-vsnprintf.c:396:0: error: ISO C forbids an empty translation unit > > Our nightly builds get a few of those too, as warnings. I've decided I > can live with those as no platform

Re: parallel make bug in tune/ directory

On 2018-02-15 13:07:32 +0100, Torbjorn Granlund wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > The user always has the right to use the -j option if he wants to. > > Thanks for clarifying that, Vincent! > > Unfortunately, the result will be a bui

Re: [MPFR] Mac OS X power pc issue with C99

Hi, On 2018-02-19 09:19:02 -0700, arn...@skeeve.com wrote: > Hi. On this system: > > $ uname -a > Darwin arnold-robbinss-powerbook-g4-12.local 9.8.0 Darwin Kernel Version > 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power > Macintosh > > $ gcc --version >

GMP 6.1.2 t-count_zeros failure on ARM with assertions

I've built GMP 6.1.2 with assertions: ./configure --enable-assert --prefix=$HOME/opt/gmp-6.1.2 on an old ARM VM (Debian squeeze). But I get the failure: FAIL: t-count_zeros === t-count_zeros.c:31: GNU MP assertion failed: (n) != 0 FAIL t-count_zeros (exit status: 134) I've

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

On 2017-12-26 11:51:28 +0100, Niels Möller wrote: > Hmm, I guess the problem is > > #define count_leading_zeros_gcc_clz(count,x)\ > do { \ > ASSERT ((x) != 0); \ > (count) = __builtin_clzll (x);

Re: note: documentation bug

Hi, On 2018-02-25 20:37:49 +0100, Stéphane Bosio wrote: > the following can be read: > >-- Function: void mpz_rrandomb (mpz_t ROP, gmp_randstate_t STATE, >   mp_bitcnt_t N) > Generate a random integer with long strings of zeros and ones in > the binary

detection of FILE definition under Cygwin

It seems that FILE definition is not detected under Cygwin. Sorry for the lack of information, but in case someone can test or give more information... For the background, see https://stackoverflow.com/questions/49880944/cygwins-gcc-compiler-warning-from-mpfr-library and my answer

Re: Asserts considered harmful (or GMP spills its sensitive information)

On 2019-01-01 11:22:56 +0100, Joerg Arndt wrote: > * Vincent Lefevre [Jan 01. 2019 11:11]: > > [...] > > > > > > Second, the SIGABRT terminates the process and can write a core file. > > > > That's the default behavior, but you can trap SIG

Re: Asserts considered harmful (or GMP spills its sensitive information)

On 2018-12-31 14:38:17 -0500, Jeffrey Walton wrote: > On Mon, Dec 31, 2018 at 2:16 PM Vincent Lefevre wrote: > > > > On 2018-12-31 13:03:27 -0500, Jeffrey Walton wrote: > > > The GMP library uses asserts to crash a program at runtime when > > > presented with da

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

Re: failure with Clang's memory sanitizer: use-of-uninitialized-value

On 2019-03-29 06:20:31 +0100, Niels Möller wrote: > A bit unobvious what MPN_COPY expands to, but possibly some assembly > that the clang analyzer can't reason about? I've just looked at the Clang documentation, and it says: MemorySanitizer requires that all program code is instrumented. This

Re: not really a bug .. is there a way to set the host type in the Makefile.am ?

On 2019-02-18 22:24:35 -0500, Dennis Clarke wrote: > On 2/18/19 8:25 PM, Vincent Lefevre wrote: > > On 2019-02-18 16:44:48 -0500, Dennis Clarke wrote: > >> > >> This may seem like a strange question but I am running into many > >> problems while trying to

Re: compilation fails with CompCert-3.4 on Linux x86-64; patch proposed

On 2019-01-25 10:38:10 +0100, Niels Möller wrote: > Vincent Lefevre writes: > > The code given by the autoconf manual is: [...] > > # elif !defined HAVE_ALLOCA > > # ifdef __cplusplus > > extern "C" > >

Re: compilation fails with CompCert-3.4 on Linux x86-64; patch proposed

On 2019-01-24 08:46:12 +0100, DAVID MONNIAUX wrote: > Fix: do not declare alloca() unless HAVE_ALLOCA is set (CompCert > does not have alloca()). Patch below: I don't think this is correct, as alloca() may be available even though HAVE_ALLOCA is not defined (e.g. with MinGW). The code given by

Re: compilation fails with CompCert-3.4 on Linux x86-64; patch proposed

On 2019-01-24 15:57:13 +0100, DAVID MONNIAUX wrote: > > I don't think this is correct, as alloca() may be available even > > though HAVE_ALLOCA is not defined (e.g. with MinGW). > But why would you declare alloca() as a function even though you're > not going to use it (as far as I understand you

Re: GMP test fails with -flto

On 2019-07-03 10:45:24 +0200, Richard Biener wrote: > On Wed, Jul 3, 2019 at 9:49 AM Vincent Lefevre wrote: > > Here, after loop enrolling, the compiler could see that the arguments > > are known and generate a fixed puts(). This kind of optimization must > > not be done with

Re: GMP test fails with -flto

On 2019-07-01 13:44:04 +0200, Marc Glisse wrote: > On Mon, 1 Jul 2019, Martin Liška wrote: > > > On 6/24/19 8:57 PM, Marc Glisse wrote: > > > On Mon, 24 Jun 2019, Martin Liška wrote: > > > > > > > Using -flto one can see a test failure: > > > > > > This is well known, see the archives for

Re: GMP test fails with -flto

On 2019-07-01 16:36:23 +0200, Torbjorn Granlund wrote: > Vincent Lefevre writes: > > I suggest another solution: > > First try like now. If the format is unknown, check whether the > object file contains the string ".gnu.lto" (which should mean &g

Re: GMP test fails with -flto

On 2019-07-01 16:59:06 +0200, Marc Glisse wrote: > On Mon, 1 Jul 2019, Vincent Lefevre wrote: > > I suggest another solution: > > > > First try like now. If the format is unknown, check whether the > > object file contains the string ".gnu.lto" (which shoul

failure to detect format of `double' on MS-Windows

Hi, With 17862:b1ea8c11ae1e, I get: $ ./configure '--host=i586-mingw32msvc' '--disable-shared' 'host_alias=i586-mingw32msvc' [...] checking format of `double' floating point... od: conftest: No such file or directory od: conftest: No such file or directory unknown configure: WARNING: Could

Re: Latest commit introduces undefined behavior in hgcd2.c

On 2019-09-18 21:20:41 +0200, Torbjorn Granlund wrote: > Guido Vranken writes: > > My bignum fuzzer running at OSS-Fuzz came up with this: > > hgcd2.c:223:42: runtime error: shift exponent 64 is too large for > 64-bit type 'mp_limb_t' (aka 'unsigned long') > #0 0x76a4db in div2

Re: not really a bug but somewhat odd : checking compiler /usr/local/bin/gcc8 ... no, mpn_lshift_com

On 2019-07-28 06:12:06 -0400, Dennis Clarke wrote: > configure:6813: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest > Abort trap (core dumped) I don't know in your case, but I fear that this program is buggy. [...] > void > lshift_com (rp, up, n, cnt) > unsigned long *rp; >

Re: not really a bug but somewhat odd : checking compiler /usr/local/bin/gcc8 ... no, mpn_lshift_com

On 2019-07-28 12:44:55 +0200, Vincent Lefevre wrote: > On 2019-07-28 06:12:06 -0400, Dennis Clarke wrote: > > configure:6813: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest > > Abort trap (core dumped) > > I don't know in your case, but I fear that this program

Re: two tests fail for 6.1.2 on RISC-V rc64imafdc FreeBSD

On 2019-07-29 00:39:09 -0400, Dennis Clarke wrote: > FAIL: reuse > === > > ../../../gmp-6.1.2/test-driver: ./reuse: Exec format error > FAIL reuse (exit status: 126) > > FAIL: t-cmp_z > = > > ../../../gmp-6.1.2/test-driver: ./t-cmp_z: Exec format error > FAIL t-cmp_z (exit

Re: mpz_set_si loses long long value on Windows

On 2019-07-24 11:11:46 +0200, Torbjorn Granlund wrote: > Dim XY writes: > This 'signed long int' type has different sizes of linux (8 bytes) and > windows 64bit (4 bytes) platforms > (https://en.cppreference.com/w/cpp/language/types) > > Maybe it is better to use 'long long' type which

Re: mpz_set_si loses long long value on Windows

On 2019-07-24 11:29:42 +0200, Torbjorn Granlund wrote: > The problem with MPFR's approach is that the library API depends on the > compiler. Yes, but note that this is also the case with GMP, for the formatted output functions. :) > (We could solve that issue by rejecting pre-C99 compilers. GMP

Re: Having trouble building the library...

On 2020-03-05 22:30:51 +0100, Torbjorn Granlund wrote: > D Lee writes: > > *These are my steps:* > Downloaded and unpacked. > mkdir gmp-obj *outside* of the source tree. > cd gmp-obj > ../gmp-6.2.0/gmp-6.2.0/configure >> configure.log 2>&1 (see attached > configure.log file) > make

Re: assertion failure in snprntffuns.c:79 for i686-w64-mingw32

On 2020-01-11 16:33:30 +0100, Marco Bodrato wrote: > Ciao, > > Il Ven, 10 Gennaio 2020 5:04 pm, Vincent Lefevre ha scritto: > > On 2020-01-10 16:27:31 +0100, Marco Bodrato wrote: > >> Can you please try with the development version? > > > I get the following e

assertion failure in snprntffuns.c:79 for i686-w64-mingw32

Under Debian/unstable, I've configured GMP with: ./configure --host=i686-w64-mingw32 --disable-shared --enable-assert but "make check LOG_COMPILER=wine" gives: FAIL: t-printf == snprntffuns.c:79: GNU MP assertion failed: strlen (d->buf) == avail-1 FAIL t-printf.exe (exit status:

Re: assertion failure in snprntffuns.c:79 for i686-w64-mingw32

On 2020-01-10 08:44:13 +0100, Niels Möller wrote: > Vincent Lefevre writes: > > > Under Debian/unstable, I've configured GMP with: > > > > ./configure --host=i686-w64-mingw32 --disable-shared --enable-assert > > > > but "make check LOG_COM

Re: assertion failure in snprntffuns.c:79 for i686-w64-mingw32

On 2020-01-10 16:27:31 +0100, Marco Bodrato wrote: > This code was changed. > > https://gmplib.org/repo/gmp/rev/d6b57abdad8e > > Can you please try with the development version? I get the following error: FAIL: t-printf == gmp_vsnprintf return value wrong fmt |%Mu|

Re: GMP 6.2 error

On 2020-04-01 09:45:18 -0400, Dennis Clarke wrote: > On 2020-03-30 16:57, Torbjörn Granlund wrote: > > rodriguez-murias writes: > > > >When i make install : > > > >/usr/bin/mkdir: cannot create directory ‘/usr/local/share/info’: > > Permission denied > > > > The inability to write

Re: Patch: support callback on allocation overflow instead of calling abort()

On 2020-10-06 04:41:42 +0100, Colin Caine wrote: > This is used by Julia to raise an OutOfMemory exception rather than having > the Julia process itself abort. > > Others on stackoverflow, etc, have experienced similar problems with > undesired aborts(), so this patch would probably be useful to

Re: Patch: support callback on allocation overflow instead of calling abort()

On 2020-10-06 11:51:29 +0200, Marc Glisse wrote: > On Tue, 6 Oct 2020, Vincent Lefevre wrote: > > > On 2020-10-06 04:41:42 +0100, Colin Caine wrote: > > > This is used by Julia to raise an OutOfMemory exception rather than having > > > the Julia process its

Re: Patch: support callback on allocation overflow instead of calling abort()

On 2020-10-06 16:59:10 +0200, Niels Möller wrote: > There are other approaches to avoid these crashes, e.g., I think the > recent emacs integration uses a (configurable) limit on bignum size, and > will raise an emacs exception long before hitting GMP's limits, and the > emacs process can go on

Re: mpz_sizeinbase() bug

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 digits in the given

Re: overflow in mpz type with a simple mpz_add_ui

On 2020-09-21 21:17:36 +0200, Torbjorn Granlund wrote: > Vincent Lefevre writes: > > This is not properly documented, then. The manual says: > >'mpz_add_ui', 'mpz_sub_ui', 'mpf_add_ui' and 'mpf_sub_ui' benefit >from an in-place operation like 'mpz_add_ui(x,x,

Re: overflow in mpz type with a simple mpz_add_ui

On 2020-09-21 18:16:15 +0200, Torbjorn Granlund wrote: > Vincent Lefevre writes: > > So the overflow occurs in "mpz_add_ui (z, z, 1);", though this > operation doesn't need a larger mpz_t and could even be done > in place: no carry occurs here, and note that a ca

overflow in mpz type with a simple mpz_add_ui

With GMP 6.2.0 (Debian's package libgmp10:i386) on x86_64 in the 32-bit ABI, i.e. when compiling with -m32, I get the following error: cventin:~> cat tst.c #include #include int main (void) { mpz_t z; mpz_init_set_ui (z, 17); mpz_mul_2exp (z, z, 0xffbc); printf ("OK\n");

mini-gmp.h FILE test update from gmp.h

In mini-gmp/mini-gmp.h, concerning FILE tests: /* This long list taken from gmp.h. */ but the list in GMP 6.2.0 and the current repository is not up-to-date. See attached patch. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

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 +

bug in longlong.h for aarch64 sub_ddmmss

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"

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

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, bu

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,

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

On 2020-06-06 14:28:21 +1000, Mihai Preda wrote: > I'm using libgmp-dev 6.1.2 on Ubuntu myself, but the bug report > concerns an unspecified version of GMP on Windows. I have reasons to > suspect the bug is valid for the most recent GMP. Clear cause analysis > and proposed solution is included. >

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

most > likely evolution is about 2), at some indeterminate point in the future > (hopefully not too far). Couldn't the C interface *optionally* support more than C89? > On Sat, 6 Jun 2020, Vincent Lefevre wrote: > > > There's the same issue with 32-bit architectures, whatever the OS. >

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

On 2020-06-09 10:21:31 +0200, Marc Glisse wrote: > On Tue, 9 Jun 2020, Niels Möller wrote: > > > Marc Glisse writes: > > > > > On Sat, 6 Jun 2020, Mihai Preda wrote: > > > > > > > I would rather suggest to support intmax_t and uintmax_t. > > > > > > That's one possibility for C (and C++,

typos in a comment in longlong.h

Hi, In longlong.h: /* FIXME: Extend the immediate range for the low word by using both ADDS and SUBS, since they set carry in the same way. Note: We need separate definitions for thumb and non-thumb to to th absense of RSC under thumb. */

Re: FAIL: t-printf on Debian sparc64 with gcc-10 patched for gcc bugid 97939

On 2020-12-06 08:23:40 +, Dennis Clarke wrote: > Sadly the situation continues here on Debian sparc64 : I suggest that you try with -fsanitize=undefined -fno-sanitize-recover just in case an issue would be detected before the actual crash. > I just go single stepping around madly for a while

Re: with strict C99 the tests/mpz/convert.c needs #include

On 2020-11-09 10:14:37 +0100, Torbjorn Granlund wrote: > Vincent Lefevre writes: > > In the context of the call, the values will always be nonnegative > so that this is OK, but there is a risk that some future developer > might reuse this function in another context,

Re: GMP bootstrap fails with Autoconf 2.69d

On 2020-11-15 23:49:10 +0100, Hans Åberg wrote: > One can also have an additional URL argument, which defines a variable > PACKAGE_URL: > > AC_INIT(GNU MP, GMP_VERSION, [gmp-bugs@gmplib.org (see > https://gmplib.org/manual/Reporting-Bugs.html)], gmp, [https://gmplib.org/]) If I understand

Re: GMP bootstrap fails with Autoconf 2.69d

On 2020-11-16 10:29:13 +0100, Hans Åberg wrote: > > On 16 Nov 2020, at 01:18, Vincent Lefevre wrote: > > If I understand correctly, the goal is to have the Reporting-Bugs.html > > URL together with the e-mail address. > > Yes, and such a feature is not supported.

Re: with strict C99 the tests/mpz/convert.c needs #include

On 2020-11-07 18:45:52 -0500, Dennis Clarke wrote: > However the tests blow up due to : > > convert.c:143:11: error: implicit declaration of function 'strcasecmp' > is invalid in C99 > > So that is easy to fix. > > ijiraq# diff -u ./tests/mpz/convert.c.orig ./tests/mpz/convert.c > ---

Re: Debian Linux SPARC64 issue with FAIL t-printf (exit status: 139)

On 2020-11-22 13:16:45 -0500, Dennis Clarke wrote: > After hours of running this in circles for both 6.2.0 and 6.2.1 > with both gcc 9.3.0 ( Debian 9.3.0-18 ) and also the latest > gcc 10.2.0 (Debian 10.2.0-17) I can report that the test t-printf > does fail every time. With a consistent configure

Re: Debian Linux SPARC64 issue with FAIL t-printf (exit status: 139)

On 2020-11-23 01:00:30 +0100, Vincent Lefevre wrote: > FYI, no failures on gcc202.fsffrance.org with > > ./configure ABI=64 --enable-cxx --disable-assembly --enable-shared > --enable-static --enable-fft > > Linux gcc202 5.9.0-2-sparc64-smp #1 SMP Debian 5.9.6-1 (2020-11-

Re: uint_least32_t is in stdint.h not in inttypes.h

On 2020-11-15 22:21:18 +0100, Felix von Leitner wrote: > I was trying to compile gmp with my libc, dietlibc, and got an error > that uint_least32_t is not defined. > > Well, it is defined, and as far as I can tell in the right header file, > too: stdint.h. > > However, gmp-impl.h reads as

Re: Arithmetic bug on ARM (STM 32 F4)

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:

Re: Arithmetic bug on ARM (STM 32 F4)

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

Re: Limitation of the mpz_get_str function

On 2021-02-16 14:22:20 +0100, Christophe Clavier wrote: > I suggest to modify the type of i to long int or to unsigned long int. long or unsigned long may still be on 32 bits, e.g. under MS Windows. I think that a more appropriate type in the context of a string (or more generally an array of

Re: Segmentation fault with mpz_inp_raw on gcc45

On 2021-09-15 16:13:55 +0200, Torbjorn Granlund wrote: > I tried to reproduce this on several systems. I failed; mpz_inp_raw > returns 0 for me as it should. > > I cannot be sure I got test_dummy2.save right. I did include the line > that asked to be ignored. Should I have ignored it? I added

Re: Segmentation fault with mpz_inp_raw on gcc45

On 2021-09-15 17:05:42 +0200, Paul Zimmermann wrote: > 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 I can reproduce the segfault only with a 32-bit ABI.

Re: Segmentation fault with mpz_inp_raw on gcc45

On 2021-09-15 17:34:01 +0200, Vincent Lefevre wrote: > On 2021-09-15 17:05:42 +0200, Paul Zimmermann wrote: > > 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 co

Re: mail archives are lost

On 2022-02-21 08:50:09 +0100, Paul Zimmermann wrote: > 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).

Re: clang warning about mini-gmp.c when used in Emacs

On 2022-04-15 07:29:34 +0200, Niels Möller wrote: > I have two minor comments on this proposed fix: > > 1. Is the void cast really needed? Corresponding macros in gmp-impl.h > are defined like > > #if WANT_ASSERT > #define ASSERT_CARRY(expr) ASSERT_ALWAYS ((expr) != 0) > #define

Re: Unsigned integer overflow in `toom_eval_pm2.c`

On 2023-09-03 22:16:21 +0200, Niels Möller wrote: > Andrew Teylu writes: > > >> I am not sure the arithmetic on unsigned types is what clang is unhappy > >> about, though. Perhaps it dislikes the xor with "neg", which is a > >> signed variable. > > I can't say precisely what implicit

Re: Unsigned integer overflow in `toom_eval_pm2.c`

On 2023-09-04 09:52:23 +0200, marco.bodr...@tutanota.com wrote: > Should the value ~0 be written as ~0U to be correctly assigned to an > unsigned? IMHO, this would be better as this would make the signedness of the types more consistent (the goal being to have an unsigned int for all these

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

Re: error from GMP_ASM_W32 when building with IBM Open XL C/C++ for AIX 17.1.1

On 2023-10-02 14:51:23 +0200, Vincent Lefevre wrote: > I tried to build GMP 6.3.0 with openxlC on AIX (for testing) using > > ./configure --prefix=$HOME/gmp-openxlc > CC=/opt/IBM/openxlC/17.1.1/bin/ibm-clang_r CFLAGS=-O2 > > on cfarm119.cfarm.net (a.k.a. gcc119), but

incorrect configfsf.guess permissions for GMP 6.3.0

In the gmp-6.3.0.tar.xz tarball: -rw-r--r-- tege/wheel49936 2023-07-29 15:42:16 gmp-6.3.0/configfsf.guess The execute permissions are missing. This yields the following error: -bash-5.1$ ./configfsf.guess -bash: ./configfsf.guess: The file access permissions do not allow the specified

error from GMP_ASM_W32 when building with IBM Open XL C/C++ for AIX 17.1.1

Hi, I tried to build GMP 6.3.0 with openxlC on AIX (for testing) using ./configure --prefix=$HOME/gmp-openxlc CC=/opt/IBM/openxlC/17.1.1/bin/ibm-clang_r CFLAGS=-O2 on cfarm119.cfarm.net (a.k.a. gcc119), but got the following warnings and error related to assembler: [...] checking for

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: clang warning about mini-gmp.c when used in Emacs

On 2022-04-19 20:16:51 +0200, Niels Möller wrote: > I've always liked gcc -Wall. I think it adheres to its design to warn > only about things that (1) are prone to be errors, and (2) in the case > that they aren't errors, are easy to clarify in a way that makes the > compiler stop warning about

use of emphasize for math in the HTML GMP manual

GMP currently uses emphasize for math in the HTML GMP manual, via @math{...} (and MPFR has copied to it). For instance, for mpz_mul_2exp, one has "Set rop to op1 times 2 raised to op2." where the whole "op1 times 2 raised to op2" is emphasized, i.e. typically rendered in italics (or with a

Please change http://mpfr.org to https://www.mpfr.org/

Hi, The GMP manual doc/gmp.texi currently has @url{http://mpfr.org}. But mpfr.org is poorly handled by Inria (no certificate and the redirection to https://www.mpfr.org/ does not always work, possibly to a temporary URL like currently, as one obtains mpfr.loria.fr). This URL should be changed to

Re: GMP does not detect float exponent overflow while reading floating point numbers

On 2022-09-16 16:34:58 -0400, Eric Li wrote: > Thanks to https://stackoverflow.com/a/73740744, looks like the cause of > the bug it that GMP triggered a signed overflow in the following code > (from https://gmplib.org/repo/gmp/file/feb796a7f683/mpf/set_str.c#l315) [...] I've given an answer:

Re: issue with Microsoft compiler

On 2023-02-13 10:20:07 +0100, Marc Glisse wrote: > On Mon, 13 Feb 2023, Niels Möller wrote: > > My view is that GMP simply depends on the required semantics of the C > > specification. And negating mp_limb_t values is something that's done in > > lots of places. I'm not aware of any workaround

Re: issue with Microsoft compiler

On 2023-02-13 11:54:50 +0100, Marc Glisse wrote: > Another option, if it is just the one place in gmp.h, would be to replace -X > with 0-X (or the uglier ~X+1 but that does not seem necessary). I find 0-X much uglier and it could even more deserve a warning due to the use of mixed signed-unsigned

integer overflow in mini-gmp due to integer promotion

Hi, When I test MPFR with ./configure --with-mini-gmp=/home/vlefevre/software/gmp/mini-gmp CC=gcc-13 CFLAGS="-O2 -fsanitize=undefined -fno-sanitize-recover -DMINI_GMP_LIMB_TYPE=short" I get lots of failures in mini-gmp.c (I suspect that the errors were hidden by some optimization in GCC 12

Re: integer overflow in mini-gmp due to integer promotion

On 2023-07-19 21:24:03 +0200, Niels Möller wrote: > Vincent Lefevre writes: > > > ./configure --with-mini-gmp=/home/vlefevre/software/gmp/mini-gmp CC=gcc-13 > > CFLAGS="-O2 -fsanitize=undefined -fno-sanitize-recover > > -DMINI_GMP_LIMB_TYPE=short" > >

Re: integer overflow in mini-gmp due to integer promotion

On 2023-07-19 22:08:24 +0200, Niels Möller wrote: > Vincent Lefevre writes: > > > On 2023-07-19 21:24:03 +0200, Niels Möller wrote: > >> I think that's needed, to be able to support any size of > >> MINI_GMP_LIMB_TYPE. Something like > >> > >

  1   2   >