Re: Leading zeroes

writes: I encountered a bug while running the R version. While the isprime() function usually is able to handle strings, it apparently gets confused if there are leading zeroes. You need to report this "R" bug to whomever is responsible for this "R version". -- Torbjörn Please encrypt,

Re: crash on __gmpz_init

"igor pesando - Dept of Physics, University of Torino" writes: thanks for the quick answer on the first case. But the issue is also present if I use malloc in C. People have explained what you did wrong, which was several things. Something you might consider: It would have been pretty

Re: crash on __gmpz_init

Vincent Lefevre writes: On 2024-01-22 11:02:21 +0100, Marc Glisse wrote: > Hello, > > mpz_class M[LINES][COLS]; > > you are trying to put an array with millions of elements on the stack, so > the stack overflows. Very large arrays need to be allocated on the heap in > C++

Re: errors in make check

Marc Glisse writes: could you check with the latest snapshot from https://gmplib.org/download/snapshot/gmp-next/ ? If that does not help, can you try with a different compiler (a real gcc, or maybe a non-Apple llvm, you can probably get them through homebrew or macports)? It would

Re: Make check fail on GMP-6.3.0 after installing macOS Sonoma 14.0 (23A344)

We are not in a position to debug this, as we don't have recent enough Mac x86 hardware for running recent enough macos to run these later problematic Apple compilers. No, I am not making this up, Apple likes to play these games with what is supported where. An educated guess is that this is an

Re: GMP 6.3.0 - make tuneup - Stop

Zsolt Kalmandi writes: ./configure --build=silvermont-pc-linux-gnu --enable-fat A fat build is incompatible with tuneup. I don't even know how it would work. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list

Re: Build failure on macOS Sonoma 14.0 beta

Marc Culler writes: If you read my earlier messages you will see that I did try that and that it failed in exactly the same way. I am not trying to get the GMP maintainers to do anything which is impossible (unless you count trying to get Apple to fix bugs -- something which is

Re: Build failure on macOS Sonoma 14.0 beta

Marc Culler writes: The build fails in the same way when I remove --enable-fat but use export CFLAGS="-arch x86_64 -mmacosx-version-min=10.9 -mno-avx -mno-avx2 -mno-bmi2" If it "fails in the same way" without --enable-fat, your machine has gremlins. The problem symbol is very specific to

Re: Build failure on macOS Sonoma 14.0 beta

Marc Culler writes: With no CFLAGS and using $ ./configure --with-pic --enable-fat --prefix=X I get almost the same error (the difference being the distance of the branch), namely: It is not possible for the GMP maintainers to analyse the effects of various options which we do not

Re: Build failure on macOS Sonoma 14.0 beta

Marc Culler writes: I am unable to build gmp-6.2.1 on macOS Sonoma beta using the command line tools released for that system. The system is up to date. The hardware of the build system is "1.6 GHz Dual-Core Intel Core i5". The build commands I am using are: $ export

Re: Unsigned integer overflow in `toom_eval_pm2.c`

Andrew Teylu writes: When I run `multiply.c` from gmpbench [https://gmplib.org/gmpbench], I'm seeing an unsigned integer overflow in `toom_eval_pm2.c` on this line: neg ^= ((k & 1) - 1) I fully appreciate that unsigned integer overflow is implementation defined, but I am not sure

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

Brett Kuntz writes: Go to line 248 inside mpn/generic/mod_1.c mp_limb_t pre[4]; There is no such thing on an unedited version of GMP 6.3, not on line 248 not anyplace else in that file. mpn_mod_1_1p_cps (pre, b); Only initializes pre[0], pre[1], and pre[3]. ***NOT*** pre[2].

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

Brett Kuntz writes: 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); mp_limb_t pre[4] is not initialized It does not exist, only pre[0] through pre[3] does. and the mpn_mod_1_1p_cps() function never

Re: Valgrind reports use of uninitialised value for __gmpz_powm_sec on i686 host

Trevor Spiteri writes: Valgrind is reporting the use of uninitialised value(s) in __gmpz_powm_sec for i686 host, though I found no similar issue for x86_64 host. This issue started in 6.3.0, and was not there for 6.2.1. I tried this, and it looks like a valgrind bug rather than a GMP bug.

Re: Outdated libtool creates trouble on macOS

Marc Glisse writes: Do you think we could increase AC_PREREQ to 2.70 (or even 2.71), which would allow a couple more cleanups? I don't think we want to support users rerunning autoconf with an older version than the one we use to generate the tarballs. Sure. Being compatible with older

Re: Outdated libtool creates trouble on macOS

Marc Glisse writes: It looks recent enough that the piece of code causing trouble on macOS has been modified. I think we can go with that, we can always upgrade again later if needed. We have been using the default shell.gmplib.org autotools tools for a week now, for generating the public

Re: Side-channel leakage in the mpz_powm_sec interface

> Therefore, > additional layers of side-channel obfuscation is needed, like standard > RSA message blinding, mod argument blinding, exponent blinding. sure, but I think that should be performed by upper level code, as how you do blinding depends on the algorithm and operation you're

Re: Side-channel leakage in the mpz_powm_sec interface

Niels Möller writes: I know you've done more work on that recently, while I have no idea how "mod argument blinding" works... A random ring extension. Yes, mod argument invariance will still be there, unless one changes extension for each multiply/squaring inside the modexp loop, but an

Re: Side-channel leakage in the mpz_powm_sec interface

marco.bodr...@tutanota.com writes: This sounds not too complex to do. Even if, as usual, C code is prone to compiler optimizations... I think this is a good idea. The concern for compilers messing up secure code is very valid. An example is that clang makes our mpn_sec_tabselect useless by

Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240

Marc Glisse writes: There is, it is called (u)intptr_t, the standard name for an integer type that can hold a pointer. Right! I only naively checked intmax_t, assuming max would mean max. :-) There seem to be a problem with arithmetic on uintptr_t, though. The compiler generates a plain

Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240

