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

Re: make check fails on samsung S8

Our apologies to the subscribers of this list for allowing a "confidential" message containing various threats. We will delete it from our archive. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org

Re: GMP test failure from arm gcc toolchain

Jeong YunWon writes: Source: https://developer.arm.com/-/media/Files/downloads/gnu-a/9.2-2019.12/srcrel/gcc-arm-src-snapshot-9.2-2019.12.tar.xz?revision=90d3618d-8136-44f2-aeef-42015dd0669a=en=00A97AA1ECF0B96A65F831AD719CA04053FBC61E

Re: bug report - 2 tests fail in make check

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

Re: Linking failure on aarch64

Claudia Pellegrino writes: I can confirm that this works flawlessly now. Thanks! Please note that I’ve put the fix into asm-defs.m4 instead of inlining it. See consolidated patch in the attachment. Perhaps we could use asm-defs.m4 more for this kind of things, but then we need to

Re: Linking failure on aarch64

FX writes: > Could you please try again with the attached patch, doing just a plain > .../configure && make && make check? I build with: ./configure --build=aarch64-apple-darwin20.0.0 otherwise config.guess returns arm-apple-darwin20.0.0 and it tries to build for 32-bit. With your

Re: Linking failure on aarch64

FX writes: If I don’t disable assembly, the compiler’s not happy with the asm code: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dcpi1_bdiv_q -O2 -pedantic -march=armv8-a -c dcpi1_bdiv_q.c -o dcpi1_bdiv_q.o >/dev/null 2>&1 tmp-bdiv_q_1.s:75:2:

Re: Linking failure on aarch64

Hans Åberg writes: So here it should be xcode-select --switch /Applications/Xcode-beta.app/Contents/Developer Sorry, I must have been unclear. I lacked installation instructions for how to get /Applications/Xcode-beta.app installed. My problem was not adding features to the beta

Re: Linking failure on aarch64

Hans Åberg writes: One must run 'xcode-select install' from the Terminal. I came that far (except it is --install) before giving up. But --install is not for installing a new Xcode, but for installing command line tools. What version? It does not say. The opened "dialogue" is not much of

Re: Linking failure on aarch64

