================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
