https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #16 from Jan Hubicka ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671599.html
optimizes the string constructors. Having strlen pass catching more cases
would be nice, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #15 from Jakub Jelinek ---
Note, while strlen pass has laststmt and some handling of it for the other
direction, shrinking of the memcpy etc. size if the nul byte is being
immediately overwritten, it is actually tree DSE which optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #14 from Jan Hubicka ---
> > So I think all we can hope for is merging memcpy with the extra write of 0.
>
> That's not actually clear.
>
> It would be reasonable to assume that foo isn't likely to change the string
> and have the i
> > So I think all we can hope for is merging memcpy with the extra write of 0.
>
> That's not actually clear.
>
> It would be reasonable to assume that foo isn't likely to change the string
> and have the inlined destructor for a string that was initialized as a short
> string like here do somet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #13 from M Welinder ---
> The reason why full destructor is inlined is that we do not know what
> foo is doing and it may make the string bigger. "const" does not promise
> that the callee does not modify the object.
:-(
> So I th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #12 from Jan Hubicka ---
> (In reply to Jakub Jelinek from comment #10)
> > __builtin_memcpy (&D.35539.D.25336._M_local_buf, "abc", 3);
> > MEM[(char_type &)&D.35539 + 11] = 0;
> > change to
> > __builtin_memcpy (&D.35539.D.2533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #10 from Jakub Jelinek ---
__builtin_memcpy (&D.35539.D.25336._M_local_buf, "abc", 3);
MEM[(char_type &)&D.35539 + 11] = 0;
change to
__builtin_memcpy (&D.35539.D.25336._M_local_buf, "abc", 4);
seems like something that the strl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Ever confir
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
--- 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
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 #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
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 #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
--- 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
Martin Liška changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
17 matches
Mail list logo
