[PATCH] D53670: Revert "Teach __libcpp_is_floating_point that __fp16 and _Float16 are"

[Richard Smith - zygoloid via Phabricator via llvm-commits]

rsmith added a comment.

In https://reviews.llvm.org/D53670#1275677, @ldionne wrote:

> In https://reviews.llvm.org/D53670#1275188, @rsmith wrote:
>
> > What's the problem with the state of affairs prior to this change? If some compiler / environment is defining a `__FLT16_MANT_DIG__` macro but not providing a `_Float16` type, isn't that just a bug in that environment?
>
>
> There's also the fact that e.g. `__fp16` doesn't work with the stream's `operator>>` and similar problems. Because of this, we're effectively lying about the fact that `__fp16` is a floating point type. This was Marshall's point, and I agree with it.
>
> @EricWF I do agree that if it quacks like a floating point and it walks like a floating point, then it is a floating point. However, `__fp16` doesn't seem to quack quite right, so it's not a floating point (at least not without additional work).


I do mostly agree with this for `__fp16` (which is a weird storage-only type with some arbitrary limitations). But not for `_Float16` nor `__float128`, which are both proper floating-point types.

For whatever it's worth, in libstdc++ `std::is_floating_point<__float128>::value` yields `true` by default (which in this case means in `-std=gnu++XY` but not in `-std=c++XY`) on targets that have a `__float128` type. They also supply an `abs` overload for `__float128` in that case, but nothing else (surprisingly not even `numeric_limits`).


Repository:
  rL LLVM

https://reviews.llvm.org/D53670