Marc Glisse writes: Hmm, but with that proposed patch, configure later fails with checking size of void *... 16 checking size of unsigned short... 2 checking size of unsigned... 4 checking size of unsigned long... 8 checking size of mp_limb_t... 8 configure: error: Oops, mp_limb_t

Re: Outdated libtool creates trouble on macOS

Marc Glisse writes: If I run .bootstrap now on shell (freebsd 12.2) after removing /home/gmp/usr/bin from my PATH so I get the tools from /usr/local/bin, I have a number of errors, but I think that's just because libtool is not installed. It is now. Torbjörn, I think we could start

Re: Possibly an annoying test in configure

Dennis Clarke writes: Pretty sure that should be "int main (void) { return 0; } ". Surely that is not how the implicit main() declaration looks? A new compiler warning is warranted. So add (int argc, const char **argv)! Oops, unused parameters, darn. We need to make a fake dependency on

Re: Possibly an annoying test in configure

Niels Möller writes: I would *not* want to support -Werror as something to be used in general by users, with arbitrary compiler versions, compile flag tweaks, etc. Indeed. There is a fashion among compiler maintainers to accept an ever decreasing subset of C, making any effort at producing

Re: GMP Error Reporting

"posihydr" writes: The problem occurs when the formula in GMP and < Picture 1 is used to calculate PI, calculate the constant C to the 3/2 power, output "Floating point exception" after running the program, and use GDB debugging to find that the program receives signal SIGFPE when

Re: Outdated libtool creates trouble on macOS

FX Coudert writes: PS: second patchlet, to deal with these two macros: > warning: The macro `AC_HEADER_STDC' is obsolete. > warning: The macro `AC_HEADER_TIME' is obsolete. If you, Marc, can take a look at those proposed changes, I think they should be applied to the head gmp repo, not

Re: Outdated libtool creates trouble on macOS

