Various things has slowed down testing on the main machine ("martin")
lately making it 100% loaded 20 hours each day. Now I implemented
splitting of the testing burden over three days. Furthermore, shell
will no longer run any tests.
This static testing is reaching its limits. I have a
t...@gmplib.org (Torbjörn Granlund) writes:
> We should at least make sure the algorithms' corner cases are exercised,
> e.g., that large quotient are generated for Euclid's algorithm and that
> remainders of +-epsilon are used for division.
The mini-gmp testsuite is a bit hairy because it uses
ni...@lysator.liu.se (Niels Möller) writes:
ni...@lysator.liu.se (Niels Möller) writes:
> I'll try to log in to alpha-gentoo and reproduce.
Plain make check (i.e., main gmp testsuite) fails in the mpn subdir with
FAIL: t-get_d
=
Warning, IEEE denorm
ni...@lysator.liu.se (Niels Möller) writes:
If it happens again, the seed should be printed out.
https://gmplib.org/repo/gmp/rev/5abbd164e2a3
Yep. Unless the smaller operands affects the behaviour.
> #15 is strange, I haven't tried to understand why these libgcc link
> errors happens
t...@gmplib.org (Torbjörn Granlund) writes:
> Of the remaining https://gmplib.org/devel/mini-gmp-status.html issues I
> worry most about #2. Marco adjusted the parameters to make it faster,
> but I remain unconvinced that g5.gmplib.org-dyn:32 really needed 400
> seconds for the test with old
ni...@lysator.liu.se (Niels Möller) writes:
t...@gmplib.org (Torbjörn Granlund) writes:
> 2. The latest Gentoo doesn't support -fno-sanitize-recover. I suppose
>it works without it?
As I understand it, the point of -fno-sanitize-recover is to make
programs crash on the spot
t...@gmplib.org (Torbjörn Granlund) writes:
> 2. The latest Gentoo doesn't support -fno-sanitize-recover. I suppose
>it works without it?
As I understand it, the point of -fno-sanitize-recover is to make
programs crash on the spot when there's some undefined operation. Not
sure what the
