On Tuesday, 20 January 2026 11:52:34 Pacific Standard Time Marc Mutz via Development wrote: > Hi, > > GCC 16 changed the numerical value of std::partial_ordering::unordered. This > is BiC, of course, but, as far as we know, libstd++ only breaks the C++20 > ABI, not the C++17 one.
Because std::partial_ordering only exists in C++20 and the underlying value is not used out-of-line anywhere. > For better or worse, we have implemented Qt::partial_ordering as a > binary-compatible C++17 replacement for C++20 std::partial_ordering (ditto > the other ordering types, but, so far, no platform has broken ABI for > those, yet). Binary-compatible means that we hard-code our numerical values > to each stdlib's values. So there's no one Qt::partial_ordering::unordered > value, it differs per stdlib, and we have tests that, in C++20 builds, make > sure the two (Qt:: and std::) are of the same size and numerical value. Correct, but you're burying the important detail: we didn't have to be binary- compatible with the std::*_ordering values. We *chose* to do that so that conversion between one and the other could simply be a std::bit_cast. If you remove the std::bit_cast, then there's no need and we are free to choose any value we want. > The idea was that the two are interchangeable both in BC and SC terms. Incorrect. Our type is our type and cannot be interchanged with the std one. At a minimum, the mangling is different. They are not SC either: that's why they are in the Qt namespace, not q20. > We have two options, both of them are not optimal: > > We can continue to maintain BC with the std types and break BC for Qt builds > of GCC 15 and 16 or we maintain BC for Qt builds of GCC 15 and 16 and break > BC with the std types. Or, phrased differently: we can choose to keep Qt binary compatibility or not. > We don't know which option is worse, so we'd like to get your feedback. > OTOH, users may have come to depend on the BC between the Qt and std types > and use them in their own ABIs. OTOH, users may expect that a C++17 build > of Qt is BC between GCC 15 and 16 because libstdc++ only broke BC for C++20 > builds, not C++17 ones. I think it's VERY clear which option is worse, to the point that I didn't even try to argue for it in https://codereview.qt-project.org/c/qt/qtbase/+/704603. > We're in particular interested in how Linux distributions intend to handle > the issue. Are you shipping C++20 or C++17 builds of Qt? Or separate ones? > How do you handle the C++20 BiC in libstdc++ for GCC 16? They are shipping C++17 because that's the only one *we* support their compiling Qt with. *We* choose how Qt gets compiled. The option to choose the C++ standard version is for developers (us) to figure out whether our code works or not. > Personally, I think fixing stdlib BiCs in Qt is a slippery slope. When we > accepted std types in the Qt ABI, we accepted that a stdlib ABI break > breaks Qt BC, too. The only reason we didn't see problems earlier was that > we're coming out of a 15-year period of stability where no stdlib ABI was > broken since C++11's container changes. So it comes as a surprise now, even > though we should have anticipated it all the time. Except that we didn't accept *every* Standard Library type in our ABI. When we started building with C++11 in 5.6, we accepted only C++98 types. When we started with C++17 in 6.0, we accepted C++11 - q.v. the lack of std::filesystem::path out-of-line. When we first talked about C++20, the GCC devs (Ville in particular) were very clear that they were not yet committing to an ABI. The next time we discussed std::format, they repeated their position that we should not depend on the C+ +20 ABI yet. And we haven't. That's why we introduced Qt::partial_ordering. In other words, we've already done the right thing to shield us from the breakage. We were incomplete, in that we were doing std::bit_cast based on the stdlib vendor, instead of an if constexpr of the right values. That's what my patch fixes. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCG - Platform & Sys. Eng.
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
