On 02/02/2024 01:47, Paul Eggert wrote:
> On 2/1/24 13:59, Pádraig Brady wrote:
>>
>> bfloat16 looks like a truncated single precision IEEE,
>> so we should be able to just pad the extra 16 bits with zeros
>> when converting to single precision internally for processing.
> 
> Sounds good. This would mean od could work even the platform doesn't
> support bfloat16_t, since od.c could fall back on the above code (though
> I suppose it could be endianness-dependent).

I see that __bf16 is supported by released versions of gcc and clang,
so rather than add conversion complexity to the core od print loop,
the attached relies on compiler support for _Float16 and __bf16 types,
which compilers will expand to more targets going forward.

I tested the attached on:

gcc 13, clang 17 x86 (Both types supported)
gcc 7 aarch64 (Only -fH supported)
gcc 13 ppc(be) (Neither supported (both will be with GCC 14))

I'll commit this later.
Marking this bug as done.

thanks,
Pádraig