Hans Åberg writes: > On 2 Jul 2020, at 00:49, Torbjörn Granlund wrote: > > (I actually attempted installing Apple's compiler bundle "Xcode" with > support for arm64, in order to work out some of these issues. > Unfortunately, Apple's documentaton was too

Re: Linking failure on aarch64

> ./configure --build=aarch64-apple-darwin MPN_PATH=generic Does it work better if you use the documented --disable-assembly instead? (disabling assembly seems like a strange thing to do...) For a new platform, disabling GMP's assembly actually makes some sense. Apple uses the archaic

Re: bug in longlong.h for aarch64 sub_ddmmss

t...@gmplib.org (Torbjörn Granlund) writes: A crude test generator: A slightly better variant. It expects an argument, either "add" or "sub", allowing it to test both add_ss and sub_ddmmss. This version should work fine on 32-bit systems without modification. T

Re: bug in longlong.h for aarch64 sub_ddmmss

Vincent Lefevre writes: Note: in the tests, it is important to test the macro on constants in order to test the "if" case. A crude test generator: #include #include #include "gmp-impl.h" void one (size_t ind, mp_limb_t m0, mp_limb_t s0) { printf ("void f%zu(mp_limb_t* r1p, mp_limb_t*

Re: bug in longlong.h for aarch64 sub_ddmmss

ni...@lysator.liu.se (Niels Möller) writes: And, which I guess is more relevant in the sub_ddmmss context, it also means that there's little need for separate instructions for adding and subtracting constants. The error we struck here for ARM and (one of the errors) for PPC was that we

Re: bug in longlong.h for aarch64 sub_ddmmss

Vincent Lefevre writes: On 2020-06-17 11:04:26 +0200, Niels Möller wrote: > t...@gmplib.org (Torbjörn Granlund) writes: > > > The two - signs ought to be ~, I think. Let me think a buit more about that. > > If I remember ARM conventions correctly, subtract wit

Re: bug in longlong.h for aarch64 sub_ddmmss

ni...@lysator.liu.se (Niels Möller) writes: t...@gmplib.org (Torbjörn Granlund) writes: > The two - signs ought to be ~, I think. Let me think a buit more about that. If I remember ARM conventions correctly, subtract with carry is defined as {cout, r} = a + ~b + cin Here

Re: bug in longlong.h for aarch64 sub_ddmmss

Vincent Lefevre writes: Note: in the tests, it is important to test the macro on constants in order to test the "if" case. Indeed, and one macro expansion per trivial function or else gcc might get the idea cse constants. This bug comes untimely for me. I consider a major purge along the

Re: bug in longlong.h for aarch64 sub_ddmmss

Vincent Lefevre writes: On 2020-06-16 13:40:14 +0200, Torbjorn Granlund wrote: > Vincent Lefevre writes: > > #define sub_ddmmss(sh, sl, ah, al, bh, bl) \ > do { \ > if (__builtin_constant_p (bl) &&

Re: bug in longlong.h for aarch64 sub_ddmmss

Vincent Lefevre writes: #define sub_ddmmss(sh, sl, ah, al, bh, bl) \ do { \ if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000) \ __asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3"

Re: building in 32-bit mode on Linux/s390x produces 64-bit mode binaries

Bruno Haible writes: On a Linux/s390x machine, a build of gmp-6.2.0, configured in the same way as dozens of other GNU packages to build 32-bit mode binaries, in fact produces 64-bit mode binaries. * The GMP version number, and if pre-packaged or patched then say so. 6.2.0,

Re: gmp 6.2.0 build failure in 32-bit mode on Linux/mips

Bruno Haible writes: No options, just './configure'. The environment variable CC is set to 'cc -xarch=v9', as recommended in https://gmplib.org/manual/ABI-and-ISA . No, the manual certainly does NOT recommended that. No, it doesn't say that I *must* set ABI. Er? I think the

Re: gmp 6.2.0 build failure in 32-bit mode on Linux/mips

Bruno Haible writes: In the section "Build Options" it mentions the possibility to set the CC variable. I've built many packages with this setting of CC. The section "ABI and ISA" has a subsection "MIPS under IRIX 6" but no section regarding Linux/MIPS. Please just read the first 10

Re: gmp 6.2.0 build failure in 32-bit mode on Linux/mips

Bruno Haible writes: $ ../configure CC="gcc -mabi=32" Please see the Installing GMP chapter in the fine manual. Usually, checking that one follows the installation instructions is a better first step than reporting one's build failure as a bug. ;-) -- Torbjörn Please encrypt, key id

Re: GMP 6.2 error

rodriguez-murias writes: When i make install : /usr/bin/mkdir: cannot create directory ‘/usr/local/share/info’: Permission denied The inability to write into system directories as a non-root user is not due to a problem with GMP. You might want to grab a book on Unix and read the first

Re: Problem by compiling GMP 6.0.2 ....

"Zhéxué M. Krawutschke [ Net.Admin & Sys.Admin ]" writes: Well, your information about „not clean“ is perfect, but I don‘t understand, why? Because I had say „make clean“, before I compile it again for my „armv7l“ - Node. Mixing files from incompatible builds cannot be made to work. (It

Re: Problem by compiling GMP 6.0.2 ....

"Zhéxué M. Krawutschke [ Net.Admin & Sys.Admin ]" writes: I want to compile GMP 6.0.2 on my ARMv7l - Node, because I need it for GNU-C 9.2.0 and 9.3.0 to compile. This Node is an 32bit - System on DEBIAN 10 - Plattform. We have never released any GMP 6.0.2. If I take the command:

Re: mpz_gcdext bug in mini-gmp

Syed Jafri writes: Thank you for your help, I used the set macros and it works perfectly. We appreciate that you follow up with this all-is-fine message! The initial point of confusion for me was that the exact same code worked in gmp but not mini-gmp. The two might interpret the fields

Re: mpz_gcdext bug in mini-gmp

ni...@lysator.liu.se (Niels Möller) writes: Never access internal fields of mpz_t directly. If for any reason (this example has no good reason, as far as I see) one needs to use a limb array as input, use mpz_roinit_n. I reacted about using Apple's infamous clang being used, but then I

Re: mpz_gcdext bug in mini-gmp

Syed Jafri writes: Thank you for the wonderful library, I have been using mini-gmp and I have run into a bug with the mpz_gcdext function. The full GMP version gives the correct output, while the mini-gmp version of the function fails at line 2911 of mini-gmp.c, at the code ```assert

Re: Having trouble building the library...

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 check >> make-check.log 2>&1 (see attached make-check.log) You forgot

Re: 6.2.0 always uses BMI1/2 instructions

GMP will include instructions for the host for which GMP is configured, These instructions come from asm file which GMP's configure selects, and from compiler generated code which results from compiler command line options which GMP passes. If you want GMP to run on older machines, configuring it

Re: efficiency bug in mpz_powm_ui?

Marc Glisse writes: I cannot see any recent snapshot at https://gmplib.org/download/snapshot/ , the most recent one appears to be from 17-Jan-2020. Ah, they are broken in the sense that they don't exist. :-) (It was a boched disabling of ftp snapshot downloads; the sync to the web

Re: efficiency bug in mpz_powm_ui?

paul zimmermann writes: PS: while trying the above change, I noticed the daily snapshots are broken since January 18... Would you mind telling us what is "broken"? -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list

Re: [Possible bug in __gmpz_powm]

Gabriel Sturzu writes: Version: GNU MP 6.0.0 That is an obsolete GMP release. Please try a current release, preferably 6.2.0. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org

Re: Build impossible

Daniel Birkmaier writes: I try to build the gmblib by using ./configure and make. But each time the only message I get is, that I have no authorization to do this. How can I solve this problem? Because also setting of file/directory access rights does not help. I assume you're new to

Re: GMP issue with mpz_nextprime()

simondev1 writes: Found non-prime with method mpz_nextprime: GMP Version 4.31(probably) We have never released any 4.31. (There was a 4.3.1 made 11 years ago, but the bug you report was fixed there already.) p = 2028576353201; mpz_nextprime(p, p); // this will find 2028576353203

Re: setting CPU_TYPE when cross-compiling from Linux to Windows

Claude Heiland-Allen writes: Notice it uses compiler `gcc` instead of `x86_64-w64-mingw32-gcc`, which leads to a build for Linux, not Windows. Well, you explicitly tell it to use "gcc" which might be why it uses "gcc". Thanks for any advice, Advice: 1. Please read the GMP

Re: GMP and Macos Catalina

Hans Åberg writes: > On 14 Dec 2019, at 23:49, Torbjörn Granlund wrote: > > Many people have reported problems with GMP on Macos Catalina. > > The problem now seems to have been fixed with the Xcode 11.3 release. At least the tests pass: One error with clang 9.

GMP and Macos Catalina

Many people have reported problems with GMP on Macos Catalina. The problem now seems to have been fixed with the Xcode 11.3 release. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org

Re: Compiling for ARMv8-A Using GCC 7.2.0 - Assertion error in gen-fac

ni...@lysator.liu.se (Niels Möller) writes: > I was able to narrow down the cause. In GC 7.2.0 the GMP_LLIMB_MASK is wrong: > > =GCC 4.8.5= > GMP_LIMB_BITS=64 > GMP_LLIMB_MASK=4294967295=0x > > =GCC 7.2.0= > GMP_LIMB_BITS=64 > GMP_LLIMB_MASK=1=0x0001 > > From

Re: Inline assembly needs "cc" clobber to avoid miscompilation

I used a few more hours of my time on this. My conclusion is that "cc" clobber is completely ignored by clang. In fact, clang happily schedules carry-set and carry-use around inline asm with "cc". This is another example that it's just a waste time trying to make GMP compile reliably with

Re: Inline assembly needs "cc" clobber to avoid miscompilation

I agree that adding a "cc" does not hurt, even if gcc does not need it for all platforms. The absence of it for ppc is for exactly that reason; gcc does not need it for this platform. I am testing a more complete patch for this omission. -- Torbjörn Please encrypt, key id 0xC8601622

Re: macOS Catalina: FAIL: t-powm

Marc Glisse writes: It seems to have code for "native" variant, although possibly noone uses it. Does --enable-fat not work on Mac? It works. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org

Re: macOS Catalina: FAIL: t-powm

Apple has released a new version of Xcode. It is said to fix some issue with UITextView, and as the update size is 8 GiB UITextView must be a very large function. But hopefully they also managed to fix the C compiler to miscompile many of our functions. -- Torbjörn Please encrypt, key id

Re: macOS Catalina: FAIL: t-powm

Jack Howarth writes: Torbjörn, Are you just using... ./configure Yes. or are you explicitly passing -fstack-check to clang on CFLAGS and CXXFLAGS? I did notice one extra oddity to this bug. When the default stack checking in Xcode 11 clang is used, the t-powm test case

Re: macOS Catalina: FAIL: t-powm

Jack Howarth writes: Torbjörn, Are you using the clang from Xcode 11? Yes, of course. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang

Hans Åberg writes: > On 20 Oct 2019, at 22:14, Torbjörn Granlund wrote: > > Believe it or not, but the GMP devs are pretty good at computer > arithmetic. How about memory allocations? — There is info here, suggesting uninitialized memory access in the test su

Re: macOS Catalina: FAIL: t-powm

Jack Howarth writes: FYI, I reported this issue to Apple via radar and their response was... Engineering has provided the following information regarding this issue: It sounds like gmp has a memory corruption issue which -fstack-check has uncovered. We suggest filing a bug with the

Re: macOS Catalina: FAIL: t-powm

Cedric Berger writes: This is a fresh XCode 11.2 (11B52) and Catalina 10.15.1 (19B88) What could I do? Many people are reporting that Catalina's version of clang miscompiles GMP. We don't have any workaround. We generally don't work around compiler bugs. -- Torbjörn Please encrypt, key

Re: Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang

Hans Åberg writes: Strictly, it is for signed overflows one cannot assume modulo 2^n, n = number of bits. For the unsigned integer types it is required, though. Believe it or not, but the GMP devs are pretty good at computer arithmetic. -- Torbjörn Please encrypt, key id 0xC8601622

Re: Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang

Hans Åberg writes: A common programming error is assuming that signed integer types are two’s complement, because even though all current CPUs are that, overflows are undefined in C/C++, and an optimizer can take advantage of that. One example from [1]: checking overflows with x > x + 1

Re: Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang

Hans Åberg writes: I have compiled gmp-6.1.2 on MacOS 10.15 using the inhouse Apple clang and the MacPorts gcc9 and clang9, with ‘make check’. All tests passed on gcc9, but the two clang had one error each. Several people seem to have trouble with using clang. When clang first appeared,

Re: possible bug

David Joyner writes: Errors are below. Just reporting this as requested. Note that there is also a link displayed which points to the page on how to create meaningful GMP bug reports. Please read it. -- Torbjörn Please encrypt, key id 0xC8601622

Re: bug in gmp_fprintf still in next release?

ni...@lysator.liu.se (Niels Möller) writes: Another limit that was pointed out to me the other day is mpz_out_raw, with a 32-bit length field (matching the current mpz_t limit, though). IIRC, the size field counts bytes for these functions. The size in mpz counts limbs. -- Torbjörn

Re: segmentation fault in t-toom53 test with MAC OS X Catalina (Clang 11.0)

Juergen Reuter writes: Please let me know any further information you need. This is almost surely a compiler bug. We have encountered countless of bugs in clang since it showed up. We have up-to-date apple systems for running GMP tests, but your clang seems to be newer than what we have. I

Re: bug in gmp_fprintf still in next release?

paul zimmermann writes: four years ago [1] I reported an issue with gmp_fprintf in GMP 6.1.0, which cannot print correcly a number of 8589934589 bits (less than 2^33). I just checked with today's snapshot: the issue is still there. Yikes! Will the next GMP release be still limited to

Re: error on mpz_inits and mpz_clears

Rabindra Moirangthem writes: I got the error while compiling and I compiled using the command: gcc programname.c -lgmp The version of the gmp I am using is gmp-6.1.2 You need to ask for help locally, perhaps from a sysadmin, somebody who knows about linking and library paths work at your

Re: error on mpz_inits and mpz_clears

ni...@lysator.liu.se (Niels Möller) writes: Rabindra Moirangthem writes: > > I have installed the gmp library on a centos system. When I compiled my c > file, it gives errors only when I am using mpz_inits and mpz_clears in my > program. Other functions compiled successfully. > The

Re: Latest commit introduces undefined behavior in hgcd2.c

ni...@lysator.liu.se (Niels Möller) writes: Is it reasonable to change it to #define LIMB_SHIFT_MASK (GMP_LIMB_BITS - 1) dh = (dh << dcnt) + (-(dcnt > 0) & (dl >> (LIMB_SHIFT_MASK & - dcnt))); Or simply: dh = (dh << dcnt) + (dl >> (GMP_LIMB_BITS - 1 - dcnt) >> 1); -- Torbjörn

Re: Latest commit introduces undefined behavior in hgcd2.c

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 /src/libgmp/mpn/hgcd2.c:223:42 #1 0x769684 in __gmpn_hgcd2

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

Vincent Lefevre writes: $ ./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: failure to detect format of `double' on MS-Windows

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

Re: coredump

I cannot repro a segfault, but then I might not be using the same GMP release as you. But your test case does indeed show a bug with floating point input in bases which are a power of two and have many leading zeros. Here is a patch: https://gmplib.org/repo/gmp/raw-rev/0fe70584021b Please

Re: Fix 1 missing dependency in Makefile.in

Vemake Vemake writes: Hi, I've fixed 1 missing dependency reported. This issue can cause incorrect results when gmp is incrementally built. Detailed speaking, any changes in the target "libtool" will not cause "dummy.lo" to be rebuilt, which is incorrect. I've tested it on my computer,

Re: mpz_set_si loses long long value on Windows

Vincent Lefevre writes: 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. :) Yikes! I wasn't aware of

Re: mpz_set_si loses long long value on Windows

Vincent Lefevre writes: GNU MPFR has mpfr_set_sj and mpfr_set_uj (when intmax_t is available) in addition to mpfr_set_si and mpfr_set_ui. Perhaps it could be nice for GMP to also have mpz_set_sj and mpz_set_uj in addition to mpz_set_si and mpz_set_ui. I have a probably incomplete patch

Re: GMP test fails with -flto

Marc Glisse writes: Without #include , some compilers reject it. Also, the string should be "%d %f" (or replace '+' with ',' in the arguments). Thanks, fixed! -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list

Re: GMP test fails with -flto

Richard Biener writes: So yes, building a shared object with the data exported is probably more future-proof ;) Indded. But I don't know how to do that portably. Let the perfect not be the enemy of the good here. Don't tease Vincent like that! :-) -- Torbjörn Please encrypt, key id

