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