FX Coudert writes: One other question: our Linux builder, which is running from Github Actions, fails to download from gmplib.org I thought only the mercurial repo was firewalled, is that not the case? Github is firewalled off in its entirety. The firewall cannot inspect packets to make

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: integer overflow in mini-gmp due to integer promotion

Vincent Lefevre writes: The goal is to try to find bugs in MPFR. With limbs of small size, particular cases (such as some limbs being 0 or -1) could occur more often. Have you looked at GMP's asl.h? It allows for tiny limbs, but GMP needs work before any small limbs size fully works.

Re: Undefined reference to lexar_line?

philliprusso writes: Any insight on why undefined reference to lexar_line when making gcc-11? This mailing list is intended exclusively for GMP bug reports. Other software projects have their own bug reporting mechanisms. -- Torbjörn Please encrypt, key id 0xC8601622

Re: Bugs with Ventura system with Macos

Michel Collin writes: I used, for a long time C with GMP, on my Mac ( cryptography calculs ), and suddenly the applications I had made, who works very well on Monterey system, doesn’t work anymore on Ventura System. The compilation is OK but, for example, if I calculate a number with

Re: mpz_probab_prime_p crashes?

Philip Riebold writes: The test program below, pt3.c is the simplest I could produce to demonstrate the problem. If that simple program would trigger a genuine GMP bug, that would be astonishing indeed. I have no idea why your computer gets a segfault. Perhaps the malloc implementation is

Re: make check failed on debian old system using arm complier

The reporter cross-compiles GMP, then apparently tries to execute Arm binaries on x86_64, unsurprisingly with limityed success. Not a GMP bug. The gmp-bugs list is not the right place for discussing possible remedies (such as emulation). -- Torbjörn Please encrypt, key id 0xC8601622

Re: Miscompilation on arm64 with GCC LTO

Have you tried using a recent GMP snapshot? If not, please do. https://gmplib.org/download/snapshot/ -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Miscompilation on arm64 with GCC LTO

Arsen Arsenović writes: I'm forwarding a message from Sam James, a fellow Gentoo developer, as he seems to be having some mail delivery issues. He surely has some patience issues. Please let Sam know about mailing list moderation and perhaps about that the earth is round and thus have

Re: Whitespace after minus sign in mpz_set_str

Marc Glisse writes: This was also discussed in https://gmplib.org/list-archives/gmp-bugs/2013-December/003257.html I don't know if anything changed... Probably not. This spacey "feature" is not expected to be widely used. -- Torbjörn Please encrypt, key id 0xC8601622

Re: 6.2.1 Bus error

You know, we might do with some more detail on what your experience with GMP might be. Such as the platform, how you built GMP, what program you ran which triggered a "Bus error". If something is wrong with, say, a car, do you let the car repair shop know anything about what the problem is,

Re: Error related to GCC LTO optimization for GMP at ARM AArch64

Some One writes: Dear GMP devs, As I reported the same issue to gentoo bugzilla and retried to reproduce for them with all logs attached, I've found out that iproute2 magically started to compile OK. However, there were other sources whose compilation was broken. Unfortunately, I

Re: Error related to GCC LTO optimization for GMP at ARM AArch64

Some One writes: I've found the problem related to GCC LTO optimization for GMP for ARM aarch64 under QEMU with ARM Neoverse-N1 virt-4.2 (Oracle Cloud) and ARM virt-7.2 (Apple M1) both running the latest Gentoo with gmp-6.2.1-r5 compiled by both gcc version 11.3.1 20221209 and gcc

Re: Test Failures on m1 MacBook Ventura: stack-overflow on address

Pasta Pasta writes: Process 46677 launched: '/Users/user/Development/dash/src/test/test_dash' (arm64) Running 1 test case... Process 46677 stopped * thread #1, name = 'd-test', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x16fe0) frame #0:

Re: GMP 6.2.1 core2 x86_64 assembler error "operands invalid for `movq'"

