================
@@ -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
