[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

Joshua Cranmer via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 6 14:37:55 PST 2025


================
@@ -132,6 +133,70 @@ template <> struct llvm::DenseMapInfo<llvm::FoldingSetNodeID> {
     return LHS == RHS;
   }
 };
+constexpr unsigned CXX23FloatRankToIndex(clang::BuiltinType::Kind Kind) {
+  switch (Kind) {
+  case clang::BuiltinType::Float16:
+    return 0;
+  case clang::BuiltinType::BFloat16:
+    return 1;
+  case clang::BuiltinType::Float:
+    return 2;
+  case clang::BuiltinType::Double:
+    return 3;
+  case clang::BuiltinType::LongDouble:
+    return 4;
+  default:
+    // Both __float128 and __ibm128 are compiler extensions, not extended floating points.
+    // __float128 also predates the invention of floating-point types.
+    llvm_unreachable("Not a CXX23+ floating point builtin type");
----------------
jcranmer-intel wrote:

`__float128` is IEEE quad-precision, and should basically be the same thing as `std::float128_t`, so it should probably considered an extended floating-point type despite being a compiler extension.

I can't speak for `__ibm128`, since I'm not very familiar with the platforms where it exists, but it seems that GCC doesn't treat it as an extended floating-point type (per https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html). Given how weird of a type it is, that seems like a very reasonable decision.

https://github.com/llvm/llvm-project/pull/78503


More information about the llvm-commits mailing list