On 5/20/26 09:33, Peter Maydell wrote:
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
Thanks.
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?
Probably should, since it's trivial, and then we wouldn't have to think about
it.
I wish there were an annotation for default: that doesn't suppress the
switch-missed-enumerator warning, for use with g_assert_not_reached().
r~
