On Sun, 16 May 2021 at 13:38, Richard Henderson
<[email protected]> wrote:
>
> Rename to parts$N_div.
> Implement float128_div with FloatParts128.
>
> Reviewed-by: Alex Bennée <[email protected]>
> Signed-off-by: Richard Henderson <[email protected]>
> ---
> +static bool frac64_div(FloatParts64 *a, FloatParts64 *b)
> +{
> + uint64_t n1, n0, r, q;
> + bool ret;
> +
> + /*
> + * We want a 2*N / N-bit division to produce exactly an N-bit
> + * result, so that we do not lose any precision and so that we
> + * do not have to renormalize afterward. If A.frac < B.frac,
> + * then division would produce an (N-1)-bit result; shift A left
> + * by one to produce the an N-bit result, and return true to
> + * decrement the exponent to match.
> + *
> + * The udiv_qrnnd algorithm that we're using requires normalization,
> + * i.e. the msb of the denominator must be set, which is already true.
> + */
> + ret = a->frac < b->frac;
> + if (ret) {
> + n0 = a->frac;
> + n1 = 0;
> + } else {
> + n0 = a->frac >> 1;
> + n1 = a->frac << 63;
> + }
> + q = udiv_qrnnd(&r, n0, n1, b->frac);
Hi -- Coverity is suspicious about this line (CID 1453209),
because udiv_qrrnd()'s prototype is
static inline uint64_t udiv_qrnnd(uint64_t *r, uint64_t n1,
uint64_t n0, uint64_t d)
but here we pass n0, n1 rather than n1, n0...
Bug, or false positive ?
thanks
-- PMM
