Re: [PULL 42/46] softfloat: Move div_floats to softfloat-parts.c.inc

[Peter Maydell]

On Sun, 16 May 2021 at 13:38, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Rename to parts$N_div.
> Implement float128_div with FloatParts128.
>
> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---

> +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