From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id AE97B385803F; Wed, 10 Nov 2021 07:26:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AE97B385803F Received: by mail-wr1-x432.google.com with SMTP id r8so2247458wra.7; Tue, 09 Nov 2021 23:26:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mvrOwB8t6flZ5O3IlORmFLR+3h1JH+S8yU8Lhu9jMw0=; b=cta8VciPjAsXEZL2QRBchPC/+1qX2UvN7ArBv7nh82BRqaLFxKhCwT295YpuZbQpC+ 9co72LYoJSRL+e4WTbvaxKuKkRogiIDQP/iFujhO1WetMePtfTbNW9j9vMnNDUrTX6FM Ozfd90wq8ymG+PmfrXyTw/eDDDY6r8L+R5H4QCKOLr3Gl3FvlgcPRrrUa+obMmaXEvvC I3eOfkZkQn6Xgnu7M4XMhMjjtGrbA/qXgjhneP5X9foOQyW3rskMQtX6VPTrE3OpHNcN sCSd0xyDB1VNglk8qnecfrlPBuKlrjz1Bi98CMxztZJ7qUB5nEIZybo4/zzRoCh+vJrW JR8w== X-Gm-Message-State: AOAM5312Hij8nmG4+xtrZhNCd5bII1ES0KUO4BnsqZLF5nsi1587rXrI gCIWIz57JuJ77MLTv6wX4LrJOn49Wsq6CZJmiTU= X-Google-Smtp-Source: ABdhPJzue3xDj8URE2dwpEH5pEeZ80twdRh2zhCyfLQPjJPQuwNjtWE6FBvIi0M/RjBdSzCDTwTvwIvIZk1HjakWq78= X-Received: by 2002:a5d:6ac7:: with SMTP id u7mr16855085wrw.57.1636529171510; Tue, 09 Nov 2021 23:26:11 -0800 (PST) MIME-Version: 1.0 References: <4eec3fb9-851e-3e4e-f9f4-1110db3af747@gmail.com> <6c349652-8b6f-2027-08c3-6ce58a765aeb@gmail.com> <22bf1b42-8cf4-7a6e-d5dc-c322ccbb2b46@gmail.com> <68641ea0-2a14-e3a5-8315-a7b3a9c1fdb4@gmail.com> <7043bd08-3035-dc76-bed2-c7911d6dab59@gmail.com> In-Reply-To: <7043bd08-3035-dc76-bed2-c7911d6dab59@gmail.com> From: Jonathan Wakely Date: Wed, 10 Nov 2021 07:26:00 +0000 Message-ID: Subject: Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge To: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= Cc: "H.J. Lu" , Jonathan Wakely , "libstdc++" , gcc-patches X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, KAM_SHORT, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Wed, 10 Nov 2021 07:26:15 -0000 On Wed, 10 Nov 2021, 05:45 Fran=C3=A7ois Dumont, wro= te: > I can't see any clue on how my commit can have had an impact on below cod= e. > Agreed. > I don't think libstdc++ hash table has any relation with gcc hash table. > Correct, it's totally unrelated. And "section type conflict" can't be caused by the library anyway. > Still, I'm rebuilding gcc at my revision to confirm. > > On 10/11/21 1:05 am, H.J. Lu wrote: > > On Mon, Nov 8, 2021 at 1:37 PM Fran=C3=A7ois Dumont via Gcc-patches > > wrote: > >> Yet another version this time with only 1 guard implementation. The > >> predicate to invalidate the safe iterators has been externalized. > >> > >> Ok to commit ? > >> > > This may have broken GCC bootstrap on Linux/x86-64: > > > > https://gcc.gnu.org/pipermail/gcc-regression/2021-November/075734.html > > > > In file included from ../../src-master/gcc/sanopt.c:22: > > In member function =E2=80=98hash_table > Allocator>::value_type* hash_table > Allocator>::alloc_entries(size_t) const [with Descriptor =3D > > hash_map >::hash_entry; bool Lazy =3D > > false; Allocator =3D xcallocator]=E2=80=99, > > inlined from =E2=80=98void hash_table > Allocator>::expand() [with Descriptor =3D hash_map > auto_vec >::hash_entry; bool Lazy =3D false; Allocator =3D > > xcallocator]=E2=80=99 at ../../src-master/gcc/hash-table.h:802:40: > > ../../src-master/gcc/system.h:784:34: error: section type conflict > > with =E2=80=98void hash_table::expand() [w= ith > > Descriptor =3D hash_map >::hash_entry; > > bool Lazy =3D false; Allocator =3D xcallocator]=E2=80=99 > > 784 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, > > __FUNCTION__), 0 : 0)) > > | > ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ../../src-master/gcc/hash-table.h:715:3: note: in expansion of macro > > =E2=80=98gcc_assert=E2=80=99 > > 715 | gcc_assert (nentries !=3D NULL); > > | ^~~~~~~~~~ > > In file included from ../../src-master/gcc/coretypes.h:482, > > from ../../src-master/gcc/sanopt.c:23: > > ../../src-master/gcc/hash-table.h: In member function =E2=80=98void > > hash_table::expand() [with Descriptor =3D > > hash_map >::hash_entry; bool Lazy =3D > > false; Allocator =3D xcallocator]=E2=80=99: > > ../../src-master/gcc/hash-table.h:779:1: note: =E2=80=98void > > hash_table::expand() [with Descriptor =3D > > hash_map >::hash_entry; bool Lazy =3D > > false; Allocator =3D xcallocator]=E2=80=99 was declared here > > 779 | hash_table::expand () > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >