From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by sourceware.org (Postfix) with ESMTPS id 387DE385DC04 for ; Fri, 10 Apr 2020 09:11:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 387DE385DC04 Received: by mail-wr1-x442.google.com with SMTP id v5so1567673wrp.12 for ; Fri, 10 Apr 2020 02:11:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CXPtQNnlxGN4JDpHJA1NFnoAKIPQU+WX2V0RRBARGvU=; b=VLpVT1tHPYTGsXG/3ZAQK+aeRzx/JJs3tvA+B4RhLMP9JtTkFGpVgJQHWLBZb1eJfL aWeKRndLXzN1qQMa0Q24zlJ/WR+Ai4DhJDKbEA58Cti4a60nzaEM+hej4hcsRIdras4e IHP0oghSdelNpNXVYhilUPl6Myt1wzVroxK/w6B8iwymeZlO/BU7FBz9qqZA0wucwbO/ Q0Gc8940T5GM+Xq/UFIHLJf3aOsA8wcPfIvPUWw821gese/or4slA1m5HfKOqsRsO/3K uD1Y/Tg6ZQbRHtEB1tSNDumGjK5rULuy25SO8iNSJ8D2kuoHEXmiTFTRzzzYOC8lsgoa Zdqw== X-Gm-Message-State: AGi0PuYBydwd/VzXhTgoHN7hrLyhXQ41TtiZ9IYd3W+NWH8luVLvdujP QcQ5xt7MBqL5xF3gzZrzVz4= X-Google-Smtp-Source: APiQypKGXJnVR5gvtJSVdXG5HXPGXR1E08kA9Vn4NiuNjA5njhdnMeaH1BVKHMD2ZzVt5L5BJGB2+g== X-Received: by 2002:a5d:4041:: with SMTP id w1mr3459726wrp.137.1586509901167; Fri, 10 Apr 2020 02:11:41 -0700 (PDT) Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id x8sm2255514wrn.27.2020.04.10.02.11.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2020 02:11:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] Allow new/delete operator deletion only for replaceable. From: Iain Sandoe In-Reply-To: Date: Fri, 10 Apr 2020 10:11:39 +0100 Cc: Jakub Jelinek , Jonathan Wakely , Nathan Sidwell , GCC Patches , Jan Hubicka , Marc Glisse Content-Transfer-Encoding: 8bit Message-Id: References: <20200403152609.GA35629@kam.mff.cuni.cz> <20200408133252.GG2212@tucnak> <20d175a6-23df-43e5-7027-d11fc660abd1@suse.cz> <8cac5c65-3b93-1c9a-87e9-9e42eb876eba@suse.cz> To: =?utf-8?Q?Martin_Li=C5=A1ka?= X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 09:11:43 -0000 Marc Glisse wrote: > 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? This is USER_LABEL_PREFIX. Several targets, including Darwin, do use it. Other than pre-pending the U_L_P, name mangling on Darwin (and I’d imagine any other Itanium ABI platform) is as per ABI. >> 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