Re: [patch] New std::string implementation
Jonathan Wakely jwak...@redhat.com writes: The powerpc64 ICE is fixed, so I'm committing the std::string ABI transition patch. This replaces our venerable Copy-on-Write std::string with a C++11-conforming* Small-String Optimized std::__cxx11::string. (* It's not quite 100% conforming, as it's missing some allocator features. Of course. Always with the allocators. But that's only a small fix to make next week.) [...] Target maintainers will see a *lot* of new exports at the latest symbol version if they generate a new baseline-symbols.txt file. I suggest waiting and doing that nearer the end of stage 3 in case there are any fixes needed after this change. Bootstrapped and tested in various configurations on x86_64-linux and powerpc64-linux. Unfortunately, this patch broke Solaris bootstrap with /bin/ld: libstdc++.so fails to link with ld: fatal: libstdc++-symbols.ver-sun: 5383: symbol 'std::locale::name[abi:cxx11]() const': symbol version conflict l.5383 has ##_ZNKSt6locale4nameB5cxx11Ev (glob) _ZNKSt6locale4nameB5cxx11Ev; i.e. # std::locale::name() returning new std::string in GLIBCXX_3.4.21 vs. ##std::locale::[A-Zn-z]* (cxx) _ZNKSt6locale4nameB5cxx11Ev; in GLIBCXX_3.4. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch] New std::string implementation
On 06/01/15 10:52 +0100, Rainer Orth wrote:
Unfortunately, this patch broke Solaris bootstrap with /bin/ld:
libstdc++.so fails to link with
ld: fatal: libstdc++-symbols.ver-sun: 5383: symbol
'std::locale::name[abi:cxx11]() const': symbol version conflict
l.5383 has
##_ZNKSt6locale4nameB5cxx11Ev (glob)
_ZNKSt6locale4nameB5cxx11Ev;
i.e.
# std::locale::name() returning new std::string
in GLIBCXX_3.4.21 vs.
##std::locale::[A-Zn-z]* (cxx)
_ZNKSt6locale4nameB5cxx11Ev;
in GLIBCXX_3.4.
Drat, I even tried to avoid that conflict, but apparently I thought
the letter that comes after 'n' is 'n'!
Does this fix it?
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -118,7 +118,7 @@ GLIBCXX_3.4 {
# std::locale::name();
std::locale::none*;
std::locale::numeric*;
- std::locale::[A-Zn-z]*;
+ std::locale::[A-Zo-z]*;
std::locale::_[A-Ha-z]*;
std::locale::_Impl::[A-Za-z]*;
# std::locale::_Impl::_M_[A-Za-z]*;
Hmm, I think the [A-Zo-z] glob depends on the locale's collation
order, maybe it should be just [o-z] since we don't have any symbols
matching std::locale::[A-Z]* anyway. That's something else to clean up
later.
Re: [patch] New std::string implementation
Jonathan Wakely jwak...@redhat.com writes:
Drat, I even tried to avoid that conflict, but apparently I thought
the letter that comes after 'n' is 'n'!
Does this fix it?
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -118,7 +118,7 @@ GLIBCXX_3.4 {
# std::locale::name();
std::locale::none*;
std::locale::numeric*;
- std::locale::[A-Zn-z]*;
+ std::locale::[A-Zo-z]*;
std::locale::_[A-Ha-z]*;
std::locale::_Impl::[A-Za-z]*;
# std::locale::_Impl::_M_[A-Za-z]*;
it does indeed.
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch] New std::string implementation
On 06/01/15 13:29 +0100, Rainer Orth wrote:
Jonathan Wakely jwak...@redhat.com writes:
Drat, I even tried to avoid that conflict, but apparently I thought
the letter that comes after 'n' is 'n'!
Does this fix it?
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -118,7 +118,7 @@ GLIBCXX_3.4 {
# std::locale::name();
std::locale::none*;
std::locale::numeric*;
- std::locale::[A-Zn-z]*;
+ std::locale::[A-Zo-z]*;
std::locale::_[A-Ha-z]*;
std::locale::_Impl::[A-Za-z]*;
# std::locale::_Impl::_M_[A-Za-z]*;
it does indeed.
Thanks for checking it. Tested x86_64-linux and committed to trunk.
commit e25934d17d4bb1c06bd76e923569a00ad0e66a18
Author: Jonathan Wakely jwak...@redhat.com
Date: Tue Jan 6 11:03:31 2015 +
* config/abi/pre/gnu.ver: Fix version conflict for std::locale::name().
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index e680e99..7bb65e9 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -118,7 +118,7 @@ GLIBCXX_3.4 {
# std::locale::name();
std::locale::none*;
std::locale::numeric*;
- std::locale::[A-Zn-z]*;
+ std::locale::[A-Zo-z]*;
std::locale::_[A-Ha-z]*;
std::locale::_Impl::[A-Za-z]*;
# std::locale::_Impl::_M_[A-Za-z]*;
Re: [patch] New std::string implementation
Hello Jonathan,
starting with around r218964, New std::string implementation.
the following program does no longer link correctly:
cat test1.cc
#include string
int
main()
{
std::string x;
x.erase(x.begin(), x.end());
}
g++ test1.cc
/tmp/ccgup1FU.o: In function `main':
test1.cc:(.text+0x41): undefined reference to `std::__cxx11::basic_stringchar,
std::char_traitschar,
std::allocatorchar::erase(__gnu_cxx::__normal_iteratorchar*,
std::__cxx11::basic_stringchar, std::char_traitschar,
std::allocatorchar, __gnu_cxx::__normal_iteratorchar*,
std::__cxx11::basic_stringchar, std::char_traitschar,
std::allocatorchar)'
collect2: error: ld returned 1 exit status
This does however not happen at -O1 and above.
Any ideas?
Thanks,
Bernd.
Re: [patch] New std::string implementation
The powerpc64 ICE is fixed, so I'm committing the std::string ABI transition patch. This replaces our venerable Copy-on-Write std::string with a C++11-conforming* Small-String Optimized std::__cxx11::string. (* It's not quite 100% conforming, as it's missing some allocator features. Of course. Always with the allocators. But that's only a small fix to make next week.) Since the last version of this patch Jason has added support for attribute((abi_tag)) on namespaces, so the new types can be defined in an inline namespace that has the tag, rather than co-existing in namespace std with the un-tagged types. This makes overloading and exporting symbols a bit more straightforward as the different linkage names can be expressed with a fully-qualified name without needing the attribute. I've also added regex templates to the new __cxx11 namespace, as they depend on std::string. There are now two new configure options, --disable-libstdcxx-dual-abi and --with-default-libstdcxx-abi. The former disables all support for the new __cxx11 ABI pieces. The latter is only relevant when the dual ABI is enabled and can be used to make the old definitions the default ones you get without defining the _GLIBCXX_USE_CXX11_ABI macro. As described previously, the locale facets that depend on the std::string ABI exist twice as twinned facets and if users replace a twinned facet the library generates a shim to replace its twin. Also as described previously, the types in stdexcept continue to use the COW string, to ensure nothrow copying and ABI stability. The Python pretty printer problems I was seeing with the new string turned out to be a GDB bug (17728). Target maintainers will see a *lot* of new exports at the latest symbol version if they generate a new baseline-symbols.txt file. I suggest waiting and doing that nearer the end of stage 3 in case there are any fixes needed after this change. Bootstrapped and tested in various configurations on x86_64-linux and powerpc64-linux. Committed to trunk! Phew. patch.txt.bz2 Description: BZip2 compressed data
Re: [patch] New std::string implementation
Hello
Great news.
However we need the following to make debug/profile modes happy.
Shouldn't we use _GLIBCXX_ABI_TAG_CXX11 to tag the __cxx11 namespace ?
2014-12-20 François Dumont fdum...@gcc.gnu.org
* include/bits/c++config: inline __cxx11 namespace within namespace
__cxx1998.
Ok to commit ?
François
On 19/12/2014 19:23, Jonathan Wakely wrote:
The powerpc64 ICE is fixed, so I'm committing the std::string ABI
transition patch.
This replaces our venerable Copy-on-Write std::string with a
C++11-conforming* Small-String Optimized std::__cxx11::string.
(* It's not quite 100% conforming, as it's missing some allocator
features. Of course. Always with the allocators. But that's only a
small fix to make next week.)
Since the last version of this patch Jason has added support for
attribute((abi_tag)) on namespaces, so the new types can be defined in
an inline namespace that has the tag, rather than co-existing in
namespace std with the un-tagged types. This makes overloading and
exporting symbols a bit more straightforward as the different linkage
names can be expressed with a fully-qualified name without needing the
attribute.
I've also added regex templates to the new __cxx11 namespace, as they
depend on std::string.
There are now two new configure options, --disable-libstdcxx-dual-abi
and --with-default-libstdcxx-abi. The former disables all support for
the new __cxx11 ABI pieces. The latter is only relevant when the dual
ABI is enabled and can be used to make the old definitions the
default ones you get without defining the _GLIBCXX_USE_CXX11_ABI
macro.
As described previously, the locale facets that depend on the
std::string ABI exist twice as twinned facets and if users replace
a twinned facet the library generates a shim to replace its twin.
Also as described previously, the types in stdexcept continue to use
the COW string, to ensure nothrow copying and ABI stability.
The Python pretty printer problems I was seeing with the new string
turned out to be a GDB bug (17728).
Target maintainers will see a *lot* of new exports at the latest
symbol version if they generate a new baseline-symbols.txt file. I
suggest waiting and doing that nearer the end of stage 3 in case there
are any fixes needed after this change.
Bootstrapped and tested in various configurations on x86_64-linux and
powerpc64-linux.
Committed to trunk!
Phew.
Index: include/bits/c++config
===
--- include/bits/c++config (revision 218970)
+++ include/bits/c++config (working copy)
@@ -277,9 +277,13 @@
// Non-inline namespace for components replaced by alternates in active mode.
namespace __cxx1998
{
-#if _GLIBCXX_INLINE_VERSION
- inline namespace __7 { }
-#endif
+# if _GLIBCXX_INLINE_VERSION
+ inline namespace __7 { }
+# endif
+
+# if _GLIBCXX_USE_CXX11_ABI
+ inline namespace __cxx11 __attribute__((abi_tag)) { }
+# endif
}
// Inline namespace for debug mode.
Re: [patch] New std::string implementation
This fixes some duplicate symbols which break Darwin bootstrap. Tested x86_64-linux and powerpc64-linux, committed to trunk. commit fa3a5af2feee0f9873ba1a9bdb84148dd122506c Author: Jonathan Wakely jwak...@redhat.com Date: Fri Dec 19 23:44:01 2014 + Fix duplicate symbol errors in Darwin bootstrap. * src/c++98/locale-inst.cc (__add_grouping, __pad, __int_to_char): Only compile for old ABI. diff --git a/libstdc++-v3/src/c++98/locale-inst.cc b/libstdc++-v3/src/c++98/locale-inst.cc index dd47921..6cd3616 100644 --- a/libstdc++-v3/src/c++98/locale-inst.cc +++ b/libstdc++-v3/src/c++98/locale-inst.cc @@ -345,6 +345,7 @@ _GLIBCXX_END_NAMESPACE_CXX11 has_facetmessagesC (const locale); +#if ! _GLIBCXX_USE_CXX11_ABI // locale functions. template C* @@ -364,6 +365,7 @@ _GLIBCXX_END_NAMESPACE_CXX11 __int_to_char(C*, unsigned long long, const C*, ios_base::fmtflags, bool); #endif +#endif _GLIBCXX_END_NAMESPACE_VERSION } // namespace
Re: [patch] New std::string implementation
On 20/12/14 00:52 +0100, François Dumont wrote: Hello Great news. However we need the following to make debug/profile modes happy. Ah, thanks for checking it. Shouldn't we use _GLIBCXX_ABI_TAG_CXX11 to tag the __cxx11 namespace ? No, that is defined to __attribute__((abi_tag(cxx11))) but you don't need a string for the tag on namespaces, just __attribute__((abi_tag)) works (and it uses the namespace name as the tag name). 2014-12-20 François Dumont fdum...@gcc.gnu.org * include/bits/c++config: inline __cxx11 namespace within namespace __cxx1998. Ok to commit ? Yes, this fixes the default configuration, so OK for trunk. I'll test it for the alternative configurations tomorrow. Thanks!
Re: [patch] New std::string implementation
Here's the next version of the std::string rework, this time with
57.1428% more locale facets!
The problem is that there are several facet types that use std::string
in their public interfaces and as the parameters (or worse, as return
types) of virtual functions. It's not possible to overload the
functions to take either the old std::string or the new std::string
because that would add virtual functions to the vtable which is an ABI
change (and you can't overload on return type anyway). The facets are
used deep in the guts of locales and iostreams so need to remain
compatible.
My solution is to add a second version of each affected facet, with
one version using the old ABI and one using the new, but with
otherwise the same behaviour. When a piece of code says
std::use_facetstd::collatechar(someLocale) they get a reference to
the locale's std::collatechar facet with the same ABI as is in
effect at the call site.
The difficult part is that users can replace a facet to customise
behaviour, so if they replace the old ABI version of
std::collatechar I need to also replace the new ABI version of the
same facet, using a shim that has the same behaviour as the
user-defined facet (which is achieved by the shim just forwarding to
the user's facet, and converting between std::string representations).
I've also had to add a new virtual function to std::error_category so
you can call error_category::message() (which returns a std::string)
in the context of either ABI. Adding the virtual grows the size of the
vtable in a type that's been exported from libstdc++.so since 4.4.0 so
I moved std::error_category to src/c++11/compatibility-c++0x.cc and
added a new std::_V2::error_category in the same inline namespace used
for a similar switcheroo on std::condition_variable_any
With these changes the entire libstdc++ testsuite passes when using
either ABI, confirming that the library still exports everything
needed for existing code (compiled with GCC 5) to keep working, but
also contains everything for new code (GCC 5+) to work.
Tested x86_64-linux with:
--target_board=unix\{-m32,\}\{,-D_GLIBCXX_USE_CXX11_ABI=0\}
Also tested on powerpc64-linux (where this patch doesn't actually
bootstrap due to PR 63573, there's a patch in the PR that's needed)
and i686-linux.
The Python pretty printers for std::string fail with the new ABI. I'm
not sure why, I think GDB is failing to distinguish between the two
types of std::string. That will only require changes to the python
code though.
patch.txt.bz2
Description: BZip2 compressed data
Re: [patch] New std::string implementation
On 28/11/14 15:24 +, Jonathan Wakely wrote:
Tested x86_64-linux with:
--target_board=unix\{-m32,\}\{,-D_GLIBCXX_USE_CXX11_ABI=0\}
Also tested on powerpc64-linux (where this patch doesn't actually
bootstrap due to PR 63573, there's a patch in the PR that's needed)
and i686-linux.
Oh how silly, the attached patch is needed for powerpc. I had fixed
this once, but must have lost the change on the compile farm machine I
was using and then not committed the fix in my local repo. The
attached patch also includes the PR63573 fix which isn't committed
yet.
I've committed the libstdc++ parts (but not the PR fix) to my repo
now, so it won't get lost again.
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index d4864ae..dd8142e 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -1617,8 +1617,12 @@ remap_gimple_stmt (gimple stmt, copy_body_data *id)
/* Clear flags that need revisiting. */
if (gcall *call_stmt = dyn_cast gcall * (copy))
- if (gimple_call_tail_p (call_stmt))
- gimple_call_set_tail (call_stmt, false);
+ {
+ if (gimple_call_tail_p (call_stmt))
+ gimple_call_set_tail (call_stmt, false);
+ if (gimple_call_from_thunk_p (call_stmt))
+ gimple_call_set_from_thunk (call_stmt, false);
+ }
/* Remap the region numbers for __builtin_eh_{pointer,filter},
RESX and EH_DISPATCH. */
diff --git a/libstdc++-v3/include/bits/locale_facets.h
b/libstdc++-v3/include/bits/locale_facets.h
index e8f9e67..77838b0 100644
--- a/libstdc++-v3/include/bits/locale_facets.h
+++ b/libstdc++-v3/include/bits/locale_facets.h
@@ -2216,8 +2216,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
double) const;
// XXX GLIBCXX_ABI Deprecated
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__ \
- _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__
virtual iter_type
__do_get(iter_type, iter_type, ios_base, ios_base::iostate,
double) const;
@@ -2231,8 +2230,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
do_get(iter_type, iter_type, ios_base, ios_base::iostate, void*)
const;
// XXX GLIBCXX_ABI Deprecated
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__ \
- _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__
virtual iter_type
do_get(iter_type, iter_type, ios_base, ios_base::iostate,
long double) const;
@@ -2501,8 +2499,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
do_put(iter_type, ios_base, char_type, double) const;
// XXX GLIBCXX_ABI Deprecated
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__ \
- _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__
virtual iter_type
__do_put(iter_type, ios_base, char_type, double) const;
#else
@@ -2514,8 +2511,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
do_put(iter_type, ios_base, char_type, const void*) const;
// XXX GLIBCXX_ABI Deprecated
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__ \
- _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__
virtual iter_type
do_put(iter_type, ios_base, char_type, long double) const;
#endif
diff --git a/libstdc++-v3/include/bits/locale_facets.tcc
b/libstdc++-v3/include/bits/locale_facets.tcc
index 23e87d0..306d3a6 100644
--- a/libstdc++-v3/include/bits/locale_facets.tcc
+++ b/libstdc++-v3/include/bits/locale_facets.tcc
@@ -712,8 +712,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
return __beg;
}
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__ \
- _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__
templatetypename _CharT, typename _InIter
_InIter
num_get_CharT, _InIter::
@@ -1156,8 +1155,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
do_put(iter_type __s, ios_base __io, char_type __fill, double __v) const
{ return _M_insert_float(__s, __io, __fill, char(), __v); }
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__ \
- _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT defined __LONG_DOUBLE_128__
templatetypename _CharT, typename _OutIter
_OutIter
num_put_CharT, _OutIter::
Re: [patch] New std::string implementation
On Mon, Nov 17, 2014 at 5:43 PM, Jonathan Wakely jwak...@redhat.com wrote: On 17/11/14 13:06 +0100, Markus Trippelsdorf wrote: On 2014.11.14 at 15:43 +, Jonathan Wakely wrote: Tested on x86_64-linux and powerpc64-linux, also with --disable-libstdcxx11-abi to verify all the incompatible changes can be disabled if needed. On ppc64 I get: FAIL: libstdc++-abi/abi_check FAIL: 27_io/basic_ios/copyfmt/char/1.cc execution test FAIL: 27_io/basic_ios/exceptions/char/1.cc execution test FAIL: 27_io/basic_istream/extractors_arithmetic/char/exceptions_failbit.cc execution test FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/exceptions_failbit.cc execution test FAIL: 27_io/basic_istream/extractors_other/char/exceptions_null.cc execution test FAIL: 27_io/basic_istream/extractors_other/wchar_t/exceptions_null.cc execution test FAIL: 27_io/basic_istream/sentry/char/12297.cc execution test FAIL: 27_io/basic_istream/sentry/wchar_t/12297.cc execution test FAIL: 27_io/basic_ostream/inserters_other/char/exceptions_null.cc execution test FAIL: 27_io/basic_ostream/inserters_other/wchar_t/exceptions_null.cc execution test FAIL: 27_io/ios_base/storage/2.cc execution test I think I've fixed those, I'll post an updated patch soon, but I'm still working on some fixes for 22_locale/ test FAILs. The problem I have is that std::basic_iosC, T objects (the base class of all iostreams) have a pointer to an instance of std::num_getC, istreambuf_iteratorC, T and that type uses std::string, so needs to be tagged, which would require the entire iostreams hierarchy to be tagged. I want to avoid that. Updated patch with fixes asap ... Looking at all these issues that just pop up inside libstdc++ I wonder if this whole business will not blow up in our face once out in the wild... Richard.
Re: [patch] New std::string implementation
On 18/11/14 10:45 +0100, Richard Biener wrote: Looking at all these issues that just pop up inside libstdc++ I wonder if this whole business will not blow up in our face once out in the wild... I'm trying to ensure that most of the the pain is dealt with inside libstdc++ and so users won't have the same kind of issues. I've got to the point where everything works except programs which use custom facets. If you create a custom locale with a user-defined facet in a translation unit that uses the new ABI and imbue an iostream with that locale, your user-defined facet will not be used, because the iostream definitions are instantiated in the library using the old ABI. I've never met anyone who uses custom facets, but that doesn't mean it's OK for them to not work properly using the new ABI. So if I add dg-options -D_GLIBCXX_USE_CXX11_ABI to the last 40 tests that are failing, everything passes. Maybe that's what I should do for now.
Re: [patch] New std::string implementation
On 14/11/14 15:43 +, Jonathan Wakely wrote:
This is the long-awaited ABI break for std::string, replacing our
venerable Copy-On-Write implementation with a C++11-conforming
Small-String-Optimization implementation (based on Paolo's vstring).
This patch fixes move construction and assignment in sstream.
I'm still trying to fix the locale facet instantiations.
diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index 66560d2..ebcc462 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -471,7 +471,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_capacity(__str._M_allocated_capacity);
}
- _M_set_length(__str.length());
+ // Must use _M_length() here not _M_set_length() because
+ // basic_stringbuf relies on writing into unallocated capacity so
+ // we mess up the contents if we put a '\0' in the string.
+ _M_length(__str.length());
__str._M_data(__str._M_local_data());
__str._M_set_length(0);
}
diff --git a/libstdc++-v3/include/std/sstream b/libstdc++-v3/include/std/sstream
index be44dae..1940ddd 100644
--- a/libstdc++-v3/include/std/sstream
+++ b/libstdc++-v3/include/std/sstream
@@ -64,6 +64,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
class _GLIBCXX_DEFAULT_ABI_TAG basic_stringbuf
: public basic_streambuf_CharT, _Traits
{
+ struct __xfer_bufptrs;
public:
// Types:
typedef _CharT char_type;
@@ -118,9 +119,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
basic_stringbuf(const basic_stringbuf) = delete;
basic_stringbuf(basic_stringbuf __rhs)
- : __streambuf_type(static_castconst __streambuf_type(__rhs)),
- _M_mode(__rhs._M_mode), _M_string(std::move(__rhs._M_string))
- { __rhs._M_stringbuf_init(__rhs._M_mode); }
+ : basic_stringbuf(std::move(__rhs), __xfer_bufptrs(__rhs, this))
+ { __rhs._M_sync(const_castchar_type*(__rhs._M_string.data()), 0, 0); }
// 27.8.2.2 Assign and swap:
@@ -130,18 +130,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
basic_stringbuf
operator=(basic_stringbuf __rhs)
{
+ __xfer_bufptrs __st{__rhs, this};
const __streambuf_type __base = __rhs;
__streambuf_type::operator=(__base);
this-pubimbue(__rhs.getloc());
_M_mode = __rhs._M_mode;
_M_string = std::move(__rhs._M_string);
- __rhs._M_stringbuf_init(__rhs._M_mode);
+ __rhs._M_sync(const_castchar_type*(__rhs._M_string.data()), 0, 0);
return *this;
}
void
swap(basic_stringbuf __rhs)
{
+ __xfer_bufptrs __l_st{*this, std::__addressof(__rhs)};
+ __xfer_bufptrs __r_st{__rhs, this};
__streambuf_type __base = __rhs;
__streambuf_type::swap(__base);
__rhs.pubimbue(this-pubimbue(__rhs.getloc()));
@@ -288,6 +291,60 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// interface of basic_streambuf, taking just an int.
void
_M_pbump(char_type* __pbeg, char_type* __pend, off_type __off);
+
+private:
+#if __cplusplus = 201103L
+#if _GLIBCXX_USE_CXX11_ABI
+ // This type captures the state of the gptr / pptr pointers as offsets
+ // so they can be restored in another object after moving the string.
+ struct __xfer_bufptrs
+ {
+ __xfer_bufptrs(const basic_stringbuf __from, basic_stringbuf* __to)
+ : _M_to{__to}, _M_goff{-1, -1, -1}, _M_poff{-1, -1, -1}
+ {
+ const _CharT* __str = __from._M_string.data();
+ if (__from.eback())
+ {
+ _M_goff[0] = __from.eback() - __str;
+ _M_goff[1] = __from.gptr() - __str;
+ _M_goff[2] = __from.egptr() - __str;
+ }
+ if (__from.pbase())
+ {
+ _M_poff[0] = __from.pbase() - __str;
+ _M_poff[1] = __from.pptr() - __from.pbase();
+ _M_poff[2] = __from.epptr() - __str;
+ }
+ }
+
+ ~__xfer_bufptrs()
+ {
+ char_type* __str = const_castchar_type*(_M_to-_M_string.data());
+ if (_M_goff[0] != -1)
+ _M_to-setg(__str+_M_goff[0], __str+_M_goff[1], __str+_M_goff[2]);
+ if (_M_poff[0] != -1)
+ _M_to-_M_pbump(__str+_M_poff[0], __str+_M_poff[2], _M_poff[1]);
+ }
+
+ basic_stringbuf* _M_to;
+ off_type _M_goff[3];
+ off_type _M_poff[3];
+ };
+#else
+ // This type does nothing when using Copy-On-Write strings.
+ struct __xfer_bufptrs
+ {
+ __xfer_bufptrs(const basic_stringbuf, basic_stringbuf*) { }
+ };
+#endif
+
+ // The move constructor initializes an __xfer_bufptrs temporary then
+ // delegates to this constructor to performs moves during its lifetime.
+ basic_stringbuf(basic_stringbuf __rhs, __xfer_bufptrs)
+ : __streambuf_type(static_castconst __streambuf_type(__rhs)),
+ _M_mode(__rhs._M_mode),
Re: [patch] New std::string implementation
On 2014.11.14 at 15:43 +, Jonathan Wakely wrote: Tested on x86_64-linux and powerpc64-linux, also with --disable-libstdcxx11-abi to verify all the incompatible changes can be disabled if needed. On ppc64 I get: FAIL: libstdc++-abi/abi_check FAIL: 27_io/basic_ios/copyfmt/char/1.cc execution test FAIL: 27_io/basic_ios/exceptions/char/1.cc execution test FAIL: 27_io/basic_istream/extractors_arithmetic/char/exceptions_failbit.cc execution test FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/exceptions_failbit.cc execution test FAIL: 27_io/basic_istream/extractors_other/char/exceptions_null.cc execution test FAIL: 27_io/basic_istream/extractors_other/wchar_t/exceptions_null.cc execution test FAIL: 27_io/basic_istream/sentry/char/12297.cc execution test FAIL: 27_io/basic_istream/sentry/wchar_t/12297.cc execution test FAIL: 27_io/basic_ostream/inserters_other/char/exceptions_null.cc execution test FAIL: 27_io/basic_ostream/inserters_other/wchar_t/exceptions_null.cc execution test FAIL: 27_io/ios_base/storage/2.cc execution test -- Markus
Re: [patch] New std::string implementation
On 17/11/14 13:06 +0100, Markus Trippelsdorf wrote: On 2014.11.14 at 15:43 +, Jonathan Wakely wrote: Tested on x86_64-linux and powerpc64-linux, also with --disable-libstdcxx11-abi to verify all the incompatible changes can be disabled if needed. On ppc64 I get: FAIL: libstdc++-abi/abi_check FAIL: 27_io/basic_ios/copyfmt/char/1.cc execution test FAIL: 27_io/basic_ios/exceptions/char/1.cc execution test FAIL: 27_io/basic_istream/extractors_arithmetic/char/exceptions_failbit.cc execution test FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/exceptions_failbit.cc execution test FAIL: 27_io/basic_istream/extractors_other/char/exceptions_null.cc execution test FAIL: 27_io/basic_istream/extractors_other/wchar_t/exceptions_null.cc execution test FAIL: 27_io/basic_istream/sentry/char/12297.cc execution test FAIL: 27_io/basic_istream/sentry/wchar_t/12297.cc execution test FAIL: 27_io/basic_ostream/inserters_other/char/exceptions_null.cc execution test FAIL: 27_io/basic_ostream/inserters_other/wchar_t/exceptions_null.cc execution test FAIL: 27_io/ios_base/storage/2.cc execution test I think I've fixed those, I'll post an updated patch soon, but I'm still working on some fixes for 22_locale/ test FAILs. The problem I have is that std::basic_iosC, T objects (the base class of all iostreams) have a pointer to an instance of std::num_getC, istreambuf_iteratorC, T and that type uses std::string, so needs to be tagged, which would require the entire iostreams hierarchy to be tagged. I want to avoid that. Updated patch with fixes asap ...
[patch] New std::string implementation
This is the long-awaited ABI break for std::string, replacing our venerable Copy-On-Write implementation with a C++11-conforming Small-String-Optimization implementation (based on Paolo's vstring). The gist of it is adding a second complete std::string implementation that is tagged with abi_tag(cxx11) so it mangles differently (as already done for std::list and std::ios_base::failure). Because strings are used pervasively through the library loads of functions need to be compiled twice, using the old and new string, so that both versions are exported from the library. That involved loads of shuffling things around within the libstdc++-v3/src directory so the right definitions could be included twice by different files and compiled with the right -std option and the right value of the _GLIBCXX_USE_CXX11_ABI macro. The stringstream classes are so tightly coupled to std::string that I just added the tag to them as well. The exception to the compile it twice rule are (fittingly) the exception classes. Because exceptions cross function/API/library boundaries without being visible to the linker simply adding the abi_tag to the exception types would have caused runtime failures where one module throws an old std::runtime_error and the code trying to catch it only handles the new std::runtime_error[abi:cxx11] type. So in order to avoid changing the exception types I have devised a horrible hack where the exception classes always use the old COW std::string type, even when the rest of the program doesn't. This is done by ensuring all constructing/copying/destroying of the exception classes is done in a context where the old std::string ABI is in effect. In practice that means the relevant functions are non-inline and exported from the library. This patch doesn't include all the testsuite fixes, which I'll send separately. We have lots of tests for features that are true for COW strings but not SSO strings so they need adjusting. There are also some failures in 22_locale and 28_regex which I'm investigating (with all the duplicated symbols and shuffling of code in the locale instantiations I'm amazed there arren't more failures!) This change *doesn't* resolve PRs 54354 and 60396, they require abi-tagging the time_get facet and ensuring that std::locale objects contain both the old and new time_get facets. That will require even more black magic than is usually involved with std::locale changes, but I still hope to have it done before stage 1 ends, if I can fix the testsuite problems I'm seeing now. Tested on x86_64-linux and powerpc64-linux, also with --disable-libstdcxx11-abi to verify all the incompatible changes can be disabled if needed. I plan to commit this today or tomorrow, but I'll check with Jakub and Richi if they'd prefer I wait until Sunday morning, to avoid causing massive churn for everyone else trying to get things in before stage 1 ends. patch.txt.gz Description: application/gzip
Re: [patch] New std::string implementation
Some (very small) questions / cleanups 1) Do you plan on supporting CXX11 ABI on C++03? There is some #if __cplusplus 201103L inside the new basic_string. 2) Is there a need for the #if 0 _M_mutate? I tried bootstrapping on Mac OS X 10.10, and got lots of linking issues, the relevant part is:: /bin/sh ../libtool --tag CXX --mode=link /Users/caj/progs/gcc/gcc-bin/./gcc/xgcc -shared-libgcc -B/Users/caj/progs/gcc/gcc-bin/./gcc -nostdinc++ -L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src -L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -B/gccbin/x86_64-apple-darwin14.0.0/bin/ -B/gccbin/x86_64-apple-darwin14.0.0/lib/ -isystem /gccbin/x86_64-apple-darwin14.0.0/include -isystem /gccbin/x86_64-apple-darwin14.0.0/sys-include -Wl,-single_module -fno-common -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:21:0 -Wl,-exported_symbols_list,libstdc++-symbols.explist -lm -rpath /gccbin/lib compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo compatibility-c++0x.lo compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la libtool: link: /Users/caj/progs/gcc/gcc-bin/./gcc/xgcc -shared-libgcc -B/Users/caj/progs/gcc/gcc-bin/./gcc -nostdinc++ -L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src -L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -B/gccbin/x86_64-apple-darwin14.0.0/bin/ -B/gccbin/x86_64-apple-darwin14.0.0/lib/ -isystem /gccbin/x86_64-apple-darwin14.0.0/include -isystem /gccbin/x86_64-apple-darwin14.0.0/sys-include-dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libstdc++.6.dylib .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,-force_load,../libsupc++/.libs/libsupc++convenience.a -Wl,-force_load,../src/c++98/.libs/libc++98convenience.a -Wl,-force_load,../src/c++11/.libs/libc++11convenience.a -L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src -L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -lm -Wl,-single_module -Wl,-exported_symbols_list -Wl,libstdc++-symbols.explist -install_name /gccbin/lib/libstdc++.6.dylib -compatibility_version 7 -current_version 7.21 -Wl,-single_module ld: warning: cannot export hidden symbol __cxxabiv1::__pbase_type_info::__pointer_catch(__cxxabiv1::__pbase_type_info const*, void**, unsigned int) const from ../libsupc++/.libs/libsupc++convenience.a(pbase_type_info.o) ld: warning: cannot export hidden symbol std::basic_stringbuf[abi:cxx11]char, std::char_traitschar, std::allocatorchar ::~cxx11() from ../src/c++98/.libs/libc++98convenience.a(complex_io.o) ld: warning: cannot export hidden symbol std::basic_stringbuf[abi:cxx11]wchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::~cxx11() from ../src/c++98/.libs/libc++98convenience.a(complex_io.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_istreamchar, std::char_traitschar -in-std::istrstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_ostreamchar, std::char_traitschar -in-std::ostrstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) duplicate symbol std::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::showmanyc() in: ../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o) ../src/c++11/.libs/libc++11convenience.a(cow-string-inst.o) duplicate symbol std::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::underflow() in: ../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o) ../src/c++11/.libs/libc++11convenience.a(cow-string-inst.o) duplicate symbol std::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::pbackfail(int) in: ../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o) ../src/c++11/.libs/libc++11convenience.a(cow-string-inst.o) duplicate symbol std::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode) in: ../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o) ../src/c++11/.libs/libc++11convenience.a(cow-string-inst.o) duplicate
Re: [patch] New std::string implementation
On 14/11/14 16:32 +, Christopher Jefferson wrote: Some (very small) questions / cleanups 1) Do you plan on supporting CXX11 ABI on C++03? There is some #if __cplusplus 201103L inside the new basic_string. Yes, the intention is that you get the same std::string implementation independent of the -std option you use, so that C++03 and C++11 code is compatible and can be linked together. So although the tag is named cxx11 that refers to the fact that this ABI change is required for C++11 conformance, not that it only applies to code compiled with -std=c++11 or -std=gnu++11. 2) Is there a need for the #if 0 _M_mutate? Oops, no, I meant to take that out. I'll do it before committing. I tried bootstrapping on Mac OS X 10.10, and got lots of linking issues, the relevant part is:: I might be missing some of the new instantiations, I'll look into that. Thanks for checking it!
Re: [patch] New std::string implementation
On 14/11/14 16:42 +, Jonathan Wakely wrote: On 14/11/14 16:32 +, Christopher Jefferson wrote: I tried bootstrapping on Mac OS X 10.10, and got lots of linking issues, the relevant part is:: I might be missing some of the new instantiations, I'll look into that. I am missing some instantiations, but that linker error is fixed by this change: --- a/libstdc++-v3/src/c++11/cow-string-inst.cc +++ b/libstdc++-v3/src/c++11/cow-string-inst.cc @@ -29,8 +29,6 @@ #define _GLIBCXX_USE_CXX11_ABI 0 #include string-inst.cc -#include sstream-inst.cc - #include ostream #include ../c++98/istream-string.cc Thie missing ones are due to the fact that insert/erase/replace etc. take iterator arguments in C++03 and const_iterator in C++11, so the explicit instantiations in src/c++11/string-inst.cc only generate the const_iterator form. I'm not sure whether to add explicit instantiations for the other forms, or just say the arguments are always const_iterator even in C++03 mode.
Re: [patch] New std::string implementation
On 14/11/14 16:51 +, Jonathan Wakely wrote: On 14/11/14 16:42 +, Jonathan Wakely wrote: On 14/11/14 16:32 +, Christopher Jefferson wrote: I tried bootstrapping on Mac OS X 10.10, and got lots of linking issues, the relevant part is:: I might be missing some of the new instantiations, I'll look into that. I am missing some instantiations Ugh! and to provide them I have to tag almost every locale facet, because they have std::string return values on virtual functions. I thought the locale bits I had left to do were quite limited, but it's not at all.
