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: Likely GMP bug

Ciao, Il Mer, 30 Maggio 2018 10:20 am, Niels Möller ha scritto: > "Marco Bodrato" writes: > Thinking about micro optimizations... Consider >> count_trailing_zeros (c, ulimb); >> ulimb = (ulimb >> 1) >> c; > vs >> count_trailing_zeros (c, ulimb); >> ulimb >>= (c + 1);

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 effect is that in many cases (if U don't need reduction modulo V) > the trailing zeros of U are removed twice. But you may be right that it's important for performance to avoid a redundant count_trailing_zeros on u. It seems tricky to avoid that, without code

Re: Likely GMP bug

Ciao, Il Lun, 28 Maggio 2018 10:00 pm, Niels Möller ha scritto: > I'd suggest the below (complete file, I think that's more readable The code is clean. You removed all gotos... > The last part of the function requires vlimb odd, but tolerates > arbitrary u, including 0. ... the effect is that

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

t...@gmplib.org (Torbjörn Granlund) writes: > For now, I'd suggest to just rip out USE_ZEROTAB. I've pushed a change to do just that. For making the rest of the file clearer, I'd suggest the below (complete file, I think that's more readable than the diff). I've also ripped out the

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

t...@gmplib.org (Torbjörn Granlund) writes: > 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. Here we have a bug where assumptions made by the code are violated, with a pretty low

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

Ciao, Il Sab, 26 Maggio 2018 11:01 pm, Niels Möller ha scritto: > Is it possible to construct some examples with v a multiple of 641, and > input U such that ulimb = 2^31 after reduction? It was hard, but we got it: https://gmplib.org/repo/gmp/rev/1f8a8fefb5c2 The bug is triggered not only for

Re: Likely GMP bug

Ciao, Il Sab, 26 Maggio 2018 11:01 pm, Niels Möller ha scritto: > "Marco Bodrato" writes: > shift, that is interpreted as the odd value 2^32+1. This number has the > factorization 641 * 6700417, and if v happens to be a multiple of one of > And we have potential

Re: Likely GMP bug

"Marco Bodrato" writes: > Il Ven, 25 Maggio 2018 2:10 pm, Niels Möller ha scritto: >> That fails with undefined behavior if by chance t == 2^31, so that c == >> 31. >> >> I don't see how that can happen, though, since ulimb, vlimb < 2^31 >> through out the loop, and t =

Re: Likely GMP bug

On 05/25/2018 04:30 PM, Torbjörn Granlund wrote: Dennis Clarke writes: I have run all the testsuite, both with the assembly and without, on a pure 32-bit Debian machine and see no errors anywhere. Our machine runs gentoo with gcc 6.4.0. (Not sure if the exact

Re: Likely GMP bug

On 05/25/2018 08:10 AM, Niels Möller wrote: Dennis Clarke writes: gcd_1.c:187:13: runtime error: shift exponent 32 is too large for 32-bit type 'long unsigned int' FAIL t-cmp_ui (exit status: 1) And code is essentially count_trailing_zeros (c, t); ulimb

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

On 05/25/2018 04:45 AM, Torbjörn Granlund wrote: 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.) This seems to require --disable-assembly during configure .. ... starting

Re: Likely GMP bug

On 05/25/2018 04:45 AM, Torbjörn Granlund wrote: 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.) Not able to reproduce that failure with gmp-6.1.99-20180525 : configure:

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