On 2026-02-26 08:06, Richard Henderson wrote: > On 2/25/26 22:08, Max Chou wrote: > > The OCP FP8 E4M3 format has only a single NaN encoding (0x7F/0xFF), > > Replace the indirect check via parts_is_snan_frac with a direct > > check of no_signaling_nans to make the intent clearer. > > > > Signed-off-by: Max Chou <[email protected]> > > --- > > fpu/softfloat-parts.c.inc | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/fpu/softfloat-parts.c.inc b/fpu/softfloat-parts.c.inc > > index 3c323c0cec..5ef7e2d921 100644 > > --- a/fpu/softfloat-parts.c.inc > > +++ b/fpu/softfloat-parts.c.inc > > @@ -245,8 +245,8 @@ static void partsN(canonicalize)(FloatPartsN *p, > > float_status *status, > > case float_expmax_e4m3: > > if (p->frac_hi == 0b111) { > > frac_shl(p, fmt->frac_shift); > > - p->cls = (parts_is_snan_frac(p->frac_hi, status) > > - ? float_class_snan : float_class_qnan); > > + p->cls = no_signaling_nans(status) ? float_class_qnan : > > + float_class_snan; > > return; > > } > > /* otherwise normal */ > > But parts_is_snan_frac also checks snan_bit_is_one. > > > r~
Hi Richard, You're right. I missed that parts_is_snan_frac respects both snan_bit_is_one and no_signaling_nans flags and I just assumed that user will use no_signaling_nans flag to define the E4M3 NaN. The current implementation correctly allows targets to control E4M3 NaN classification through either mechanism, and this change would have removed the snan_bit_is_one flexibility. I'll drop this patch and send a v2 series containing only the two bug fix patches: Thanks, rnax
