ni...@lysator.liu.se (Niels Möller) writes:
I'd suggest doing the below (also undoing Marco's previous fix).
To fix the actual failure, one would also need to edit the two
gmp-mparam.h files which set DIV_QR_1_NORM_THRESHOLD to zero.
I checked that in yesterday. But I'm a bit confused by the
ni...@lysator.liu.se (Niels Möller) writes:
I'd suggest doing the below (also undoing Marco's previous fix).
To fix the actual failure, one would also need to edit the two
gmp-mparam.h files which set DIV_QR_1_NORM_THRESHOLD to zero.
I checked that in yesterday. But I'm a bit
Ciao
Il Lun, 17 Febbraio 2014 9:12 am, Niels ha scritto:
(on tuning of DIV_QR_1_UNNORM_THRESHOLD)
Me too, I checked how tuneup interacts with the current div_qr_1 code. You
are right, it seems the current code is OK. Good!
Regards,
m
--
http://bodrato.it/
bodr...@mail.dm.unipi.it writes:
Me too, I checked how tuneup interacts with the current div_qr_1 code. You
are right, it seems the current code is OK. Good!
If you have figured out *why* it works, I'd like to hear...
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid
ni...@lysator.liu.se (Niels Möller) writes:
So to avoid zeros, we'd just need to clear the param.min_is_always flag
when tuning, right?
I'd suggest doing the below (also undoing Marco's previous fix).
To fix the actual failure, one would also need to edit the two
gmp-mparam.h files which set
bodr...@mail.dm.unipi.it writes:
Code says:
if (d GMP_NUMB_HIGHBIT)
{ /* Normalized case */
uh = up[--n]; /* Here n goes to 0 */
...
if (BELOW_THRESHOLD (n, DIV_QR_1_NORM_THRESHOLD))
{
while (n 0)
udiv_qrnnd (...);
Torbjorn Granlund t...@gmplib.org writes:
Also, keeping DIV_QR_1_UNNORM_THRESHOLD = 1 surely does the job, but it
puts another test it the critical path. Perhaps that's unavoidable, I
haven't checked.
I'm not entirely sure I follow you, but I guess the alternative is
something like
if (nn
Ciao,
Il Dom, 16 Febbraio 2014 5:45 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
I disallowed zero DIV_QR_1_NORM_THRESHOLD with this patch:
Since we control these thresholds at the source level, if it is
desirable to keep DIV_QR_1_UNNORM_THRESHOLD = 1, that should be
Torbjorn Granlund t...@gmplib.org writes:
Since we control these thresholds at the source level, if it is
desirable to keep DIV_QR_1_UNNORM_THRESHOLD = 1, that should be done in
tuneup.
It uses DIV_1_PARAMS settings, which includes param.min_size = 2. So it
should get zero only to indicate
We currently have many spurious failures flagged in red at
https://gmplib.org/devel/tm-date.html, mainly due to hardware errors
with the system `biko'.
But the `hark' failure looks real:
hark$ cd /var/tmp/gmp-obj/hark-stat-64
hark$ GMP_CHECK_RANDOMIZE=3526906869 tests/mpn/t-div
Torbjorn Granlund t...@gmplib.org writes:
I suspect this is a new bug, and that the error is in the test code. It
seems to happen for many seeds, around one in 25, for s390. If the bug
were old it'd had happened before.
Hmm. Look like it's the returning of the high limb via the separate *qp
ni...@lysator.liu.se (Niels Möller) writes:
Hmm. Look like it's the returning of the high limb via the separate *qp
which is broken? And there's no (non-inline) assembly involved, its
generic/mpn_div_qr_1.c.
I traced it to a nn=0 call to the underlying pi1 call. Dunno if that's
Ciao,
Il Sab, 15 Febbraio 2014 4:55 pm, Torbjorn Granlund ha scritto:
I traced it to a nn=0 call to the underlying pi1 call. Dunno if that's
problematic.
Yes, that's the problem. When n=1.
Code says:
if (d GMP_NUMB_HIGHBIT)
{ /* Normalized case */
uh = up[--n]; /* Here n goes
13 matches
Mail list logo
