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

Reply via email to