Re: Configure unable to recognize mipsisa64r2el triplets

Jiaxun Yang writes: I'm trying to cross-compile GMP for a MIPS64r2 target. The triple is mipsisa64r2el-unknow-linux-gnu witch get from config.guess. And the expected ABI should be ABI=64. However, the ./configure told me that the only choice of ABI is o32. I've

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

paul zimmermann writes: Dear Arnold, the "duplicate symbol ___gmpz_abs" seems to be a frequent issue on Mac OS: http://mail-index.netbsd.org/pkgsrc-users/2008/11/20/msg008688.html https://groups.google.com/forum/#!topic/sage-devel/LVASCTPZnXw

Re: parallel make bug in tune/ directory

Vincent Lefevre writes: The user always has the right to use the -j option if he wants to. Thanks for clarifying that, Vincent! Unfortunately, the result will be a build error in the tune subdir. But I assume the GMP developers have The Right to release GMP without

Re: parallel make bug in tune/ directory

Win C writes: This is a bug of the current mercurial repo in the tune/ directory: When I run `make -j6 allprogs` for the first time, an error was emitted: libtool: link: (cd .libs/libspeed.lax/libtests.a && ar x

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

Dennis Clarke writes: As a minor annoyance it does cause gcc ( recent versions 7.x ) to fail. Oddly enough ye Oracle Studio 12.6 cc running in strict c99 mode is fine and happy with everything. That is a new experience for me. However the performance on sparc is

Re: Configure fails on 32-bit platform

Vincent Lefevre writes: So, if I understand correctly, this means that if the user chooses to set -m32 in CFLAGS, he might have to try different ABI values before finding one that works (because -m32 does not necessarily imply 32-bit limbs). This is not nice. It is

Re: Configure fails on 32-bit platform

Vincent Lefevre writes: As written above, this is for C compilers. But GMP also has assembler code. So, you need to provide an option that will affect the assembler code. This is what ABI is for. That said, perhaps GMP might be improved to detect the ABI by a

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

Dennis Clarke writes: repl-vsnprintf.c:396:0: error: ISO C forbids an empty translation unit Our nightly builds get a few of those too, as warnings. I've decided I can live with those as no platform seems to actually dislike the resulting object files. -- Torbjörn

Re: GMP 6.1.2: 32-bit ARM build failure on 64-bit hardware with CFLAGS=-g

> What CFLAGS does GMP use if you don't override its detection? $ grep ^CFLAGS Makefile CFLAGS = -O2 -pedantic -fomit-frame-pointer -march=armv8-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a53 Is it up to me to include all that in the CFLAGS that I specify? If you override

Re: Incorrect detection of MMX support in Intel Family 5 CPU's

Thanks for tracing your crashes to GMP and thanks for reporting it to us. You demonstrate a fragility in our CPU detection. Please try these patches: https://gmplib.org/repo/gmp/raw-rev/cd5e58236267 https://gmplib.org/repo/gmp/raw-rev/4117847f9e8b If you can make both a plain build and one

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

(Related, I wonder what the effect would be of redefining umul_ppmm as C expressions involving __uint128_t on compilers that support that). We do that already for some CPUs, but this has proven to be somewhat fragile, and in unexpected cases lead to libgcc calls. We brave to do

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

ni...@lysator.liu.se (Niels Möller) writes: Using inline asm instead has the drawback that it leaves a little less opportunity for the compiler to schedule this instructions optimally. No idea if that matters in practice. Since it seems we don't really need count_*_zeros to support zero

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

ni...@lysator.liu.se (Niels Möller) writes: t...@gmplib.org (Torbjörn Granlund) writes: > The idea with that was to allow some usages that want to pass 0 to avoid > a condition. Isn't that used? The idea makes sense, but I couldn't find any such use. I was thinking that a

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

ni...@lysator.liu.se (Niels Möller) writes: And below, a patch to delete all mention of COUNT_LEADING_ZEROS_0, except for tune/many.pl, which I'm not familiar with. What do you think? The idea with that was to allow some usages that want to pass 0 to avoid a condition. Isn't that used?

Re: GMP doesn't honor march flag

Paul Jähne writes: I encountered a problem with GMP when using the march flag. I build GMP 6.1.1 with march=corei7 or march=westmere with GCC 5.4.0 on a server with a Haswell processor (E5-2630 v3). When executing curl (version 7.47.0 on Ubuntu 16.04) which uses

Re: register corruption under MS Windows / x86-64

Vincent Lefevre writes: One of those who saw the bug with MPFR 4 RC1 + GMP dev said that everything seems fine with the latest GMP dev: https://sympa.inria.fr/sympa/arc/mpfr/2017-12/msg00067.html Thanks. -- Torbjörn Please encrypt, key id 0xC8601622

Re: register corruption under MS Windows / x86-64

It is a flaw in our testing setup that this calling convention breach is not caught by the automated testing. I will fix both bugs. :-) I have now pushed a fix for the mainline repo. Testing would be appreciated! Improving test suite calling conventions checks (through

Re: register corruption under MS Windows / x86-64

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

Re: GMP build issues on Solaris 10 UltraSPARC

Sad Clouds writes: https://gmplib.org/list-archives/gmp-commit/2013-May/001723.html + [ultrasparct[12]]) + gcc_cflags_cpu="-mcpu=niagara -mcpu=v9" + gcc_32_cflags_asm="-Wa,-Av8plusc -Wa,-xarch=v8plusc" +

Re: [PATCH] Inline assembly division needs __volatile__

Ximin Luo writes: Any chance my patch could be tested and merged? I tried applying it, but it fails for the current head. Manual merging is required. (It applies flawlessly to GMP 6.1, though.) If you could modify your patch to apply to the GMP head, then that would

Re: issues on gcc202

paul zimmermann writes: However I had to define INTERPRETER= in test-driver. That requirement should be gone now. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org

Re: issues on gcc202

paul zimmermann writes: However I had to define INTERPRETER= in test-driver. Yep, that's an undocumented feature of the snapshots. :-) We use that for our nightly builds for running valgrind and various emulators. Also the "Testsuite summary" is still not very

Re: issues on gcc202

I find several issues on gcc202.fsffrance.org: 1) gmp-6.1.2 configured with --disable-shared and gcc 7.2.0: libgmp.a contains an undefined symbol __gmpn_addlsh1_n_ip1: zimmerma@gcc202:/tmp/gmp-6.1.2$ cat e.c #include "gmp.h" int main() { mpz_t x;

