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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 252083858426 for ; Mon, 9 Aug 2021 14:24:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 252083858426 Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-317-8etcSwsLNuiX44McqW8BBQ-1; Mon, 09 Aug 2021 10:24:52 -0400 X-MC-Unique: 8etcSwsLNuiX44McqW8BBQ-1 Received: by mail-wm1-f72.google.com with SMTP id r125-20020a1c2b830000b0290197a4be97b7so42950wmr.9 for ; Mon, 09 Aug 2021 07:24:52 -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:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=p5gLMv4qUnXs9Q/qPZGusP40XtUVD+qdTc/I5zHGgHI=; b=CAQYdo8RAe3F6sww23frlObwDIBUJBMSW+zZXYbVCr7H+5INnlM4JxMtAvLS4hTLji GX8iK+KrtIXksZ5NPR4aQZG4sPGrKcghT24aBu8Jpkge6YNlSkSEA0L1OsJ/6/kxZd5V WaOSesr+DgszlqEsVozctGETW/+mYDOkt/0NxZS2H8xNJLXdscdX3VuM+PxHodejZpNp 62xL1g+vBbu/d2BQ1B2A9y7Ap7hOYEbNLRQOCBjlWGYbd/SjZPATM8DrcU+N/w50xDe1 1bDcC+2LGLYd0tBEygi5GWGdP72Ga6VVv80hZIhefMovP6whi/fw+psytYbWRtCk6L2e JYIw== X-Gm-Message-State: AOAM533sww54GNwIlkeVDaRYaomqWaE0kSVV42aMhmfbznPP/xV1Gtoz u1UsUYDQ9QTLJeXx69MWiIIVYXA8jkOdEV9kPQdVMO9MiwOGrSoqEGyJjyyDRqswQkqUHzRYIVk /YLJIMsPumK6yzryehyw/w86o9PgKI+CReQ== X-Received: by 2002:adf:ea41:: with SMTP id j1mr25410379wrn.147.1628519091416; Mon, 09 Aug 2021 07:24:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2VLYzpmbiM4Gu8gCksOSf5PiP0U6ewr4izRPs6hZNkAFoDSTAFb78o6GB+CphjgvUeuB2V3v56A3SowR2Gfs= X-Received: by 2002:adf:ea41:: with SMTP id j1mr25410355wrn.147.1628519091122; Mon, 09 Aug 2021 07:24:51 -0700 (PDT) MIME-Version: 1.0 References: <6edc763b-e463-a676-0232-7b2193fb403b@gmail.com> <7097b577-337f-b488-5f48-5fe97f4a9718@gmail.com> In-Reply-To: <7097b577-337f-b488-5f48-5fe97f4a9718@gmail.com> From: Jonathan Wakely Date: Mon, 9 Aug 2021 15:24:40 +0100 Message-ID: Subject: Re: [PATCH] Avoid allocator operator== in _Safe_container To: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= Cc: "libstdc++@gcc.gnu.org" , gcc-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 09 Aug 2021 14:24:57 -0000 On Mon, 9 Aug 2021 at 13:08, Fran=C3=A7ois Dumont wr= ote: > > On 09/08/21 1:52 pm, Fran=C3=A7ois 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=C3=A7ois 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=3D=3D. > >>>> All allocators are required to have operator=3D=3D so that should no= t be a > >>>> problem. What is the error? > >>> OK, I see it. I just forgot to define operator=3D=3D and operator!=3D= 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 =3D=3D/!=3D (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. Those tests are all OK, the allocators inherit from std::allocator so can use its equality operators. But if I did mess up any more test allocators then we should fix those ones= too. > > 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. Yes, this optimization is good. OK for trunk, thanks!