Re: GMP test fails with -flto

Vincent Lefevre writes: C99 says: "An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract

Re: GMP test fails with -flto

Richard Biener writes: Yes, this should work. It probably has a slightly higher chance of mismatching the start/end patterns elsewhere in the file, but well... Thanks for checking my proposed patch! Yes, I realise that we could get unlucky now, something which really shouldn't happen with

Re: GMP test fails with -flto

Richard Biener writes: On Mon, Jul 1, 2019 at 11:13 PM Torbjörn Granlund wrote: > > Vincent Lefevre writes: > > Yes, with LTO, the object file does not contain the structure as is. > Thus the detection from "od -b conftest.$OBJEXT" does not work. &

Re: GMP test fails with -flto

Vincent Lefevre writes: Yes, with LTO, the object file does not contain the structure as is. Thus the detection from "od -b conftest.$OBJEXT" does not work. That could be solved by generating a final executable, right? -- Torbjörn Please encrypt, key id 0xC8601622

Re: GMP test fails with -flto

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 that GCC was used with LTO), and in this case, try again with "-fno-lto" as the patch was doing. That

Re: error during "make tune"

"K. I. Yusaku" writes: The "configure" and "make" finished without fail. But "make tune" stopped with the attached log file. The config.log is also attached for system information. Please give me some advice about this error. Your (huge) message does not seem to contain any "tune"