I seem to have misread the report. I thought the movq mem,xmm instructions were the problem. I pushed a fix to the repo. Please try it. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org

Re: GMP 6.2.1 core2 x86_64 assembler error "operands invalid for `movq'"

ni...@lysator.liu.se (Niels Möller) writes: So would be useful to try if replacement movq --> movd (i) solves the problem on (older) macos, and (ii) produces identical object code on systems with more up-to-date assemblers. Note that the movq instances the old assembler complains about

Re: GMP 6.2.1 core2 x86_64 assembler error "operands invalid for `movq'"

Simon Sobisch writes: That is an old MacBook with the most current "developer command line tools" that were available (from 2013/2014 if I remember correctly). I am afraid obsolete systems might get less developer attention... Sigh. Sadly I don't know enough about assembly to patch it

Re: GMP 6.2.1 core2 x86_64 assembler error "operands invalid for `movq'"

Simon Sobisch writes: config.status: linking ../mpn/x86_64/core2/popcount.asm to mpn/popcount.asm config.status: linking ../mpn/x86_64/core2/hamdist.asm to mpn/hamdist.asm tmp-popcount.s:181:suffix or operands invalid for `movq' tmp-hamdist.s:206:suffix or operands invalid for `movq'

Re: use of emphasize for math in the HTML GMP manual

Vincent Lefevre writes: 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

Re: Minor mistakes in the manual

Thank you! I have applied most of your change suggestions! -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs

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

"Marco Bodrato" writes: gmp$ ./configure CC="gcc -Wall -Werror" [...] configure: error: could not find a working compiler, see config.log for details Yes, you are right... a too fussy compiler is not considered a working compiler by the "configure" script :-) The language accepted

Re: 2 minor issues on Windows

There is some sort of sick competition between certain compilers to have the most warnings for valid C. I don't think we should play their game, and as a result obfuscate the GMP sources. Incidantally, arithmetic on unsigned types is well-defined. Unlike that of signed types. Should not

Re: 2 minor issues on Windows

Marco Bodrato writes: - *__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK; + *__gmp_rp = (1 + ~ *__gmp_up) & GMP_NUMB_MASK; Let's please not do this. There is some sort of sick competition between certain compilers to have the most warnings for valid C. I don't think we should play their game,

Re: mail archives are lost

Yes, the archiving function is not yet back. I will fix that as soon as I can find the time. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Errors making GMP621 on SCO Openserver 6.

