From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id A07B53857007; Mon, 9 Aug 2021 12:08:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A07B53857007 Received: by mail-wm1-x32a.google.com with SMTP id h24-20020a1ccc180000b029022e0571d1a0so11379946wmb.5; Mon, 09 Aug 2021 05:08:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=bJMvcZ4msOfE5GU+a3IyUBxg6OIDOzpkOXAyG8MlYps=; b=Rhz6FoyNKtR+xQxZ4YCbKlaRg54GHZWu4/vfMnBd8Ec30uDbAPWhasAMt60hzH9lIi 0NDuDhlpxIY7VgGlgUL32tybeWHfhnZT4mOqZikY551BhpvGDd1Cuxi7X1yPm7SyanZH Zx6U3xaLTkydhvKyQHR0NjuhGy7tFCN+0s6nDo+5XRJ/z4pr5SODgwFpALr2i4ZQ1w0P EB2uG9sjn74SSrmk2gSoBNBnpCMu2Jf3HNUzdbMm8V1hCeSFb9yKhdzK+RlDY9cf8TG0 SiyDa4vXuzObOLnIMGMz9QVW1rv+M8ebjSfmFDHBwkI5LpMANTOx9eeQLIf5WOJAHXwx l6Ag== X-Gm-Message-State: AOAM533S6dEmT3tKMA8FiL+UfjpT2QZdHq18NUdx8KewH+6yE0bpcGPd TJLO2KMCMcosxypy3dJwaho/Oit8JBw= X-Google-Smtp-Source: ABdhPJxyGNU60uJEIwtDDNDeSFGqh2JcTcUaLpI8l+gvZJ7f2CB/YNmNETFVMBWZRNeYeeXtKxZieQ== X-Received: by 2002:a7b:c106:: with SMTP id w6mr3323009wmi.152.1628510893277; Mon, 09 Aug 2021 05:08:13 -0700 (PDT) Received: from [192.168.42.32] (pop.92-184-100-250.mobile.abo.orange.fr. [92.184.100.250]) by smtp.googlemail.com with ESMTPSA id k1sm19886602wrz.61.2021.08.09.05.08.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Aug 2021 05:08:12 -0700 (PDT) Subject: Re: [PATCH] Avoid allocator operator== in _Safe_container From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= To: Jonathan Wakely Cc: "libstdc++@gcc.gnu.org" , gcc-patches References: <6edc763b-e463-a676-0232-7b2193fb403b@gmail.com> Message-ID: <7097b577-337f-b488-5f48-5fe97f4a9718@gmail.com> Date: Mon, 9 Aug 2021 14:08:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------F686977FAC11A508C1AE7363" Content-Language: fr X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 12:08:16 -0000 This is a multi-part message in MIME format. --------------F686977FAC11A508C1AE7363 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 09/08/21 1:52 pm, François Dumont wrote: > On 09/08/21 12:45 pm, Jonathan Wakely wrote: >> On Mon, 9 Aug 2021 at 11:34, Jonathan Wakely wrote: >>> On Mon, 9 Aug 2021 at 11:33, Jonathan Wakely wrote: >>>> On Mon, 9 Aug 2021 at 11:26, François Dumont via Libstdc++ >>>> wrote: >>>>> Some newly introduced tests in >>>>> 23_containers/unordered_map/cons/default.cc revealed that we are >>>>> forcing >>>>> the allocator type to have a operator==. >>>> All allocators are required to have operator== so that should not be a >>>> problem. What is the error? >>> OK, I see it. I just forgot to define operator== and operator!= for >>> the custom allocator in that new test, and that should be added. >> Fixed like this instead. Tested x86_64-linux with -D_GLIBCXX_DEBUG. >> Pushed to trunk. > > Ok, I thought my change was better because we have many allocator > types in tests without operator ==/!= (see > 23_containers/*/cons/noexcept_default_construct.cc). But of course the > tests are not making any use of it for the moment, no big deal. > > So this patch is just an optimization, may I still commit it ? Unless > you like the fact that Debug mode is checking that those operators are > provided when allocator-aware move constructor is being used. > > A simpler version, using _Safe_container move constructor when allocator instances are always equals. --------------F686977FAC11A508C1AE7363 Content-Type: text/x-patch; charset=UTF-8; name="safe_container.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="safe_container.patch" diff --git a/libstdc++-v3/include/debug/safe_container.h b/libstdc++-v3/include/debug/safe_container.h index d9636c29e9b..97c47167fe8 100644 --- a/libstdc++-v3/include/debug/safe_container.h +++ b/libstdc++-v3/include/debug/safe_container.h @@ -57,7 +57,12 @@ namespace __gnu_debug _Safe_container(const _Safe_container&) = default; _Safe_container(_Safe_container&&) = default; - _Safe_container(_Safe_container&& __x, const _Alloc& __a) + private: + _Safe_container(_Safe_container&& __x, const _Alloc&, std::true_type) + : _Safe_container(std::move(__x)) + { } + + _Safe_container(_Safe_container&& __x, const _Alloc& __a, std::false_type) : _Safe_container() { if (__x._M_cont().get_allocator() == __a) @@ -65,6 +70,12 @@ namespace __gnu_debug else __x._M_invalidate_all(); } + + protected: + _Safe_container(_Safe_container&& __x, const _Alloc& __a) + : _Safe_container(std::move(__x), __a, + typename std::allocator_traits<_Alloc>::is_always_equal{}) + { } #endif public: --------------F686977FAC11A508C1AE7363--