On Sun, 17 May 2026 at 01:27, Richard Henderson <[email protected]> wrote: > > Notice the conflict between saturation and rebias_overflow, > which should never happen. Otherwise, saturate to INT32_MAX > and allow the usual overflow to max, infinity, or dnan. > > Signed-off-by: Richard Henderson <[email protected]> > --- > fpu/softfloat-parts.c.inc | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/fpu/softfloat-parts.c.inc b/fpu/softfloat-parts.c.inc > index 45606f8402..914e588ec8 100644 > --- a/fpu/softfloat-parts.c.inc > +++ b/fpu/softfloat-parts.c.inc > @@ -341,7 +341,17 @@ static void partsN(uncanon_normal)(FloatPartsN *p, > float_status *s, > g_assert_not_reached(); > } > > - exp = p->exp + fmt->exp_bias; > + /* Because exp_bias is positive, we can only overflow past INT_MAX. */ > + if (sadd32_overflow(p->exp, fmt->exp_bias, &exp)) { > + /* > + * rebias_overflow wants to compute a modulo exponent, which > + * conflicts with saturation. That said, saturation can only > + * happen with scalbn, which is not a PowerPC operation. > + */ > + assert(!s->rebias_overflow); > + exp = INT32_MAX;
As mentioned in the review comment on one of the Arm patches, I think that if we set exp to INT32_MAX here then the "round up" code below can increment it, overflowing to INT_MIN, and then we won't correctly spot that it is too large for the format. > + } thanks -- PMM
