libstdc++: _Bfloat16 for <compare>

Jon pointed out that we have TODO: _Bfloat16 in <compare>.
Right now _S_fp_fmt() returns _Binary16 for _Float16, __fp16 as well
as __bf16 and it actually works because we don't have a special handling
of _Binary16.  So, either we could just document that, but I'm a little bit
afraid if HPPA or MIPS don't start supporting _Float16 and/or __bf16.
If they do, we have the
 #if defined __hppa__ || (defined __mips__ && !defined __mips_nan2008)
                  // IEEE 754-1985 allowed the meaning of the quiet/signaling
                  // bit to be reversed. Flip that to give desired ordering.
                  if (__builtin_isnan(__x) && __builtin_isnan(__y))
                    {
                      using _Int = decltype(__ix);

                      constexpr int __nantype = __fmt == _Binary32  ?  22
                                              : __fmt == _Binary64  ?  51
                                              : __fmt == _Binary128 ? 111
                                              : -1;
                      constexpr _Int __bit = _Int(1) << __nantype;
                      __ix ^= __bit;
                      __iy ^= __bit;
                    }
 #endif
code, the only one where we actually care whether something is
_Binary{32,64,128} (elsewhere we just care about the x86 and m68k 80bits
or double double or just floating point type's sizeof) and we'd need
to handle there _Binary16 and/or _Bfloat16.

So this patch uses different enum for it even when it isn't needed right
now, after all _Binary16 isn't needed either and we could just use
_Binary32...

2022-11-02  Jakub Jelinek  <jakub@redhat.com>

	* libsupc++/compare (_Strong_order::_Fp_fmt): Add _Bfloat16.
	(_Strong_order::_Bfloat16): New static data member.
	(_Strong_order::_S_fp_fmt): Return _Bfloat16 for std::bfloat16_t.

0 files changed, 0 insertions, 0 deletions