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 GCD_1_METHOD==
"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 excluded...
--
Torbjörn
Plea
Il Lun, 28 Maggio 2018 4:39 pm, Torbjörn Granlund ha scritto:
> I assume this bug is now fixed, and so I will remove the test failure
> file.
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 imp
I assume this bug is now fixed, and so I will remove the test failure file.
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
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 probability
"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 realise that a plain assembly ena
