On Wed, 24 Aug 2022 at 23:47, Jonathan Wakely <jwak...@redhat.com> wrote: > > On Wed, 24 Aug 2022 at 23:39, Alexandre Oliva <ol...@gnu.org> wrote: > > > > On Aug 24, 2022, Jonathan Wakely via Gcc-patches <gcc-patches@gcc.gnu.org> > > wrote: > > > > > * include/bits/basic_string.h (operator+(const string&, > > > const char*)): > > > Remove naive implementation. > > > * include/bits/basic_string.tcc (operator+(const string&, > > > const char*)): > > > Add single-allocation implementation. > > > > ISTM this requires the following additional tweak: > > > > diff --git a/libstdc++-v3/src/c++11/string-inst.cc > > b/libstdc++-v3/src/c++11/string-inst.cc > > index bfae6d902a1dd..2ec0e9d85f947 100644 > > --- a/libstdc++-v3/src/c++11/string-inst.cc > > +++ b/libstdc++-v3/src/c++11/string-inst.cc > > @@ -58,6 +58,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > > > > template class basic_string<C>; > > template S operator+(const C*, const S&); > > + template S operator+(const S&, const C*); > > template S operator+(C, const S&); > > template S operator+(const S&, const S&); > > > > > > Without this, I'm getting undefined references to this specialization in > > libstdc++.so, that I tracked down to a std::system_error ctor in > > cxx11-ios_failure.o. I got this while testing another patch that might > > be the reason why the template instantiation doesn't get inlined, but... > > we can't depend on its being inlined, can we? > > Right. But adding that will cause another symbol to be exported, > probably with the wrong symbol version.
Oh, but those symbols aren't exported ... they're just needed because we compile with -fno-implicit-templatesand other symbols in libstdc++.so require them. So that probably is the right fix. I have another change for operator+ in mind now anyway, which optimizes operator(const string&, char) the same way, and removes the duplication in those five operator+ overloads. > > To fix https://gcc.gnu.org/PR106735 I'm just going to revert it for > now, and revisit in the morning.
