public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Marc Glisse <marc.glisse@inria.fr>
To: "Martin Liška" <mliska@suse.cz>
Cc: Jonathan Wakely <jwakely.gcc@gmail.com>,
	 Richard Biener <richard.guenther@gmail.com>,
	 Jason Merrill <jason@redhat.com>,
	Jakub Jelinek <jakub@redhat.com>,  Jan Hubicka <hubicka@ucw.cz>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	 Nathan Sidwell <nathan@acm.org>
Subject: Re: [PATCH] Allow new/delete operator deletion only for replaceable.
Date: Fri, 10 Apr 2020 10:37:09 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2004101036270.5445@stedding.saclay.inria.fr> (raw)
In-Reply-To: <8cac5c65-3b93-1c9a-87e9-9e42eb876eba@suse.cz>

On Fri, 10 Apr 2020, Martin Liška wrote:

> On 4/9/20 10:13 AM, Jonathan Wakely wrote:
>> On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote:
>>> Note that the matching is not 1-to-1. Array vs non-array and
>>> aligned vs non-aligned seem important, but sized and unsized delete can
>>> both match the same new, IIUC.
>> 
>> Right.
>> 
>>> Not sure about the nothrow versions...
>> 
>> This is valid, and mixes the nothrow new with non-nothrow delete:
>> 
>> delete new (std::nothrow) int;
>> 
>
> All right, there's a patch candidate that comes up with the list of possible 
> pairs.
> For better readability, I present demangled names:
>
> $ cat /tmp/pairs.txt | c++filt
> 	  "operator new(unsigned long):operator delete(void*)" ,
> 	  "operator new(unsigned long):operator delete(void*, unsigned long)" 
> ,
> 	  "operator new(unsigned long):operator delete(void*, std::nothrow_t 
> const&)" ,
> 	  "operator new(unsigned long, std::nothrow_t const&):operator 
> delete(void*)" ,
> 	  "operator new(unsigned long, std::nothrow_t const&):operator 
> delete(void*, unsigned long)" ,
> 	  "operator new(unsigned long, std::nothrow_t const&):operator 
> delete(void*, std::nothrow_t const&)" ,
> 	  /* non-[] operators with alignment.  */
> 	  "operator new(unsigned long, std::align_val_t):operator 
> delete(void*, unsigned long, std::align_val_t)" ,
> 	  "operator new(unsigned long, std::align_val_t):operator 
> delete(void*, std::align_val_t)" ,
> 	  "operator new(unsigned long, std::align_val_t):operator 
> delete(void*, std::align_val_t, std::nothrow_t const&)" ,
> 	  "operator new(unsigned long, std::align_val_t, std::nothrow_t 
> const&):operator delete(void*, unsigned long, std::align_val_t)" ,
> 	  "operator new(unsigned long, std::align_val_t, std::nothrow_t 
> const&):operator delete(void*, std::align_val_t)" ,
> 	  "operator new(unsigned long, std::align_val_t, std::nothrow_t 
> const&):operator delete(void*, std::align_val_t, std::nothrow_t const&)" ,
> 	  /* [] operators.  */
> 	   "operator new[](unsigned long):operator delete[](void*)" ,
> 	   "operator new[](unsigned long):operator delete[](void*, unsigned 
> long)" ,
> 	   "operator new[](unsigned long):operator delete[](void*, 
> std::nothrow_t const&)" ,
> 	   "operator new[](unsigned long, std::nothrow_t const&):operator 
> delete[](void*)" ,
> 	   "operator new[](unsigned long, std::nothrow_t const&):operator 
> delete[](void*, unsigned long)" ,
> 	   "operator new[](unsigned long, std::nothrow_t const&):operator 
> delete[](void*, std::nothrow_t const&)" ,
> 	  /* [] operators with alignment.  */
> 	   "operator new[](unsigned long, std::align_val_t):operator 
> delete[](void*, unsigned long, std::align_val_t)" ,
> 	   "operator new[](unsigned long, std::align_val_t):operator 
> delete[](void*, std::align_val_t)" ,
> 	   "operator new[](unsigned long, std::align_val_t):operator 
> delete[](void*, std::align_val_t, std::nothrow_t const&)" ,
> 	   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
> const&):operator delete[](void*, unsigned long, std::align_val_t)",
> 	   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
> const&):operator delete[](void*, std::align_val_t)",
> 	   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
> const&):operator delete[](void*, std::align_val_t, std::nothrow_t const&)",
>
> Marc pointed out that some targets do not use the leading '_' (or use 2 
> dashes?) for mangled named?
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

