[email protected] (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 for just certain similar configs. The direct links to examples are dead. They were quite garbled, now hopefully fixed. Do these system normally have LD_LIBRARY_PATH set? If so, maybe something wrong when gmp:s .lib is prepended to the path. echo $LD_LIBRARY_PATH /usr/local/lib What confused me was that the -fake test variant (which runs through many CPUs for a fat build) didn't fail. Now I see why; they don't include mini-gmp. I havn't followed the logic of the local test wrapper, but presumably it doesn't prepend (or append) correctly to LD_LIBRARY_PATH. When the dust has settled, we'll have to think about whether we should make a "mini-gmp release" with bug-fixes, or just send out an announcement. Agreed. Let's follow this plan: 1. Fix any issues remaining which we think are are worth fixing (i.e., we don't need to work around every bug elsewhere). 2. Make sure the testsuite is up to scratch wrt hard-to-test algorithms (for example those I mentioned yesterday) 3. Then let the test machinery run for a few weeks; this ought to trigger any remaining arithmetic bugs. (Please recall that 6 days are required for a full cycle as things are set up these days.) 4. Perhaps release 6.1.2 with the now hopefully bug-free mini-gmp. (Or somehow release it separately (whatever that means) or just shout about this and direct people to the repo.) -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-devel mailing list [email protected] https://gmplib.org/mailman/listinfo/gmp-devel