Re: EXC_I386_INVOP in GMP 6.1.2 on OS X

-> 0x1000d04f5 <+213>: mulxq (%rsi), %r9, %rax You have configured your GMP for a too new CPU. The mulx instruction is available in Intel Broadwell, Skylake and newer, and in Amd Excavator, Zen. Presumably, you have configured GMP on a new system and then run it on an older system. --

Re: gmp-6.1.2 Bug Report (gmp_fprintf(), "implicit declaration of function" warning)

"mlg ." writes: Long story short, with gcc, the function/macro "gmp_fprintf()" gives an"implicit declaration of function" warning. Please see the attached file for the complete report. Please see the GMP manual, specifically see this page:

Re: gmp-6.1.2, acinclude.m4, configure

"Ralf Gerhauser" writes: checking whether make supports nested variables... yes checking whether to enable maintainer-specific portions of Makefiles... no checking ABI=64 checking compiler gcc -O2 -I/home/rage/Development/OpenWrt/openwrt/staging_dir/host/include

Re: Problems with mpfr_set_str() and decimal numbers

You might want to let the MPFR developers know about this. GMP != MPFR. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs

Re: gmp-6.1.2 test suite fails with core dump

Your two reports seem to refer to the same issue. I cannot make out much relevant information from either report. Both your reports quite this text: For bug reporting instructions, please see: . If you want us to help you reslve your issue, please

