https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122834
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- The GCC 12 behavior was to pick randomly for same precision types when neither of them is float/double/long double: auto a = 0.0DL + 1.0Q; auto b = 1.0Q + 0.0DL; This results in decltype (0.0DL) a and decltype (1.0Q) b. Anyway, given the http://eel.is/c++draft/conv.rank#2 wording, when extended floating points are involved (we don't define dfp types as those currently), I think the dfp types must have unordered ranks with extended binary floating point types, because their set of values is neither a proper subset or superset. Dfp types will have larger decimal exponent range for the same precision (e.g. for TD mode around 9.99...x10^6144 vs. _Float128 1.18...x10^4932) and there will be always values representable exactly just in one and not the other format, 0.3DF vs. 0.3F128. So, I'd go with: --- gcc/cp/typeck.cc.jj 2025-11-24 09:02:57.279720286 +0100 +++ gcc/cp/typeck.cc 2025-12-09 15:50:20.305052558 +0100 @@ -305,7 +305,14 @@ cp_compare_floating_point_conversion_ran const struct real_format *fmt1 = REAL_MODE_FORMAT (TYPE_MODE (t1)); const struct real_format *fmt2 = REAL_MODE_FORMAT (TYPE_MODE (t2)); - gcc_assert (fmt1->b == 2 && fmt2->b == 2); + /* Currently, extended floating point types are only binary, and + they never have a proper subset or superset of values with + decimal floating point types, so return 3 for unorderedn conversion + ranks. */ + gcc_assert (fmt1->b == 2); + if (fmt2->b == 10) + return 3; + gcc_assert (fmt2->b == 2); /* For {ibm,mips}_extended_format formats, the type has variable precision up to ~2150 bits when the first double is around maximum representable double and second double is subnormal minimum. Your testcase will then result in -Wnarrowing warning and be rejected with -pedantic-errors and auto a = 0.0DL + 1.0F128; auto b = 1.0F128 + 0.0DL; will be rejected by default, but I think that is what should happen. Use explicit casts to select what exactly you want to happen.
