From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id D2A68385800E for ; Wed, 2 Mar 2022 16:31:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D2A68385800E Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-621-KCAyWHE3NFuyPCgHWy06eQ-1; Wed, 02 Mar 2022 11:30:59 -0500 X-MC-Unique: KCAyWHE3NFuyPCgHWy06eQ-1 Received: by mail-wr1-f70.google.com with SMTP id e6-20020a5d4e86000000b001f045d4a962so640688wru.21 for ; Wed, 02 Mar 2022 08:30:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=X9J/+L1oSymJUaSf3G03xk6ZZaOl0JLo1ixajEc0+pw=; b=v65Z453PTxyhG9EZ/tNZOkSiE59zWVoSgtcTH+R5AnhyVzjZcKF0yf4aD77aY4Y7Rc GDrVW55HqnBx3lmzPkmHf76OHWSpkMS7/OqqN1BmSnZu2H+5n2o3Wb3SXZTi8AzxZau8 kqdEUmXvW2JJ0dhbAGsBVH+psaURuhVe7bLAyN2yswUfaBRJo82TdVDKFDrHUYwXeSym ckOjsldsse/NQQ9BN6/tD1Uz6z9IWxHNp4CuGN2duAw7HdJOpEZt/v174ZJ3AdLOQLYv 1H2IK61B59Xy0ptmQDrnf1FJ62xmzfZz8U8nHhT+apKhd9RGlG1TLIOJgu1pH4G/qc6h ZqMA== X-Gm-Message-State: AOAM5333CB9p0rcQSOQinWuNwQceLjK3k2zspWt5NfgDPP17Oq0HMvoD dTRt1B01XUEPdqQQY5AGFMp0xA2JNtamuoeJ347oqmj7dJo1n5NET0cZEDbXYWBWegVj3vivGwV mvWSag7T+l4IfpVwSD2+BFA== X-Received: by 2002:a05:6000:1242:b0:1ef:846b:290a with SMTP id j2-20020a056000124200b001ef846b290amr15998643wrx.235.1646238658226; Wed, 02 Mar 2022 08:30:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJx6nn6QZ50354Q8h37F1e4iSwzLmJLqhf/M1MTXpmsLKJ/z1ioI60DK7EU4A7AuFk8WdwSktg== X-Received: by 2002:a05:6000:1242:b0:1ef:846b:290a with SMTP id j2-20020a056000124200b001ef846b290amr15998633wrx.235.1646238657940; Wed, 02 Mar 2022 08:30:57 -0800 (PST) Received: from localhost (host86-169-131-29.range86-169.btcentralplus.com. [86.169.131.29]) by smtp.gmail.com with ESMTPSA id u4-20020adfdb84000000b001e8d8ac5394sm18256389wri.110.2022.03.02.08.30.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 08:30:57 -0800 (PST) Date: Wed, 2 Mar 2022 16:30:56 +0000 From: Andrew Burgess To: =?utf-8?B?5ZGo5pil5piOKOaXpeaciCk=?= Cc: Gdb-patches , Simon Marchi , gdb-patches , Louis-He <1726110778@qq.com>, Dominique Quatravaux , Sam Warner Subject: Re: =?utf-8?B?Li4vLi4vZ2Ric3VwcG9ydC9uZXct?= =?utf-8?B?b3AuY2M6MTM3OjE6IGVycm9yOiDigJh2b2lkIG9wZXJhdG9yIGRlbGV0ZSBb?= =?utf-8?B?XSh2b2lkKiwgc3RkOjpzaXplX3Qp4oCZIGlzIGEgdXN1YWwgKG5vbi1wbGFj?= =?utf-8?Q?ement=29_deallocation_function_i?= =?utf-8?Q?n?= C++14 (or with -fsized-deallocation) [-Werror=c++14-compat] Message-ID: <20220302163056.GC1212730@redhat.com> References: <65ee9ce9-34db-4434-9cc6-34378f96bee9.riyue.zcm@alibaba-inc.com> MIME-Version: 1.0 In-Reply-To: <65ee9ce9-34db-4434-9cc6-34378f96bee9.riyue.zcm@alibaba-inc.com> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 15:47:41 up 3 days, 5:25, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2022 16:31:05 -0000 * =E5=91=A8=E6=98=A5=E6=98=8E(=E6=97=A5=E6=9C=88) via Gdb-patches [2022-03-01 15:48:47 +0800]: >=20 > Hi GDB maintainers, >=20 > I tried to build new GDB12, but encounter below error, anyone could tell = me how to fix it? Thanks! >=20 > CXX new-op.o > ../../gdbsupport/new-op.cc:32:13: error: =E2=80=98void operator delete(vo= id*, std::size_t)=E2=80=99 is a usual (non-placement) deallocation function= in C++14 (or with -fsized-deallocation) [-Werror=3Dc++14-compat] > extern void operator delete (void *p, std::size_t) noexcept; > ^ > ../../gdbsupport/new-op.cc:33:13: error: =E2=80=98void operator delete []= (void*, std::size_t)=E2=80=99 is a usual (non-placement) deallocation funct= ion in C++14 (or with -fsized-deallocation) [-Werror=3Dc++14-compat] > extern void operator delete[] (void *p, std::size_t) noexcept; > ^ > ../../gdbsupport/new-op.cc:119:1: error: =E2=80=98void operator delete(vo= id*, std::size_t)=E2=80=99 is a usual (non-placement) deallocation function= in C++14 (or with -fsized-deallocation) [-Werror=3Dc++14-compat] > operator delete (void *p, std::size_t) noexcept > ^ > ../../gdbsupport/new-op.cc:137:1: error: =E2=80=98void operator delete []= (void*, std::size_t)=E2=80=99 is a usual (non-placement) deallocation funct= ion in C++14 (or with -fsized-deallocation) [-Werror=3Dc++14-compat] > operator delete[] (void *p, std::size_t) noexcept I was able to reproduce this on Ubuntu 16.04.1 with their gcc 5.4.0. I was unable to easily rebuild GCC 5.4.0 on my current development machine to check if this is reproducible with upstream gcc, or is just something impacting Ubuntu. However, you can configure like: ../src/configure ...configure-flags-here... CXXFLAGS=3D"-Wno-error=3Dc++1= 4-compat" to disable this warning/error which I believe should be fine. For why this error is occurring, I'm honestly not 100% sure what the error is telling us. I _think_ what it's saying is that the delete operator that we're declaring/defining conflicts with a "usual deallocation function", which is added in c++14 and means something specific. I guess the idea is that maybe we're just randomly defining this version of delete for some reason, and then, if/when we move on to c++14 this function will get called unexpectedly by the language runtime in some situations. As time moved on I think this warning was relaxed, possibly with this commit: https://gcc.gnu.org/legacy-ml/gcc-patches/2015-05/msg01883.html All this makes me wonder if the usual deallocation functions are ever actually used, and indeed, I applied the patch below, and GDB still seems to build fine, so this might be an alternative approach. Maybe we should commit this to master? Thanks, Andrew --- diff --git a/gdbsupport/new-op.cc b/gdbsupport/new-op.cc index 1d066ba..4faa557 100644 --- a/gdbsupport/new-op.cc +++ b/gdbsupport/new-op.cc @@ -27,11 +27,6 @@ #include "host-defs.h" #include =20 -/* These are declared in starting C++14. Add these here to enable - compilation using C++11. */ -extern void operator delete (void *p, std::size_t) noexcept; -extern void operator delete[] (void *p, std::size_t) noexcept; - /* Override operator new / operator new[], in order to internal_error on allocation failure and thus query the user for abort/core dump/continue, just like xmalloc does. We don't do this from a @@ -116,12 +111,6 @@ operator delete (void *p, const std::nothrow_t&) noexc= ept } =20 void -operator delete (void *p, std::size_t) noexcept -{ - return ::operator delete (p, std::nothrow); -} - -void operator delete[] (void *p) noexcept { return ::operator delete (p); @@ -133,10 +122,4 @@ operator delete[] (void *p, const std::nothrow_t&) noe= xcept return ::operator delete (p, std::nothrow); } =20 -void -operator delete[] (void *p, std::size_t) noexcept -{ - return ::operator delete[] (p, std::nothrow); -} - #endif