Re: [PATCH] missing va_end() in some IO functions (gmp 6.1.2)

Jakub Martisko writes: I believe there are some missing va_end() calls in some of the IO functions of GMP 6.1.2. See attached patch for details. Are you sure that's how stdarg works? I see no problems with GMP's current code. I believe your patch is incorrect in several ways. --

Re: Stray backslashes in html docs

Trevor Spiteri writes: In the html documentation, I found a few backslashes that shouldn't be there: https://gmplib.org/manual/FFT-Multiplication.html#FFT-Multiplication mp\_bits\_per\_limb https://gmplib.org/manual/Low_002dlevel-Functions.html#index-mpn_005fsec_005fpowm

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

Jeffrey Walton writes: Here's what I witness on a BananaPi and a couple of other boards. Can you provide info on the ARM boards you are using? I have about 8 of them for testing, and I may be able to duplicate your [successful] result. Marco and others have told you to read the GMP

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

The assert that Jeffrey has hit is in sec_powm.c, ASSERT_ALWAYS (enb >= windowsize); As far as I can see, "enb" is the input argument to the win_size function, and "windowsize" is the return value. I'm waiting for more information, since it works fine in my build. Possible

[ADMIN] Foul language and swearwords

We have rejected a couple of messages sent to this list on a recent subject because they contained profanity. Keeping a reasonably civil tone is required on these mailing list. ___ gmp-bugs mailing list gmp-bugs@gmplib.org

