Re: [PATCH 2/4] math: signal underflow for narrowing results that are tiny before rounding

On Mon, 3 Aug 2026, Matt Turner wrote:

> A result that rounds up to exactly the smallest normal value of the
> narrower type is not tiny any more once rounded, so architectures
> determining tininess after rounding do not raise underflow for it even
> though the exact result was tiny.  Whether underflow is due is decided
> by rounding the round-to-odd value with an unbounded exponent range:
> dividing by the smallest normal is exact and moves it into the normal
> range, so the conversion that follows rounds only the significand.

Are you claiming a bug on systems that implement IEEE 
tininess-after-rounding semantics correctly?  If so, please give a 
detailed example with the exact function inputs and value the current 
logic ends up rounding.  I'd expect round-to-odd to work correctly for 
tininess-after-rounding (since the at-least-two-bits-wider value being 
narrowed should produce the correct results both for narrowing to the 
target format, and for the narrowing with target precision but infinite 
exponent range that's used to determine underflow) if the hardware 
implements the right semantics.

Or are you working around a hardware bug that misses the right exceptions?  
If so, I'd expect the changes to be conditional so that no extra code is 
generated on architectures without this bug.

> A subnormal result is tiny by inspection, and an inexact narrowing to
> one underflows.  This is normally signaled by the narrowing conversion
> itself, but is lost where that conversion is carried out in more than
> one step: an intermediate type wide enough to keep the double rounding
> harmless for the value can still round to a number the narrower type
> represents exactly, leaving the final step exact.  This happens on
> alpha, where the compiler converts long double to float via double.

This sound like it's working around a compiler bug and so should 
definitely be conditional to only apply with architectures and compilers 
where it's needed.

-- 
Joseph S. Myers
[email protected]