Re: assembly files on Solaris SPARC can only be processed with gcc

Dennis Clarke writes: somedays I don't include details and I get railed at .. other days I do and I get railed at .. life goes on. Did Niels rail you? I think that's a quite unfair assessment. He's pointing out a central issue here, your snub is the attitude

Re: Jacobi Symbol

paul zimmermann writes: 15.3.5 Jacobi Symbol [This section is obsolete. The current Jacobi code actually uses a very efficient algorithm.] I just checked the latest daily snapshot, it is still the same. When will

Re: reporting bug of Segmentation fault which occurs while make check.(completed one )

Jason Yu writes: I encouter Segementation fault while I run "make check"(configure had run well).: Any of the about 20 less obsolete GMP releases should be fine. ___ gmp-bugs mailing list gmp-bugs@gmplib.org

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

Vincent Lefevre writes: > The fbsd developers' GNU/Linux envy is projected at GPL hate which in > turn badly hurts their own system. This is not fair. The current behavior is the same as various Linux systems, including Debian until Jessie. I was referring to that

Re: fat_init violates host ABI on Win64

Nicolas Hake writes: the Windows x64 ABI requires callers to allocate a 32 byte "parameter area" before calling into a function, which the callee is allowed to use as it pleases[1]. fat_init does not do this before calling __gmpn_cpuvec_init, thus violating the ABI.

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

ni...@lysator.liu.se (Niels Möller) writes: #if defined(__WIN32__) && define (__GNUC__) #define __USE_MINGW_ANSI_STDIO 1 #endif I'd guess there are plenty of windows programs that depend on the non-standard behavior. So bug-compatibility makes some sense. But we don't want it.

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

Claude Heiland-Allen writes: > Could the macro __USE_MINGW_ANSI_STDIO be relevant? Yes, perfect! I did CPPFLAGS=-D__USE_MINGW_ANSI_STDIO ./configure --host=x86_64-w64-mingw32 --prefix=$HOME/win64 CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make -j 8

Re: Crash when attempting to call mpz_invert in a program that uses mpq_class and mpz_class