How do you handle platforms where size_t is not unsigned long?

-- 
Marc Glisse

  parent reply	other threads:[~2020-04-10  8:37 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30  8:40 [PATCH] Check DECL_CONTEXT of new/delete operators Martin Liška
2020-03-30  8:53 ` Richard Biener
2020-03-31 12:29   ` Jan Hubicka
2020-03-31 12:38     ` Martin Liška
2020-04-03 15:26       ` Jan Hubicka
2020-04-03 15:42         ` Jan Hubicka
2020-04-04 11:53           ` Jan Hubicka
2020-04-06  9:27             ` Richard Biener
2020-04-06 15:10               ` Jason Merrill
2020-04-06  8:34         ` Martin Liška
2020-04-06 12:45           ` Nathan Sidwell
2020-04-07  8:26             ` Jonathan Wakely
2020-04-07  9:29               ` Richard Biener
2020-04-07  9:49                 ` Jan Hubicka
2020-04-07 10:22                   ` Richard Biener
2020-04-07 10:42                     ` Martin Liška
2020-04-07 11:41                 ` Jonathan Wakely
2020-04-07 10:46             ` Martin Liška
2020-04-07 11:29             ` Jonathan Wakely
2020-04-07 11:40               ` Richard Biener
2020-04-07 11:46                 ` Jonathan Wakely
2020-04-07 11:57                   ` Richard Biener
2020-04-07 15:00                     ` [PATCH] Allow new/delete operator deletion only for replaceable Martin Liška
2020-04-08  8:47                       ` Richard Biener
2020-04-08 13:20                         ` Jason Merrill
2020-04-08 13:32                           ` Jakub Jelinek
2020-04-08 13:34                             ` Jason Merrill
2020-04-08 15:16                               ` Martin Liška
2020-04-08 15:46                                 ` Jan Hubicka
2020-04-08 16:06                                   ` Jakub Jelinek
2020-04-09  5:05                                 ` Martin Liška
2020-04-09  6:45                                   ` Richard Biener
2020-04-09  6:59                                     ` Martin Liška
2020-04-09  7:21                                       ` Richard Biener
2020-04-09  7:55                                       ` Jakub Jelinek
2020-04-09  8:04                                     ` Marc Glisse
2020-04-09  8:13                                       ` Jonathan Wakely
2020-04-10  8:08                                         ` Martin Liška
2020-04-10  8:18                                           ` Jonathan Wakely
2020-04-10  8:29                                             ` Martin Liška
2020-04-10  9:17                                               ` Jakub Jelinek
2020-04-14  7:09                                                 ` Martin Liška
2020-04-14  7:11                                                   ` Martin Liška
2020-04-14  8:37                                                     ` Jakub Jelinek
2020-04-14 10:54                                                       ` Martin Liška
2020-04-17  7:05                                                         ` Jakub Jelinek
2020-04-17  8:12                                                           ` Jonathan Wakely
2020-04-10  8:37                                           ` Marc Glisse [this message]
2020-04-10  9:11                                             ` Iain Sandoe
2020-04-09 16:55                                   ` Jason Merrill
2020-04-07 15:16                     ` [PATCH] Check DECL_CONTEXT of new/delete operators Jonathan Wakely
2020-04-08  7:34                       ` Richard Biener
2020-04-08  8:11                         ` Jonathan Wakely
2020-04-07 14:11               ` Nathan Sidwell
2020-03-30  9:29 ` Marc Glisse

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=alpine.DEB.2.22.394.2004101036270.5445@stedding.saclay.inria.fr \
    --to=marc.glisse@inria.fr \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=jakub@redhat.com \
    --cc=jason@redhat.com \
    --cc=jwakely.gcc@gmail.com \
    --cc=mliska@suse.cz \
    --cc=nathan@acm.org \
    --cc=richard.guenther@gmail.com \
    /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).