https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #14 from Jason Merrill <jason at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #13) > (In reply to Hana Dusíková from comment #12) > > I'm using [[gnu::used]] to emit constexpr symbol so it can be part of > > compatible interface. Sure, that would work if you use a macro to only apply that attribute in the TU where you want it emitted. And perhaps gnu_inline instead in other TUs. > I think we don't have a problem with exporting the ABI compatible symbols, > those are compiled with -std=c++98 mostly. The question is whether we want > to pay the price of defining comdat vtables for all the exception subclasses > in C++26. Again, we'd only emit them if they're needed by something else. And they're pretty small compared to all the comdat templates we're already emitting (when needed). So perhaps we don't need to do anything else if we already have the symbols for compatibility. > I think #pragma interface could work if the exception subclasses are defined > in separate headers, but unsure if it can work well for std::exception > itself when it has also > _GLIBCXX26_CONSTEXPR exception(const exception&) = default; > _GLIBCXX26_CONSTEXPR exception& operator=(const exception&) = default; > _GLIBCXX26_CONSTEXPR exception(exception&&) = default; > _GLIBCXX26_CONSTEXPR exception& operator=(exception&&) = default; > While one can't take address of the ctor (and perhaps it could be > [[__gnu__::__always_inline__]] too just in case), I think for the assignment > operator one could take pointer to member and let it be emitted out of line, > but with #pragma interface that would require definition somewhere else > (which is not the case). Yeah, probably best not to go back to #pragma interface, though I think it's a bug that #pragma interface affects explicitly defaulted functions when it doesn't affect implicitly defaulted functions.
