public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "richard-gccbugzilla at metafoo dot co.uk" <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: Tue, 18 Apr 2023 02:15:47 +0000 [thread overview] Message-ID: <bug-109442-4-Bob7486Gbh@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 #16 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> --- (In reply to Richard Biener from comment #15) > I was specifically looking at C++20 7.6.2.7/10 to /14 (but maybe also > others and of course the relevant parts of the delete expression). In > particular the extra leeway the standard provides to new/delete _expressions_ > vs. calls of the global replaceable operators directly - do the > __builtin_operator_{new,delete} in this regard behave like new/delete > _expressions_ or like direct calls to the operators? They permit the same optimizations as new/delete expressions. The sections of the C++ standard that you referred to are what the documentation for the builtins means when it says: "[__builtin_operator_new] allows certain optimizations that the C++ standard does not permit for a direct function call to ::operator new (in particular, removing new / delete pairs and merging allocations)" > Do the builtins call one of the replaceable global new/delete operators > and thus users can reliably override them? If the implementation doesn't provide storage in some other way, optimize away the allocation, or merge it with another allocation, then yes, the storage is obtained by calling the corresponding replaceable global new/delete operators. Per the documentation: "A call to __builtin_operator_new(args) is exactly the same as a call to ::operator new(args), except that [text quoted above]" > How do the builtins behave during constexpr evaluation? new/delete > expressions have their behavior documented in the standard. They behave exactly like a direct call to the replaceable global allocation function. In Clang's implementation, direct calls to ::operator new and ::operator delete are permitted within calls to std::allocator<T>::allocate and std::allocator<T>::deallocate during constant evaluation, and are treated as allocating or deallocating arrays of T; consequently, calls to __builtin_operator_new and __builtin_operator_delete are permitted in the same contexts. In all other contexts, Clang rejects such calls, because the callee is not declared `constexpr`.
next prev parent reply other threads:[~2023-04-18 2:15 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 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 [this message] 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-Bob7486Gbh@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).