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

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

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

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

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

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

"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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   3   >