public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/103993] -Wismatched-new-delete due to difference in inlining decisions Date: Wed, 12 Jan 2022 18:31:02 +0000 [thread overview] Message-ID: <bug-103993-4-BtB66ls2QF@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103993-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103993 Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |100406 CC| |msebor at gcc dot gnu.org See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=100861 Summary|Incorrect error generated |-Wismatched-new-delete due |by mismatched-new-delete |to difference in inlining | |decisions Keywords| |diagnostic Component|c++ |middle-end --- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> --- The reported mismatch is between void operator delete [](void*) and void* ACE_Svc_Handler<PEER_STREAM, SYNCH_TRAITS>::operator new(size_t) i.e., the array form of the global operator delete is being called on the result of a scalar member operator new. The deallocation function corresponding to a member array new is a member array delete, so the warning isn't incorrect per se. The warning is based on the compiler's view of the optimized code, after inlining and other transformations. If the program provides overloads of operators new and delete for some type and GCC inlines a call to one but not the other, the warning will trigger because it sees a mismatch. To avoid this problem either prevent the inlining of both the allocation and the deallocation function (using attribute noinline), or force both to be inlined (by declaring them inline and attribute always_inline). The diff below shows the latter solution. It's possible for GCC do the former automatically (and it does that for a subset of these cases) but given it's not without a performance cost it seems preferable to leave the choice up to the programmer. Another approach was suggested in pr101829. See also pr100861 for a discussions of another similar issue. (When reporting a problem it's helpful to explain why you think it's in GCC rather than in the submitted test case so we don't have to guess.) $ diff -u JSimpleProcess.C JSimpleProcess-fix.C --- JSimpleProcess.C 2022-01-12 11:06:52.787461649 -0700 +++ JSimpleProcess-fix.C 2022-01-12 11:18:30.085356124 -0700 @@ -78365,7 +78365,8 @@ ; return; } -template <typename PEER_STREAM, typename SYNCH_TRAITS> void * +template <typename PEER_STREAM, typename SYNCH_TRAITS> +inline __attribute__ ((always_inline)) void * ACE_Svc_Handler<PEER_STREAM, SYNCH_TRAITS>::operator new (size_t n) { ; @@ -78378,10 +78379,11 @@ else { dynamic_instance->set (); - return ::new char[n]; + return ::operator new (n); } } -template <typename PEER_STREAM, typename SYNCH_TRAITS> void * +template <typename PEER_STREAM, typename SYNCH_TRAITS> +inline __attribute__ ((always_inline)) void * ACE_Svc_Handler<PEER_STREAM, SYNCH_TRAITS>::operator new (size_t n, const ::std::nothrow_t&) throw() { @@ -78395,15 +78397,16 @@ else { dynamic_instance->set (); - return ::new(::std::nothrow) char[n]; + return ::operator new(n, ::std::nothrow); } } -template <typename PEER_STREAM, typename SYNCH_TRAITS> void +template <typename PEER_STREAM, typename SYNCH_TRAITS> +inline __attribute__ ((always_inline)) void ACE_Svc_Handler<PEER_STREAM, SYNCH_TRAITS>::operator delete (void *p, const ::std::nothrow_t&) throw() { ; - ::delete [] static_cast <char *> (p); + ::operator delete (p); } template <typename PEER_STREAM, typename SYNCH_TRAITS> void ACE_Svc_Handler<PEER_STREAM, SYNCH_TRAITS>::destroy () @@ -78412,11 +78415,12 @@ if (this->mod_ == 0 && this->dynamic_ && this->closing_ == false) delete this; } -template <typename PEER_STREAM, typename SYNCH_TRAITS> void +template <typename PEER_STREAM, typename SYNCH_TRAITS> +inline __attribute__ ((always_inline)) void ACE_Svc_Handler<PEER_STREAM, SYNCH_TRAITS>::operator delete (void *obj) { ; - ::delete [] static_cast <char *> (obj); + ::operator delete (obj); } template <typename PEER_STREAM, typename SYNCH_TRAITS> ACE_Svc_Handler<PEER_STREAM, SYNCH_TRAITS>::ACE_Svc_Handler (ACE_Thread_Manager *tm, Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 [Bug 100406] bogus/missing -Wmismatched-new-delete
next prev parent reply other threads:[~2022-01-12 18:31 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-12 16:39 [Bug c++/103993] New: Incorrect error generated by mismatched-new-delete jjlindal at gmail dot com 2022-01-12 16:41 ` [Bug c++/103993] " jjlindal at gmail dot com 2022-01-12 18:31 ` msebor at gcc dot gnu.org [this message] 2022-04-25 21:13 ` [Bug middle-end/103993] -Wismatched-new-delete due to difference in inlining decisions andre at kostur dot net 2022-06-29 18:08 ` ed at catmur dot uk 2023-04-29 19:30 ` cdfrey at foursquare dot net
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-103993-4-BtB66ls2QF@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).