On Thursday, 14 December 2023 16:58:56 -03 Marc Mutz via Std-Discussion wrote:
> >
> > This is intentional and thus, by definition, not a problem.
>
> I didn't see any discussion about this in P1467, but I didn't check the
> meeting minutes, yet. So I don't see where you take the information from
> that it's intentional.

It may not be there. I did ask David Olsen specifically on this and he said
that the non-promotion is by design. It's also the reason why __fp16 and
_Float16 are different types and mangle differently with GCC and Clang.

> If the question is whether I found a problem in practice, then yes.
> Apart from the fact that it's a mathematically nonsensical, novel
> behaviour, there's also implementation divergence in the same compiler.
> GCC casts to float for comparison when the target doesn't support FP16
> in hardware, and casts the int to a PF16 if it does.
>
> You might call that a bug in GCC, and it very well might be, but it
> might also be that the standard is faulty here.

My question is whether the operation:

  1'000'000 <=> numeric_limits<std::float16_t>::infinity()

is less rather than equivalent in any compiler for a given platform target.
Or, equivalently, if

  1'000'000 < numeric_limits<std::float16_t>::infinity()

is true instead of false.

Given the discussion in the Qt change, I think we did find one for GCC, but
Clang implements it correctly.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering