public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/109442] Dead local copy of std::vector not removed from function Date: Wed, 12 Apr 2023 10:29:41 +0000 [thread overview] Message-ID: <bug-109442-4-wjtLI9QXvS@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-109442-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442 --- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Richard Biener from comment #9) > Yep, looking at that link this is exactly what would be needed. Note > that in the middle-end we already see the calls to > DECL_IS_REPLACEABLE_OPERATOR_NEW_P and replaceable operator delete. We > just restrict all optimizations to calls emitted from new/delete expressions. > I'm not sure the clang builtin is exactly providing the new/delete > expression semantics resolving to replaceable operator new/delete or if > there's other details. That is, I'm curious whether __builtin_operator_new > provides more guarantees than a new/delete expression - the builtin semantics > isn't very well defined unfortunately. It might be safer to go our own > way here. I would prefer if we don't deviate, and get Clang to clarify things instead of reinventing something that looks similar but isn't. > I suppose the standard library could as well use malloc/free? No. std::allocator is required to use operator new and operator delete to obtain memory, but it's unspecified when or how often it calls them. So it's OK to call them once at startup to obtain ALL THE MEMORY that any std::allocator will ever need for the duration of the program, or to merge allocations, or to elide them completely. But it's not OK to use malloc. std::allocator::allocate says: "The storage for the array is obtained by calling ::operator new (17.6.3), but it is unspecified when or how often this function is called."
next prev parent reply other threads:[~2023-04-12 10:29 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-06 19:00 [Bug tree-optimization/109442] New: " hiraditya at msn dot com 2023-04-11 13:28 ` [Bug tree-optimization/109442] " rguenth at gcc dot gnu.org 2023-04-11 13:33 ` redi at gcc dot gnu.org 2023-04-11 13:38 ` redi at gcc dot gnu.org 2023-04-12 7:40 ` [Bug libstdc++/109442] " rguenth at gcc dot gnu.org 2023-04-12 9:29 ` redi at gcc dot gnu.org 2023-04-12 9:45 ` rguenth at gcc dot gnu.org 2023-04-12 10:01 ` redi at gcc dot gnu.org 2023-04-12 10:13 ` redi at gcc dot gnu.org 2023-04-12 10:22 ` rguenth at gcc dot gnu.org 2023-04-12 10:29 ` redi at gcc dot gnu.org [this message] 2023-04-12 10:35 ` redi at gcc dot gnu.org 2023-04-12 11:52 ` rguenther at suse dot de 2023-04-12 11:55 ` redi at gcc dot gnu.org 2023-04-16 18:38 ` richard-gccbugzilla at metafoo dot co.uk 2023-04-17 6:49 ` rguenth at gcc dot gnu.org 2023-04-18 2:15 ` richard-gccbugzilla at metafoo dot co.uk 2023-06-15 18:38 ` hiraditya at msn dot com 2024-05-11 0:07 ` xry111 at gcc dot gnu.org 2024-05-11 16:05 ` hubicka at gcc dot gnu.org 2024-05-14 13:47 ` Jan Hubicka 2024-05-11 16:44 ` redi at gcc dot gnu.org 2024-05-14 13:47 ` hubicka at ucw dot cz
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-109442-4-wjtLI9QXvS@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: linkBe 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).