Re: tmp-lshift.s:106: Error: selected processor does not support ARM mode `vdup.32 d6, r3'

ni...@lysator.liu.se (Niels Möller) writes: For the specific case of neon, one alternative might be to explicitly add the pseudo-op .fpu neon in all neon asm files, which should make them less dependent on flags passed on the compiler command line. It looks like the definition of

Re: Mercurial: GMP repo clone failure

Markku Pulkkinen writes: Tried to clone GMP repo but it failed. The command and response was: hg clone --debug -v https://gmplib.org/repo/gmp/ using https://gmplib.org/repo/gmp/ sending capabilities command destination directory: gmp query 1; heads sending batch command

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

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

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

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

Re: GMP tuneup crashes

Failures with the tuneup program not getting accurate timing is unfortunately normal. For some reason, GCD measurements are particular fragile. Try mesuring on an idle system, it should work better. -- Torbjörn Please encrypt, key id 0xC8601622 ___

Re: Likely GMP bug

Vincent Lefevre writes: But shouldn't it be the goal of the compiler to generate the fastest code for the target? Yeah, that's a good idea. :-) This might require more analysis than what we can expect from the compiler, as (x >> 1) >> c is not the same thing as x >> (1+c) (at least not if

Re: configure failure for --host=armv7-apple-darwin with assembly

Taner Sener writes: checking how to define a 32-bit word... configure: error: cannot determine how to define a 32-bit word Well, how do you define a 32-bit word in this assembly variant? (You might want to compile something like "int foo = 0xdeadbeef;" into assembly and check the output to

Re: Likely GMP bug

ni...@lysator.liu.se (Niels Möller) writes: But you may be right that it's important for performance to avoid a redundant count_trailing_zeros on u. It is slow on several machines, but it has become more common to provide good leading/trailing bit count for newer microarchs. It seems

Re: Likely GMP bug

"Marco Bodrato" writes: The test suite now checks for this bug, for every run with --disable-assembly. So yes, you can remove the failure file, it will be recreated if some asm implementation is affected :-) I beleieve all x86 asm for gcd_1 was whacked tonight (we only have two

Re: Likely GMP bug

"Marco Bodrato" writes: The test suite now checks for this bug, for every run with --disable-assembly. So yes, you can remove the failure file, it will be recreated if some asm implementation is affected :-) Ehum? With --disable-assembly asm code tends to be

Re: Likely GMP bug

"Marco Bodrato" writes: It was hard, but we got it: https://gmplib.org/repo/gmp/rev/1f8a8fefb5c2 Thanks! It really worries me that our crazy broad testing did not catch this until now. This makes me much less confident about GMP's correctness, actually. I

Re: Likely GMP bug

ni...@lysator.liu.se (Niels Möller) writes: And code is essentially count_trailing_zeros (c, t); ulimb >>= (c + 1); The intention is to shift right to get rid of both trailing zero bits, and the redundant least significant one bit. That fails with undefined behavior if

Likely GMP bug

If somebody could take a look at https://gmplib.org/devel/tm/gmp/check/failure/ivygentoo32.gmplib.org-dyn-noasm-ubsan:32.txt I would appreciate it. (I am traveling.) -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list

Re: gmp-6.1.2: configure MPN_PATH="generic" fails on 64 bit

Karsten Scheibler writes: Compiling gmp-6.1.2 on Ubuntu 16.04.4 (x86_64) with a ./configure works without problems. But when trying to disable the assembly routines using: ./configure MPN_PATH="generic" configure fails with the following error:

Re: Configure unable to recognize mipsisa64r2el triplets

Jiaxun Yang writes: > I've never seen "mipsisa64r2el" before. Yes, it's rare. However, according to config.sub from GCC [1], it's not illegal. Good! We woudn't want to be gaoled for a CPU moniker! I ran it on a LFS rootfs provided by Loongson (A Chinese

<    1   2   3   >