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 c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
Date: Mon, 20 Apr 2020 14:23:33 +0000 [thread overview]
Message-ID: <bug-94671-4-KVybU5wzlT@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-94671-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Bas Vodde from comment #4)
> When an operator new gets optimized by the compiler, the framework can't
> keep track of the accounting information and the delete call will report
> that non-allocated memory was deleted.
Obviously memory that wasn't returned from your replacement operator new can't
be passed to your replacement operator delete. If calls to operator new are
combined into fewer calls, or elided completely, then the compiler is also
responsible for combining/eliding the corresponding calls to operator delete.
Read the proposal referenced in the Clang bug you linked to:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3433.html
I don't see any bug with current GCC 10.0.1 snapshots. If I provide a
replacement operator delete then it is only called once, with a pointer that
was returned by the single call to operator new.
next prev parent reply other threads:[~2020-04-20 14:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-20 13:03 [Bug c++/94671] New: " basv@odd-e.com
2020-04-20 13:12 ` [Bug c++/94671] " redi at gcc dot gnu.org
2020-04-20 13:15 ` basv@odd-e.com
2020-04-20 13:17 ` rguenth at gcc dot gnu.org
2020-04-20 13:25 ` basv@odd-e.com
2020-04-20 13:31 ` basv@odd-e.com
2020-04-20 13:36 ` jakub at gcc dot gnu.org
2020-04-20 13:55 ` redi at gcc dot gnu.org
2020-04-20 14:23 ` redi at gcc dot gnu.org [this message]
2020-04-21 0:40 ` basv@odd-e.com
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-94671-4-KVybU5wzlT@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).