On 1/1/26 1:15 AM, Jakub Jelinek wrote:
Hi!libstdc++ in various spots used just function/method declarations and definitions inside of libstdc++.so.6 for various reasons, whether because the bodies were too large or because it wanted a key method for the class to be defined in the library only to avoid vtables etc. in many TUs. Already when working on the first constexpr exception patch on the library side I've noticed that std::exception etc. have for C++26 the vtables emitted everywhere, but these two new PRs, PR123183 and PR123326 issues show that it is even bigger problem. While for both of these (one is about FreeBSD link failures when using libstdc++.a and format.o from that library is linked in and -liconv is not added, the other about MinGW clash between inline functions (which can't be weak) and non-inline definition in libstdc++.a) need to be resolved some way in any case, the FreeBSD perhaps through addition of libstdc++.spec or arrange in some other way to link in -liconv when linking with -lstdc++ and for MinGW perhaps making the libstdc++.a functions inline not in the class definitions (which is something that doesn't work on arm-eabi though), especially the FreeBSD PR shows quite undesirable optimization problem. Previously, when something needed std::bad_alloc::~bad_alloc(), it linked libstdc++.a(bad_alloc.o). But now many C++26 compiled objects also export std::bad_alloc::~bad_alloc() and it depends on the luck which one will be linked, so with luck like before the very small bad_alloc.o, when less lucky uselessly the whole format.o or something perhaps even larger. Even before I think Jonathan complained that with C++ requiring more and more large functions/methods to be constexpr lots of things become inline functions which might not be desirable in many cases. The following patch introduces a new attribute - gnu::constexpr_only - which can be applied only to functions/methods with constexpr keyword and will make their bodies only available to constexpr evaluation but otherwise pretend it is just a declaration, not function definition which if used needs to be defined somewhere else (like in libstdc++.{so.6,a}). A constexpr method marked with this attribute can still be a key method of a class too.
Hmm, I would think we want something closer to gnu_inline that specifically affects linkage, without the other effects; it seems desirable to be able to inline these functions outside of constant evaluation as well.
Jason
