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

[Richard Henderson <richard.henderson@linaro.org>]

On 5/20/21 8:40 AM, Peter Maydell wrote:
> 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 ?

I think it's a false positive.

Different naming schemes between gcc (from whence qrrnd came, 0 as least 
significant element) and the Berkeley softfloat code (0 as most significant 
element).


r~