Possibly incorrect implementation of ILogB for BFloat16 and Half

[vcsjones]

ILogB is implemented on Half as such:

runtime/src/libraries/System.Private.CoreLib/src/System/Half.cs

Line 1535 in 8ff3668

return MinExponent - (BitOperations.LeadingZeroCount(x.TrailingSignificand) - BiasedExponentLength);

and TrailingSignificand is a ushort

runtime/src/libraries/System.Private.CoreLib/src/System/Half.cs

Line 137 in 8ff3668

internal ushort TrailingSignificand

However, BitOperations.LeadingZeroCount has no overload that accepts a ushort. So it is implicitly widened to the uint overload, and calculates the leading zero count as if the number had a 32-bit width instead of 16-bit.

I believe that means that Half.ILogB may be off by 16 for subnormal values (and probably BFloat16).

For example, for Half.Epsilon I would expect the ilogb to be -24, but is reported as -40.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.