Re: GMPlib tuneup building bug

No bug; you cannot use tuneup for a fat build. (It is not clear what a tuneup run would optimise for in fat builds.) -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bug

Re: Bug in GMP 6.1.0 + ARM

Karine Even-Mendoza writes: I tried building GMP 6.1.0 on ARMv8 machine (aarch64): GMP 6.1.0 is 9 years old now. Consider trying a current release. If the problem persists, please let us know. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gm

Re: A unary minus operator was applied to an unsigned type - conversion from 64 Bit to 32 Bit

Marc Glisse writes: (For C++, gcc has become much worse than MSVC, its recent optimization-based warnings have false positives all over the place and are almost impossible to work around) It is some sort of compiler hackerd game, inventing new warnings. These warning naturally become grad

Re: `make check` yields some failures on macOS

I am building gmp 6.3.0 (downloaded from the .tar.xz on the web site just now) on macOS (Sonoma, 14.6.1). I've attached tests/mpn/test-suite.log; please let me know if you need anything more. I build with just `./configure` (no options) and `make`. My bad. 6.3.0 is in fact the lat

Re: `make check` yields some failures on macOS

Chris Palmer writes: I am building gmp 6.3.0 (downloaded from the .tar.xz on the web site just now) on macOS (Sonoma, 14.6.1). I've attached tests/mpn/test-suite.log; please let me know if you need anything more. I build with just `./configure` (no options) and `make`. Any particular re

Re: mpf_set_str() seems buggy

Note that this user's example code contains a stack smasher. It is probably harmless, but please don't run it. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpf_set_str() seems buggy

It seems that the exponent being read in by mpf_dset_str() is wrong. I expect the new exponent (last line) to read -5 but it reads 4. The error is also seen in the line before that with gmp_printf() I find it fascinating that you think a GMP function which has been in use for over 30 year

Re: problems on MacOS 14.5 (23F79) (XCode 15.4)

> ... Clearly, GMP is not compiled correctly by newer Apple compilers. "Apple compilers" are actually based on LLVM clang. Indeed. Plus a bunch of bugs. Does GMP pass all checks with the latest clang on Linux? Of course. > Should GMP recognise and block Apple compilers? By this y

Re: problems on MacOS 14.5 (23F79) (XCode 15.4)

"Anna M. Bigatti" writes: Thanks, finally I tried, but I get the same outcome as before. Clearly, GMP is not compiled correctly by newer Apple compilers. Unfortunately, we don't have resources to debug Apple's compilers, and then consider to implement GMP workarounds. We do have Apple hardwa

Re: Multiple test failures when building for multilib system

Marc Glisse writes: t-do-exceptions-work-at-all-with-this-compiler means that your C++ compiler (or the C++ runtime) does not work, you should fix that before trying to compile any other software. Perhaps we should rename the test to t-do-exceptions-work-at-all-with-this-compiler---if-thi

Re: Multiple test failures when building for multilib system

Your message is garbled and hard to follow. GMP comes with documentation and therein there is a chapter on how to report GMP bugs. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/li

Re: Reduced number of allocated limbs after calling mpz_remove

Niels Möller writes: I don't have a strong opinion on how to fix this discrepancy between docs and implementation. But I feel rather strongly that mini-gmp shpuldn't make this promise, so code that rely on it will not work with mini-gmp. It is, in my opinion, not a bug in the code, nor i

Re: Fix for BMI2 detection for Intel CPUs in fat builds

Thanks, your proposed patch has been committed. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs

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 surpr

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++ (new

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 sur

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 A

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 gmp-bugs@gmplib.o

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 impossibl

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 GMPPREFIX=/a/path

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 if

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

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 write

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 pe

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 att

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 ge

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 the

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 callin

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 th

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 mo

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

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

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

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 diffe

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

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 don

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 ver

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 https://gmplib.or

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 mys

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' Is

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 ren

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 b

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 t

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

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 usually

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: root@freebsd12:/usr/ports/ma

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

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

When tuneup cannot measure things accurately, it bails out. No bug. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs

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

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 typ

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 override

Re: Segmentation fault with mpz_inp_raw on gcc45

Yes, but, should we really consider it only a temporary overflow? Does GMP support mpz numbers with a bit-lenght that overflows? GMP does not support such sizes. My fix avoided the overflow, allowing GMP overflow detection in the (re)allocation functions. It makes sense from a bookkeeping ov

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 (assu

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

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 ___ gmp-b

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 encrypt

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 quotes

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

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 be

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: https://gmplib.org/repo/gmp/rev

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 obser

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 syst

Re: Failing tests on new Synology DS1821+ server

Stephen Watt writes: * GCC version: gcc version 4.9.3 20150311 (prerelease) (crosstool-NG 1.20.0) That is a non-release of an awfully old compiler. I bet that's where the bug is. PASS: t-powm_ui FAIL: t-pow PASS: t-div_2exp FAIL: t-root GMP passes its own test suite unless the compi

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 us

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 th

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 som

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 g

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 a

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

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 discussion

Re: Arithmetic bug on ARM (STM 32 F4)

ttt = 3578942983869995381409279381784954092773488221200587338717407747084074518600438737913956360066709506626656635118978526559637095289631190671071178702312877654 but ttt should be 5247183143879283565064056089869553515440215252945038779070795247972433237341511292686962488915110675351673

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 t

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 function

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 di

  1   2   3   4   >