Marco Bodrato writes: ==> /tmp/config.guess.log <== ./config.guess: syntax error at line 284: `(' unexpected Perhaps the $(command ...) syntax is not known by the old SCO shell? Really old /bin/sh only had `command ...`. -- Torbjörn Please encrypt, key id 0xC8601622

[ADMIN] GMP mailing list

The GMP mailing lists have been down for several months, but I am now working on resuming their operation. If you get this message, chances are that things now work again. The backgound is that a security update to the (FreeBSD) virtual server broke the mailing list software (mailman). I

Re: Fwd: math/gmp FreeBSD 12.2 Ports build failure on sparc64

I took the trouble of installing FreeBSD under qemu. I think I understand the problem: sparc64-fbsd$ gcc -v Using built-in specs. Target: sparc64-undermydesk-freebsd Configured with: FreeBSD/sparc64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD]

Re: Fwd: math/gmp FreeBSD 12.2 Ports build failure on sparc64

Alex Dupre writes: tmp-gcd_11.s: Assembler messages: tmp-gcd_11.s:210: Error: Illegal operands tmp-gcd_11.s:211: Error: Illegal operands tmp-gcd_11.s:212: Error: Illegal operands The m4-generated assembly codes above (w/ w/out PIC) differ in these lines:

Re: macOS version detection broken in configure

Marc Glisse writes: From a quick look at the mailing list and the git repository, it seems to have been entirely unmaintained for more than 2 years now :-( https://www.gnu.org/software/libtool/ "Libtool is currently looking for a maintainer." -- Torbjörn Please encrypt, key id 0xC8601622

Re: GMP 6.2.1 Aborting when running tuneup program in one.cold()

Simon Sobisch writes: Am 20.10.2021 um 16:19 schrieb Torbjörn Granlund: > When tuneup cannot measure things accurately, it bails out. That's interesting. Is there any thing I can do to help tuneup measure things accurately? Make sure your system is idle except for the tuneup proc

Re: Configuration on IceLake

Arturo Fernandez writes: Just for clarification, I'm no longer seeing the 'm4-ccas: Permission denied' error. I started on a fresh system (cloud-based) running CentOS8.4, unpacked gmp-6.2.99-20211010014524 and simply run ./configure, which returned: Version: GNU MP 6.2.99 Host type:

Re: Configuration on IceLake

Arturo Fernandez writes: Hello. I was finally able to get back and work on this configuration. Yesterday evening I downloaded the latest version (gmp-6.2.99-20211010014524) but it is still unable to recognize IceLake. The command configure is returning: Version: GNU MP 6.2.99 Host

Re: See attached test results.

Did you notice this part: tests are not linked to the newly compiled library local version is: 6.2.1 linked version is: 6.2.0 That's what's wrong. GMP's tests then exits to avoid generating spurious test results. Why it happens? Well, some sort of linking path of your system

Re: Segmentation fault with mpz_inp_raw on gcc45

Vincent Lefevre writes: In mpz/inp_raw.c, I think that abs_csize*8 yields an integer overflow on large sizes. Indeed. Going from byte count to bit count to limb count is non-trivial without risking overflow, even if the end result will typically be smaller than the incoming byte count

Re: Segmentation fault with mpz_inp_raw on gcc45

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 LF at each appparent line end, including the ignore line. --

Re: Segmentation fault with mpz_inp_raw on gcc45

Paul Zimmermann writes: I was thus expecting it to return 0 in case of an invalid file. OK, so you deliberately sen d junk to mpz_inp_raw. That is fine, but it was not clear from your report. -- Torbjörn Please encrypt, key id 0xC8601622 ___

Re: Segmentation fault with mpz_inp_raw on gcc45

Paul Zimmermann writes: $ 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. -- Torbjörn Please

Re: libgmp.a text relocation error on powerpc-*

George Koehler writes: This report is for GMP 6.2.1. The powerpc32 asm in the static library libgmp.a contains a text relocation; this causes a linker error when I use LLD to link a program with libgmp.a. I have no problem with the shared library. The fix is simple: delete the

Re: Configuration on IceLake

Arturo Fernandez writes: Sorry for the late reply as things have been piling up. I have tried gmp-6.2.99-20210902195716 in different systems but it fails while building it. Here is an error: ../libtool: line 1766: ../mpn/m4-ccas: Permission denied That error you need to debug locally.

Re: Rounding error

Paul Zimmermann writes: Of course you can add say 100 guard bits, then the probability to get an incorrect rounding is about 2^-100... You're joking, but this was sort-of my thinking when designing mpf! -- Torbjörn Please encrypt, key id 0xC8601622

Re: Configuration on IceLake

Arturo Fernandez writes: I wasn't expecting Nehalem so my guess is that it doesn't recognize IceLake and is assigning some default value. We let all unknown "model" numbers mean nehalem. This is so that both unknown low-end cores and unknown high-end cores will at least work. There have

Re: gmp 6.2.1 self-tests start failing with latest macOS Monterey beta

Dominik Schloesser writes: Since update to latest beta of upcoming macOS 12, `make check` fails with release gmp 6.2.1 (see attached log) I've retested with HEAD version gmp, and that runs without any error on this beta. Perhaps this change is relevant:

Re: Crashes after upgrading to GMP 6.20+

Michael Maroszek writes: The code works flawlessly on the Boardwell architecture (and a lot more!). The issue arises only on the mentioned Celeron. As I wrote before, GMP's fat mechanism knows of that processor. So it is not a simple oversight on our part which causes the problems you

Re: Crashes after upgrading to GMP 6.20+

Michael Maroszek writes: i am using an unpatched gmplib version and the problem was introduced with version 6.20 (still exists in 6.21). Reverting to 6.1.2 solves the problem. There are no GMP versions 6.20 or 6.21. Are these PHP releases, perhaps? The problem does not happen on all

Re: 68000 issue in longlong.h

Thanks for your analysis, Niels! I now agree that sticking an & in there is the right thing to do. (I'm adding a test config for plain 68000 too; I thought we had one already but that does not seem to be the case.) -- Torbjörn Please encrypt, key id 0xC8601622

Re: AW: 68000 issue in longlong.h

"se...@t-online.de" writes: Can you explain why __umul_tmp1 should not be an "early-clobber output"? Because it is not written to before we're done with the input. (I wrote this code close to 30 years ago. It is stll possible that it is buggy, but it looks correct to me and it has been in

Re: AW: 68000 issue in longlong.h

gmp-bugs-ow...@gmplib.org writes: With his change the tests pass so I think the change is reasonable. I disagree. If I am right that the inline asm is correct, changing it to avoid triggering a compiler bug is not a reasonable change. But perhaps I am wrong and the inline asm is buggy, but

Re: 68000 issue in longlong.h

"se...@t-online.de" writes: Hello, I am compiling and testing libgmp for AmigaOS. Yes, I am crazy. I use Thanks to bebbo's gcc https://github.com/bebbo/amiga-gcc I was quite successful. I had

Re: t-lucnum_ui segfaults

Paul Dufresne writes: make[4] : on entre dans le répertoire «  /home/paul/gpc2/gcc-4.6.4/gmp-4.3.2/tests/mpz » Are you seriously using GMP 4.3.2? It is 11 years old! Please use some slightly less obsolete release. -- Torbjörn Please encrypt, key id 0xC8601622

Re: Warning when using gmp 64 bits in vcpkg

Cristofer Martins writes: The warning is as follows(MSVC) "warning C4146: unary minus operator applied to unsigned type, result still unsigned" Line 2240 inside gmp.h code "*__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK;" I hope its fixed since its create warnings for all files that includes

Re: memory leak huge number of digits mpz_mul,mpf_sqrt_ui

Are you famiiar with valgrind? It is a great tool for detecting memory leaks. I used it to oonfirm that GMP indeed does not leak for your test cases. (You seem to have forgotten to mention the system you used for these experiments; I used an amd64 cpu running debian.) Your analysis of what is

Re: memory leak huge number of digits mpz_mul, mpf_sqrt_ui

Your analysis is very likely incorrect. You may cause the same "leak" without GMP. Just malloc a set of large chunks of different sizes. Access them to make sure it is actually there, then free them in some random order. Often the free calls will not have given back the memory to the system.

Re: small patch to suppress a warning

I think there might be better places to discuss compiler warnings than the gmp-bugs list. I think most of us agree that compiler warnings for valid C code are sometimes useful. For example, valid warnings about unitialised variables seem pretty uncontroversial. But please continue the

Re: Arithmetic bug on ARM (STM 32 F4)

ttt = 3578942983869995381409279381784954092773488221200587338717407747084074518600438737913956360066709506626656635118978526559637095289631190671071178702312877654 but ttt should be

Re: Illegal instruction fix

William Blanke writes: At Chia, we are using GMP inside Python binary wheels. This means we compile GMP on one machine and then run this code on different machines, possibly with different CPUs. When GMP 6.2 was released, we encountered illegal instruction crashes on Intel CPUs older

Re: GMP website: old release (3.1.1) cannot be downloaded

"Peter Jin" writes: It appears that at least one of the old archived GMP releases (version 3.1.1) cannot be downloaded from the GMP website. This is possibly due to bad permissions on the file (not readable by the web server?). Or possibly due to an incorrect URL. (I suggest that you use

Re: Problems compiling on HPE NonStop

OK, I see a pretty garbled output from the configure run (which incidentally seem to trigger some elementary limitations of the sed command). I also see an error message, which I understand comes from a compiler which presumably is c99 compiant. The error message makes little sense. The

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

Vincent Lefevre writes: So, including if present should be sufficient, and this is what the above code does. That said, for C99 implementations, the #if tests would be useless, so that the above code is also designed for non-C99 implementations, which may have and with a behavior

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

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, where it would be incorrect on platforms with signed char (in particular, there is

Re: GMP Problem with % under C++

Miki Hermann writes: I am very well familiar with the % operator in %. Swell. In the document, whose link you sent me, and which I have read before, it is mentioned that Function: mpz_class operator% (mpz_class a, mpz_class d) This means, that the % operator in GMP overloads the

Re: possible miscompilation on macOS Catalina 10.15.6

Trevor Spiteri writes: I maintain Rust language bindings to GMP and got a bug report from a user on macOS Catalina 10.15.6.  I do not know if this issue is caused by the particular system setup of the user or if it is more general, so I'm listing what information I have in case it is

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

Andreas Buff writes: 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

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

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

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

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

Re: COFF_TYPE on x86_64

Jeremy Drake writes: I anchored the link to a particular line: My bad, I didn't see that. > Strangely, the fix for this was only applied to x86, and not x86_64. This > patch applies the fix to x86_64. > > What *fix* are you talking about?

Re: COFF_TYPE on x86_64

Jeremy Drake writes: On msys2's MINGW-packages, we recently hit an issue[1] which I eventually tracked down to the very issue documented in https://gmplib.org/repo/gmp-6.2/file/09e101b6f2ff/acinclude.m4#l2128 This is a link to a huge file. Many things are mentioned there. > > My

Re: Hardcoded value of GMP_LIMB_BITS impedes bi-arch builds

Jan Engelhardt writes: When ./configure has run, the GMP_LIMB_BITS define in gmp.h is hardcoded to 32 or 64, depending on arch. This makes it impossible to use that header file for a x86_64-driven build with gcc -m32. It is my (naive) view that declaring #define GMP_LIMB_BITS

Re: gmp{6.1.2, 6.2.0} config.guess detects wrong cputype/instruction sets

Bernd Recktor writes: coffeelake processes from intel are affected. Specifically in my case i9-9900KF and Pentium-Gold-G5400. The ./config.guess script recognizes kabylake-pc-linux-gnu or kabylakenoavx-pc-linux-gnu. Both compilers GCC-10.2 and GCC-8.3 recognize skylake using 'gcc -march

Re: commits not available on the mercurial page

Paul Zimmermann writes: 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? Unfortunately, it is a recurring problem which started years ago. I have not

Re: overflow in mpz type with a simple mpz_add_ui

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,y)', since usually ^^ only one or two limbs of

Re: overflow in mpz type with a simple mpz_add_ui

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 carry for a huge number is very unlikely to occur. No bug. You're (presumably

Re: Upstream patch to remove abort() that occur during memory overflow

Marco Bodrato writes: With ABI=64 I get: 16777216 ^ 768614336404564651 = 256 With ABI=32 I get: 16777216 ^ 178956971 = 256 Not a signal, nor an abort, simply an incorrect result :-) That's undesirable. I thought we cought overflows also in this difficult a^b case by (indirectly

Re: Issues with configuring gmp-6.2.0

"Soroush, Masoud" writes: Dear GMP Team, I have tried very hard to configure gmp-6.2.0 on my macOS Catalina (10.15.6). However, I get the following error message: "configure: error: could not find a working compiler, see config.log for details" and I have no idea how to proceed. I

Re: mpz_sizeinbase() bug

"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 0xC8601622

  1   2   3   >