On 2018-09-05 17:43:29 +0200, Vincent Lefevre wrote:
> On 2018-09-05 16:00:18 +0200, Torbjorn Granlund wrote:
> > Perhaps this can be automated and given a new, trendy name now that
> > fuzzing has been on everybody's mind for so long? :-)
>
> An interesting place is to check inequalities on
On 2018-09-05 16:00:18 +0200, Torbjorn Granlund wrote:
> paul zimmermann writes:
>
> void
> mpz_add_ui (mpz_t r, const mpz_t a, unsigned long b)
> {
> b = b % 0x;
> if (a->_mp_size >= 0)
> r->_mp_size = mpz_abs_add_ui (r, a, b);
> else
> r->_mp_size =
paul zimmermann writes:
void
mpz_add_ui (mpz_t r, const mpz_t a, unsigned long b)
{
b = b % 0x;
if (a->_mp_size >= 0)
r->_mp_size = mpz_abs_add_ui (r, a, b);
else
r->_mp_size = -mpz_abs_sub_ui (r, a, b);
}
An interestng approach, patch the library to
Any particular machines you have in mind? Would be nice with some
numbers.
Any Sparc system except for T4/T5.
Alpha except for ev6*.
Pentium4 (in particular nocona in 64-bit mode).
The original Intel Atom in particular in 64-bit mode.
The newer inte Atom/Silvermont (but not the
ni...@lysator.liu.se (Niels Möller) writes:
> I believe we could find CPUs (mainly low-end and obsolete hig-end ones)
> where the old code will beat the new code because of the old code's
> lower submul_1 size argument.
Any particular machines you have in mind? Would be nice with some
Hi,
I noticed the mini-gmp test suite does not seem to contain any test of
mpz_add_ui with the unsigned long argument having more than 32 bits.
Indeed with the following change "make check" still says "All 25 tests passed"
(with the mini-gmp from gmp-6.1.2):
void
mpz_add_ui (mpz_t r,
t...@gmplib.org (Torbjörn Granlund) writes:
> Why is (the obsolete function) mpn_tdiv_qr's interface relevant
> here?
Because it's the only top-level function, and because a fair amount of
the newer division code also doesn't clobber np (it seems dc might allow
clobbering n, and the mu code
