[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