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

  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: 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).