Álvaro Begué writes: mpz_class fraction_mod_m(mpq_class x, mpz_class m) { mpz_t inverse; mpz_class den = x.get_den(); mpz_invert(inverse, den.get_mpz_t(), m.get_mpz_t()); // Crashes return mpz_class(inverse); } No GMP bug. Please re-read

Re: BUG REPORT

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

Re: mpf_get_d_2exp ignores sign of input

paul zimmermann writes: I disagree. The fine manual says "D * 2^EXP is the (truncated) OP value", which is wrong if say OP = -0.5. And why bother write 0.5<=abs(D)<1 instead of 0.5<=D<1 if D is always >= 0? Right. I am testing a fix, and am also rewriting

Re: mpf_get_d_2exp ignores sign of input

Claude Heiland-Allen writes: mpf_get_d_2exp() always returns a non-negative value, even for negative input. I think this is a bug. The function works as documented. No bug. -- Torbjörn Please encrypt, key id 0xC8601622

Re: Problem with gmp_randinit_set

Pedro Gimeno writes: With something like the attached? Perhaps. In fact I don't know why it isn't doing it now. Can that structure possibly come from disk or some other place that makes the pointers invalid? I guess not. That patch makes a lot of sense... I'll

Re: Problem with gmp_randinit_set

Pedro Gimeno writes: I chose xxtea for being simple and small (as can be seen in the patch) and for having variable block size, so I could encrypt just 1 block of 19936 bits, eliminating the need to choose a suitable enciphering mode. For ciphers with smaller

Re: Problem with gmp_randinit_set

Pedro Gimeno writes: Ah, yes, that was a problem that needed to be avoided. Thanks for looking into this. One possible fix would be to resurrect my patch for a different seeding routine, which was based on the xxtea encryption algorithm. That one is faster

Re: Problem with gmp_randinit_set

Pedro Gimeno <gmpdisc...@formauri.es> writes: Torbjörn Granlund wrote, On 2017-02-14 01:41: > One can change Mersenne_Twister_Generator_Noseed to > Mersenne_Twister_Generator to fix this (and move __gmp_randiset_mt to > randmts.c as mandated by Mersenne_Twister_Ge

Re: Problem with gmp_randinit_set

gmp_randinit_set(b, a); gmp_randseed_ui(b, 123456); /* crashes */ AFAICT this is a gmp bug, but I don't rule out the possibility that it's a user bug. This looks like a GMP bug. I never looked properly through the GMP PRNG code, and looking at it now I don't immediately

Re: Inconsistency in version number.

victor.su...@upc.edu writes: Hello, I have installed GMP 6.1.2 from source using default options for configure. As expected, in 'gmp.h' I find #define __GNU_MP_VERSION    6 #define __GNU_MP_VERSION_MINOR  1 #define __GNU_MP_VERSION_PATCHLEVEL 2 However, the

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

Mike Frysinger writes: OK, i've moved this to MPFR's tracker: https://gforge.inria.fr/tracker/index.php?func=detail=21053_id=136=619 Thanks! We're probably going to create many more problems for extension libs for GMP 7. It will be the first release to support

Re: [PATCH] tune: fix spurious clock_gettime reference

Mike Frysinger writes: ../gmp-mparam.h:1:1: error: unknown type name 'clock_gettime' clock_gettime is 1.000ns accurate This is because the tune source has one printf that is not protected by the verbose flag leading it to be written to the output. Patch applied,

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

Mike Frysinger writes: building gmp-6.1.0 & gmp-6.1.1 like so: ./configure \ --build=s390-ibm-linux-gnu --host=s390-ibm-linux-gnu \ --enable-shared --disable-assembly --enable-cxx --disable-static triggers this warning: udiv_w_sdiv.c: In function

Re: mpz reuse test takes too much time

Vincent Lefevre writes: But there may have been a temporary problem, as I now get: ./reuse 27.56s user 0.15s system 100% cpu 27.698 total That's more in the expected range. Amd bulldozers are not GMP speed demons, with their 1/4 mul throughput, but they are not

Re: Manual for mpz_powm, mpz_powm_ui

[Please follow up to gmp-discuss as this is not a bug report.] -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Invalid read in mpz_sub

Vincent Lefevre writes: I propose the attached patch. I think that 3.4 Variable Conventions is the best section for such information. So, I've moved a part of the paragraph in 3.5 Parameter Conventions to a new paragraph in 3.4 with more information, and I've

Re: Invalid read in mpz_sub

Vincent Lefevre writes: However, the GMP manual says: [...] Here are some examples of how to declare such integers: mpz_t sum; struct foo { mpz_t x, y; }; mpz_t vec[20]; and doesn't forbid to copy the structure, for instance. I think

Re: [gmp-bugs] Build feedback for gmp-6.1.0

Marc Glisse writes: >/usr/bin/gcc -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_lshift \ > -I/usr/uumath/include -I/usr/uumath/include -Wa,--noexecstack tmp-lshift.s -fPIC \ > -DPIC -o .libs/lshift.o Do you have CFLAGS set or

Re: FAILED t-scan test of the arm-2009q3-67-arm-none-linux-gnueabi gmp-stable.

I don't know what gmp-stable means. You claim architecture arm-2009q3-67-arm-none-linux-gnueabi first and x86_64 later. Which is it? (The former looks very strange.) Please read https://gmplib.org/manual/Reporting-Bugs.html and write a self-contained and complete report. -- Torbjörn Please

<    1   2   3