https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
--- Comment #6 from rguenther at suse dot de ---
On Tue, 19 Aug 2014, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
>
> --- Comment #5 from Marc Glisse ---
> (In reply to rguent...@suse.de from comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
--- Comment #5 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #4)
> Eventually worth "fixing" the libstdc++ side to generate better
> initial code?
Replacing memcpy(,,3)+assign(,'\0') with memcpy(,,4) can indeed be done at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
--- Comment #4 from rguenther at suse dot de ---
On Mon, 18 Aug 2014, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
>
> --- Comment #2 from Marc Glisse ---
> (In reply to Richard Biener from comment #1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
--- Comment #3 from Marc Glisse ---
Not much difference using __gnu_cxx::__vstring (no reference counting, small
string optimization):
__builtin_memcpy (&MEM[(struct __sso_string_base
*)&D.28720].D.23707._M_local_data, "foo", 3);
MEM[(size_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> What kind of std::string code is this? That is, can we expect
> memcmp and memcpy to be adjacent (without intermediate memory operations?)
I don't remember the e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|