https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #18 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:78aed0ae5de801cc1e8220b214145300b28da562
commit r15-9050-g78aed0ae5de801cc1e8220b214145300b28da562
Author: Jakub Jelinek
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #17 from GCC Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:9c5505a35d9d71705464f9254f55407192d31ec3
commit r15-9047-g9c5505a35d9d71705464f9254f55407192d31ec3
Author: Jan Hubicka
Date: Sun M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #15 from Jan Hubicka ---
Original testcase is solved by
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671599.html
We still won't optimize longer strings because _M_create is not inline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #14 from Jan Hubicka ---
Declaring _S_create and _M_create inline indeed helps a little:
diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index 17b973c8b45..d73a61abe5b 100644
--- a/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #13 from Jan Hubicka ---
As discussed with Jason, problem with _M_create not seen by middle-end is
actually due to C++ standard. Explicit instantiations prevents implicit ones
for non-inline functions, see discussion in PR39242. With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #12 from Jan Hubicka ---
I think with my patch to basic_string we should have at least arrived to
something comparable with clang.
With -O2 it is optimized away,
with -O2 -D_GLIBCXX_USE_CXX11_ABI=0 I get:
int sain ()
{
struct alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
Sam James changed:
What|Removed |Added
Last reconfirmed|2022-01-07 00:00:00 |2024-11-27
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #10 from Marc Glisse ---
(In reply to AK from comment #9)
> can't repro this with gcc 12.1 Seems like this is fixed?
No. As stated in other comments, it still reproduces with a longer string (or
with -D_GLIBCXX_USE_CXX11_ABI=0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #9 from AK ---
can't repro this with gcc 12.1 Seems like this is fixed?
https://godbolt.org/z/e6n94zK4E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #8 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #7)
> With -std=c++20 -O2 I get better code than just -std=c++17 -O2:
> _34 = operator new (24);
> __builtin_memcpy (_34, "a ", 23);
> MEM[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #7 from Andrew Pinski ---
With -std=c++20 -O2 I get better code than just -std=c++17 -O2:
_34 = operator new (24);
__builtin_memcpy (_34, "a ", 23);
MEM[(char_type &)_34 + 23] = 0;
operator delete (_34, 24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-01-07
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
Bug 80331 depends on bug 23383, which changed state.
Bug 23383 Summary: builtin array operator new is not marked with malloc
attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
Andrew Pinski changed:
What|Removed |Added
Depends on||23383
--- Comment #4 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #3 from Marc Glisse ---
(In reply to Marc Glisse from comment #2)
> I didn't check if those are the only blockers in this case...
Looks like they are indeed the only blockers, since we optimize the below just
fine. So, known issue (w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #2 from Marc Glisse ---
If you replace "a" with something longer (size>16 when counting the last '\0'),
it does reproduce. I'd say this is a dup of 2 known issues:
- the compiled part of libstdc++ prevents optimization (maybe eventual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
19 matches
Mail list logo
