On Sun, 17 May 2026 at 01:36, Richard Henderson
<[email protected]> wrote:
>
> Signed-off-by: Richard Henderson <[email protected]>



> +static FP8MulContext fp8_mul_start(CPUARMState *env, int scale_mask)
> +{
> +    uint64_t fpmr = env->vfp.fpmr;
> +
> +    FP8MulContext ret = {
> +        .stat = env->vfp.fp_status[FPST_A64],
> +        .fmt1 = fp8_input_fmt[FIELD_EX64(fpmr, FPMR, F8S1)],
> +        .fmt2 = fp8_input_fmt[FIELD_EX64(fpmr, FPMR, F8S2)],
> +        .scale = -(FIELD_EX64(fpmr, FPMR, LSCALE) & scale_mask),
> +    };
> +
> +    set_flush_to_zero(0, &ret.stat);
> +    set_flush_inputs_to_zero(0, &ret.stat);
> +    set_default_nan_mode(true, &ret.stat);
> +    set_float_rounding_mode(FIELD_EX64(fpmr, FPMR, OSM)
> +                            ? float_round_nearest_even_max
> +                            : float_round_nearest_even, &ret.stat);
> +
> +    return ret;
> +}

This use of float_round_nearest_even_max prompted me to look at
the uses of it in fpu/, and it looks like the implementation is
incomplete. Most importantly, although commit 72330260cdb420 added
it to the first "switch (s->float_rounding_mode)" in uncanon_normal,
it missed adding it to the one later in the same function, which
I think means we will generate wrongly-rounded answers for
denormals. A fix is probably:

diff --git a/fpu/softfloat-parts.c.inc b/fpu/softfloat-parts.c.inc
index efd130bf16..6cc9429ebe 100644
--- a/fpu/softfloat-parts.c.inc
+++ b/fpu/softfloat-parts.c.inc
@@ -450,6 +450,7 @@ static void partsN(uncanon_normal)(FloatPartsN *p,
float_status *s,
             /* Need to recompute round-to-even/round-to-odd. */
             switch (s->float_rounding_mode) {
             case float_round_nearest_even:
+            case float_round_nearest_even_max:
                 if (N > 64 && frac_lsb == 0) {
                     inc = ((p->frac_hi & 1) ||
                            (p->frac_lo & round_mask) != frac_lsbm1

There are also other places within fpu/ which switch on the
rounding mode and have no support for the new even_nearest_max
enum value. Those ones have a default case that asserts or
aborts, so at least you'll know it if you run into them.
They are round_to_int_normal, and roundAndPackFloatx80.
Is it worth extending the support for this rounding mode to
either of those?

-- PMM

Reply via email to