[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
cor3ntin wrote: @codemzs Sometimes around January. But it would be best not to wait until the last moment - especially if someone (or you!) is interested in working on the library bits of that paper https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
codemzs wrote: > @codemzs No worries! > > > > There is no chance that this could make Clang 21, sorry (the release is in a > few weeks and we are past the point where we can backport large features) > > > > But there would be value in making progress on this feature on main soon so > that it has time to mature for clang 22. > > How does that sound? > > > > Thanks! Thanks, @cor3ntin sounds reasonable to me, do you happen to know the code complete for clang 22? https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
cor3ntin wrote: @codemzs No worries! There is no chance that this could make Clang 21, sorry (the release is in a few weeks and we are past the point where we can backport large features) But there would be value in making progress on this feature on main soon so that it has time to mature for clang 22. How does that sound? Thanks! https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
codemzs wrote: > > @codemzs I want to make sure you saw the pending feedback. I think it would > > be great if we could land this for clang 21 :) > > @cor3ntin I plan to address the feedback this weekend. I agree with you on > aiming to get this in for clang 21, thank you for letting me know. @cor3ntin I am really sorry for delay in my response. I have been busy with work on several time sensitive projects that just happen to come one after the other. I can prioritize checking-in this PR if you think we still have a chance to get in for clang 21? Even if not I fully plan on closing this as soon as possible. @AaronBallman I'd like to get your thoughts as well? https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -132,6 +133,70 @@ template <> struct
llvm::DenseMapInfo {
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");
lntue wrote:
I'm curious how will `_Float128`/`std::float128_t` fit into this together with
`__float128` and `long double`?
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -470,8 +470,16 @@ static void InitializeStandardPredefinedMacros(const
TargetInfo &TI,
if (LangOpts.CPlusPlus26)
// FIXME: Use correct value for C++26.
Builder.defineMacro("__cplusplus", "202400L");
-else if (LangOpts.CPlusPlus23)
+else if (LangOpts.CPlusPlus23) {
Builder.defineMacro("__cplusplus", "202302L");
+ // [C++23] 15.11p2 [cpp.predefined]
+ if (TI.hasFloat16Type()) {
+Builder.defineMacro("__STDCPP_FLOAT16_T__", "1");
+ }
+ if (TI.hasFullBFloat16Type()) {
+Builder.defineMacro("__STDCPP_BFLOAT16_T__", "1");
+ }
frederick-vs-ja wrote:
They will get defined in C++26 mode. `LangOpts.CPlusPlus23` means "C++23 and
later", not simply "C++23".
Although I think it will make a bit more sense to define these macros in all
modes.
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -132,6 +133,70 @@ template <> struct
llvm::DenseMapInfo {
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");
hubert-reinterpretcast wrote:
Because `__float128` conflicts with `long double` in the name mangling (on at
least some platforms), I would hesitate to call it an extended floating-point
type. It's a non-conforming extension.
https://godbolt.org/z/98b696cr9
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -9278,6 +9278,8 @@ def err_cast_pointer_to_non_pointer_int : Error<
def err_nullptr_cast : Error<
"cannot cast an object of type %select{'nullptr_t' to %1|%1 to 'nullptr_t'}0"
>;
+def err_invalid_implicit_floating_point_cast : Error<
shafik wrote:
I don't see this diagnostic emitted in any of the tests, am I just missing this?
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
cor3ntin wrote: @codemzs I want to make sure you saw the pending feedback. I think it would be great if we could land this for clang 21 :) https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -4446,6 +4455,73 @@ CompareStandardConversionSequences(Sema &S, SourceLocation Loc, ? ImplicitConversionSequence::Better : ImplicitConversionSequence::Worse; + // C++23 [over.ics.rank]p4b3: + // A conversion in either direction between floating-point type FP1 and + // floating-point type FP2 is better than a conversion in the same direction + // between FP1 and arithmetic type T3 if: + // 1) The floating-point conversion rank ([conv.rank]) of FP1 is equal to the + // rank of FP2, and 2) T3 is not a floating-point type, or T3 is a + // floating-point type whose rank is not equal to the rank of FP1, or the + // floating-point conversion subrank ([conv.rank]) of FP2 is greater than the + // subrank of T3. ilya-biryukov wrote: I am somewhat familiar with the overload resolution code and this has popped up in our internal discussions, so I would be happy to review that part if you need help. I am not sure how much more eyes is needed on the whole change, let me know if looking only at overloading is useful... https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -11226,12 +11232,14 @@ void Sema::CheckImplicitConversion(Expr *E, QualType
T, SourceLocation CC,
DiagnoseImpCast(*this, E, T, CC, diag::warn_impcast_float_precision);
}
// ... or possibly if we're increasing rank, too
- else if (Order < 0) {
+ else if (Order == FRCR_Lesser) {
if (SourceMgr.isInSystemMacro(CC))
return;
DiagnoseImpCast(*this, E, T, CC, diag::warn_impcast_double_promotion);
}
+ assert(Order != FRCR_Unordered &&
+ "Unordered floating types are not allowed.");
jcranmer-intel wrote:
Maybe mention "in implicit conversion" in the message here?
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -132,6 +133,70 @@ template <> struct
llvm::DenseMapInfo {
return LHS == RHS;
}
};
+constexpr unsigned CXX23FloatRankToIndex(clang::BuiltinType::Kind Kind) {
jcranmer-intel wrote:
This function appears to be unused now.
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -0,0 +1,505 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++23 -triple x86_64-unknown-unknown
-target-feature +fullbf16 -verify -ast-dump %s | FileCheck %s
+#include
+_Float16 f16_val_1 = 1.0bf16; // expected-error {{cannot initialize a variable
of type '_Float16' with an rvalue of type '__bf16'}}
+_Float16 f16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of
type '_Float16' with an rvalue of type 'float'}}
+_Float16 f16_val_3 = 1.0; // expected-error {{cannot initialize a variable of
type '_Float16' with an rvalue of type 'double'}}
+_Float16 f16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of
type '_Float16' with an rvalue of type 'long double'}}
+_Float16 f16_val_6 = 1.0f16;
+//CHECK: VarDecl {{.*}} f16_val_6 '_Float16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+_Float16 f16_val_7 = static_cast<_Float16>(1.0bf16); // expected-error
{{static_cast from '__bf16' to '_Float16' is not allowed}}
+_Float16 f16_val_8 = static_cast<_Float16>(1.0f);
+//CHECK: VarDecl {{.*}} f16_val_8 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16>
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+_Float16 f16_val_9 = static_cast<_Float16>(1.0);
+//CHECK: VarDecl {{.*}} f16_val_9 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16>
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+_Float16 f16_val_10 = static_cast<_Float16>(1.0l);
+//CHECK: VarDecl {{.*}} f16_val_10 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16>
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+_Float16 f16_val_11 = static_cast<_Float16>(1.0f16);
+//CHECK: VarDecl {{.*}} f16_val_11 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16>
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_1 = 1.0f16; // expected-error {{cannot initialize a
variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type
'_Float16'}}
+decltype(0.0BF16) bf16_val_2 = 1.0f; // expected-error {{cannot initialize a
variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type
'float'}}
+decltype(0.0BF16) bf16_val_3 = 1.0; // expected-error {{cannot initialize a
variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type
'double'}}
+decltype(0.0BF16) bf16_val_4 = 1.0l; // expected-error {{cannot initialize a
variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'long
double'}}
+decltype(0.0BF16) bf16_val_5 = 1.0bf16;
+//CHECK: VarDecl {{.*}} bf16_val_5 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '__bf16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_6 = static_cast(1.0f16); //
expected-error {{static_cast from '_Float16' to 'decltype(0.BF16)' (aka
'__bf16') is not allowed}}
+decltype(0.0BF16) bf16_val_7 = static_cast(1.0f);
+//CHECK: VarDecl {{.*}} bf16_val_7 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16'
static_cast
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+decltype(0.0BF16) bf16_val_8 = static_cast(1.0);
+//CHECK: VarDecl {{.*}} bf16_val_8 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16'
static_cast
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+decltype(0.0BF16) bf16_val_9 = static_cast(1.0l);
+//CHECK: VarDecl {{.*}} bf16_val_9 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16'
static_cast
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+decltype(0.0BF16) bf16_val_10 = static_cast(1.0bf16);
+//CHECK: VarDecl {{.*}} bf16_val_10 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16'
static_cast
+//CHECK-NEXT: FloatingLiteral {{.*}} '__bf16' 1.00e+00
+
+float f_val_1 = 1.0f16;
+//CHECK: VarDecl {{.*}} f_val_1 'float' cinit
+//CHECK-NEXT: ImplicitCastExpr {{.*}} 'float'
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+float f_val_2 = 1.0bf16;
+//CHECK: VarDecl {{.*}} f_val_2 'float' cinit
+//CHECK-NEXT: ImplicitCastExpr {{.*}} 'float'
+//CHECK-NEXT: FloatingLiteral {{.*}} '__bf16' 1.00e+00
+float f_val_3 = 1.0;
+//CHECK: VarDecl {{.*}} f_val_3 'float' cinit
+//CHECK-NEXT: ImplicitCastExpr {{.*}} 'float'
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+float f_val_4 = 1.0l;
+//CHECK: VarDecl {{.*}} f_val_4 'float' cinit
+//CHECK-NEXT: ImplicitCastExpr {{.*}} 'float'
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+float f_val_5 = 1.0f;
+//CHECK: VarDecl {{.*}} f_val_5 'float' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+
+double d_val_1 = 1.0f16;
+//CHECK: VarDecl {{.*}}
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -4446,6 +4455,73 @@ CompareStandardConversionSequences(Sema &S, SourceLocation Loc, ? ImplicitConversionSequence::Better : ImplicitConversionSequence::Worse; + // C++23 [over.ics.rank]p4b3: + // A conversion in either direction between floating-point type FP1 and + // floating-point type FP2 is better than a conversion in the same direction + // between FP1 and arithmetic type T3 if: + // 1) The floating-point conversion rank ([conv.rank]) of FP1 is equal to the + // rank of FP2, and 2) T3 is not a floating-point type, or T3 is a + // floating-point type whose rank is not equal to the rank of FP1, or the + // floating-point conversion subrank ([conv.rank]) of FP2 is greater than the + // subrank of T3. jcranmer-intel wrote: I'm unfortunately not fluent enough in the workings of overload resolution in Clang to understand if this is the correct place to put this logic. What I can do, though, is note the most surprising of the consequences of the rules: floating-point promotion (which is defined as, and only as, float ->double) is preferred over floating-point conversions, with the end result that float -> double is considered better than float -> _Float32. Given that _Float32 isn't supported for this patch, it's hard to test for this, but I still would like to know what existing code handles floating-point promotion to know if this is in the right place. https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
https://github.com/jcranmer-intel commented: I think this concludes my full look at this PR. I don't fully have a grasp on the mechanisms of C++ overload to comment on key parts of this patch. This also doesn't implement enough of the hard cases of P1467R9 (namely _Float32/_Float64) for me to rely on correct test results to indicate that it implements the changes correctly. https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -7444,9 +7444,12 @@ isArithmeticArgumentPromotion(Sema &S, const
ImplicitCastExpr *ICE) {
From = VecTy->getElementType();
if (const auto *VecTy = To->getAs())
To = VecTy->getElementType();
- // It's a floating promotion if the source type is a lower rank.
- return ICE->getCastKind() == CK_FloatingCast &&
- S.Context.getFloatingTypeOrder(From, To) < 0;
+ // It's a floating promotion if the source type is float.
+ // [7.3.8p1][conv.fpprom] A prvalue of type float can be converted to a
+ // prvalue of type double. The value is unchanged.
+ return (ICE->getCastKind() == CK_FloatingCast &&
+ S.Context.isPromotableFloatingType(From) &&
+ S.Context.getPromotedFloatingType(From) == To);
jcranmer-intel wrote:
Given that the *only* floating-point promotion is `float` -> `double`, and
we've just seen C++23 add a slew of new types without any other promotions, I'm
not sure these helper methods are helpful to understanding what's going on
here, over just hard-coding the `float`->`double` check here.
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
https://github.com/jcranmer-intel edited https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -132,6 +133,70 @@ template <> struct
llvm::DenseMapInfo {
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");
+ }
+}
+
+// C++23 6.8.6p2 [conv.rank]
+FloatConvRankCompareResult
+CXX23CompareFpConversionRanks(BuiltinType::Kind LHSKind,
+ BuiltinType::Kind RHSKind, QualType LHS,
+ QualType RHS, const ASTContext &Ctx) {
+
+ // Same types.
+ if (LHSKind == RHSKind)
+return FloatConvRankCompareResult::FRCR_Equal;
+
+ // Special case comparision between float, double and long double.
+ if (LHSKind == BuiltinType::Float && RHSKind == BuiltinType::Double)
+return FloatConvRankCompareResult::FRCR_Lesser;
+ if (LHSKind == BuiltinType::Double && RHSKind == BuiltinType::Float)
+return FloatConvRankCompareResult::FRCR_Greater;
+ if (LHSKind == BuiltinType::Float && RHSKind == BuiltinType::LongDouble)
+return FloatConvRankCompareResult::FRCR_Lesser;
+ if (LHSKind == BuiltinType::LongDouble && RHSKind == BuiltinType::Float)
+return FloatConvRankCompareResult::FRCR_Greater;
+ if (LHSKind == BuiltinType::Double && RHSKind == BuiltinType::LongDouble)
+return FloatConvRankCompareResult::FRCR_Lesser;
+ if (LHSKind == BuiltinType::LongDouble && RHSKind == BuiltinType::Double)
+return FloatConvRankCompareResult::FRCR_Greater;
+
+ const llvm::fltSemantics &LHSSemantics = Ctx.getFloatTypeSemantics(LHS);
+ const llvm::fltSemantics &RHSSemantics = Ctx.getFloatTypeSemantics(RHS);
+
+ bool LHSRepresentableByRHS =
+ llvm::APFloat::isRepresentableBy(LHSSemantics, RHSSemantics);
+ bool RHSRepresentableByLHS =
+ llvm::APFloat::isRepresentableBy(RHSSemantics, LHSSemantics);
jcranmer-intel wrote:
If you look at the definition of `fltSemantics::isRepresentableBy`, it doesn't
precisely match the definition of 2.1, since that requires the set of values of
one type to be a proper subset of the other, and the function is only checking
finite, nonzero values. That said, the distinction is only going to be relevant
for the weird tiny FP types, which I hope do not become extended floating-point
types, so it probably doesn't matter.
Where it does matter is I think the `ppc_fp128` semantics return bogus values
that don't reflect the reality, so that the conversion rank of `long double`
and `_Float16` is going to come out wrong on systems where `long double` is
`ppc_fp128`.
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -132,6 +133,70 @@ template <> struct
llvm::DenseMapInfo {
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
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -470,8 +470,16 @@ static void InitializeStandardPredefinedMacros(const
TargetInfo &TI,
if (LangOpts.CPlusPlus26)
// FIXME: Use correct value for C++26.
Builder.defineMacro("__cplusplus", "202400L");
-else if (LangOpts.CPlusPlus23)
+else if (LangOpts.CPlusPlus23) {
Builder.defineMacro("__cplusplus", "202302L");
+ // [C++23] 15.11p2 [cpp.predefined]
+ if (TI.hasFloat16Type()) {
+Builder.defineMacro("__STDCPP_FLOAT16_T__", "1");
+ }
+ if (TI.hasFullBFloat16Type()) {
+Builder.defineMacro("__STDCPP_BFLOAT16_T__", "1");
+ }
jcranmer-intel wrote:
If I'm understanding the code correctly, these don't get defined in C++26 mode,
which seems like a bug to me.
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -7670,27 +7739,68 @@ static FloatingRank getFloatingRank(QualType T) {
}
}
+/// C++23 6.8.5 [conv.rank]
/// getFloatingTypeOrder - Compare the rank of the two specified floating
/// point types, ignoring the domain of the type (i.e. 'double' ==
-/// '_Complex double'). If LHS > RHS, return 1. If LHS == RHS, return 0. If
-/// LHS < RHS, return -1.
-int ASTContext::getFloatingTypeOrder(QualType LHS, QualType RHS) const {
+/// '_Complex double').
+/// If LHS > RHS, return FRCR_Greater. If LHS == RHS, return FRCR_Equal. If
+/// LHS < RHS, return FRCR_Lesser. If the values representable by the two
+/// are not subset of each other, return FRCR_Unordered. If LHS == RHS but
+/// LHS has a higher subrank than RHS return FRCR_Equal_Greater_Subrank else
+/// return FRCR_Equal_Lesser_Subrank.
+FloatConvRankCompareResult
+ASTContext::getFloatingTypeOrder(QualType LHS, QualType RHS) const {
+ if (LHS->isCXX23FloatingPointType(*this) &&
jcranmer-intel wrote:
I think it's worth explicitly calling out in a comment here that C and C++ have
different rules for the extended floating-point types.
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -0,0 +1,563 @@ +// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature +// RUN: %clang_cc1 -std=c++23 -triple x86_64-unknown-unknown -target-feature +fullbf16 -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK jcranmer-intel wrote: x86 is unfortunately pretty tame as far as testing these rules goes. You should also test on: * a target where double = long double = IEEE double-precision * a target where long double = IEEE quad-precision * a target where long double = `ppc_fp128` https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
https://github.com/jcranmer-intel commented: I haven't fully reviewed this, but here's some comments to start with: https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
https://github.com/jcranmer-intel edited https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
codemzs wrote: Hi @shafik , it looks like you’re the designated reviewer for C++ standards. Would you mind taking a look at this PR? It has already been through several iterations with @tahonermann, and we’d really appreciate your feedback. Thanks! https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)
@@ -5565,6 +5565,15 @@ float APFloat::convertToFloat() const {
return Temp.getIEEE().convertToFloat();
}
+/// Returns true if the semantics can represent all of the values that the
other
+/// semantics can represent.
+///
+/// \param Sem - type float semantics
codemzs wrote:
Update comment to include the second parameter.
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
