public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/105838] [10/11/12/13 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings
Date: Mon, 05 Dec 2022 18:30:45 +0000 [thread overview]
Message-ID: <bug-105838-4-RUFRkvZAs5@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-105838-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #10)
> A lot of the problem here is that building a std::string involves building a
> std::allocator<char> temporary to pass to the string constructor, and then
> we need to wait until the entire array is built before we can destroy any of
> them: https://eel.is/c++draft/class.temporary#5 says we can only destroy
> temporaries early if there was no initializer for that array element. So
> for each element of the initializer we have another EH region for its
> allocator temporary.
>
> We could do better for the general case by creating a parallel array of
> temporaries and using the same single cleanup region for it as for the array
> of strings. This seems like a worthwhile general optimization.
>
> We might be able to do better for the specific case by recognizing that
> std::allocator has no data and nothing cares about its address, so we can go
> ahead and destroy it after initializing the string, and reuse the stack
> slot. This also saves stack space.
Even if we don't emit a loop (which I still think is the way to go for larger
initializers because anything else means just too large code), can't there for
the larger initializers simply be some variable holding a counter how many
initializers have been already initialized and a single EH region that will
perform all the cleanups based on that counter?
next prev parent reply other threads:[~2022-12-05 18:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 16:22 [Bug c++/105838] New: " eisjmbjdfcukqlaely at nthrl dot com
2022-06-13 12:47 ` [Bug c++/105838] " rguenth at gcc dot gnu.org
2022-06-13 12:52 ` rguenth at gcc dot gnu.org
2022-06-14 11:56 ` rguenth at gcc dot gnu.org
2022-06-14 13:10 ` [Bug c++/105838] [10/11/12/13 Regression] " rguenth at gcc dot gnu.org
2022-06-14 13:11 ` rguenth at gcc dot gnu.org
2022-06-14 13:37 ` jakub at gcc dot gnu.org
2022-06-28 10:49 ` jakub at gcc dot gnu.org
2022-07-10 20:39 ` pinskia at gcc dot gnu.org
2022-07-11 15:43 ` luydorarko at vusra dot com
2022-12-05 17:57 ` jason at gcc dot gnu.org
2022-12-05 18:30 ` jakub at gcc dot gnu.org [this message]
2022-12-05 20:50 ` jason at gcc dot gnu.org
2022-12-05 20:58 ` jason at gcc dot gnu.org
2022-12-05 22:27 ` redi at gcc dot gnu.org
2022-12-05 22:34 ` jakub at gcc dot gnu.org
2022-12-05 23:57 ` jason at gcc dot gnu.org
2022-12-08 18:34 ` cvs-commit at gcc dot gnu.org
2022-12-08 18:41 ` cvs-commit at gcc dot gnu.org
2022-12-08 18:45 ` cvs-commit at gcc dot gnu.org
2022-12-15 5:26 ` cvs-commit at gcc dot gnu.org
2023-01-09 22:41 ` cvs-commit at gcc dot gnu.org
2023-06-02 15:01 ` [Bug c++/105838] [10/11/12/13/14 " cvs-commit at gcc dot gnu.org
2023-06-12 8:57 ` [Bug c++/105838] [10/11/12 " cvs-commit at gcc dot gnu.org
2023-07-07 10:43 ` [Bug c++/105838] [11/12 " rguenth at gcc dot gnu.org
2023-08-19 9:22 ` fxcoudert at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-105838-4-RUFRkvZAs5@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).