https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #8 from Andrew Pinski ---
(In reply to Marc Glisse from comment #3)
> (In reply to M Welinder from comment #2)
> > The destruction still stinks: the full destructor is inlined instead of
> > the small-string-only version (i.e., a no-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
Martin Liška changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #2 from M Welinder ---
Created attachment 44789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44789&action=edit
Proof-on-concept patch
This proof-of-concept improves the situation dramatically. I don't
know if it is actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #3 from Marc Glisse ---
(In reply to M Welinder from comment #2)
> The destruction still stinks: the full destructor is inlined instead of
> the small-string-only version (i.e., a no-op). Evidently gcc cannot
> see that the string re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
Martin Liška changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #5 from Andrew Pinski ---
The C++17 calling a function part of this issue is record as PR 86590 already.
The rest is a different issue and should be looked into.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #6 from M Welinder ---
> const_cast(s)="some longer string so it needs proper deletion";
Is that really valid?
This comes down to whether the temporary object creating with the function
call is constant [in which case the above is U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #7 from M Welinder ---
Actually, it's more like 50+ instructions for destructing the string that
never (or almost never) needs destructing. 16 of those appear to need
linker fixup.
Sample for the C++14 mode:
callZ3fo
