From patchwork Wed Aug 18 15:34:28 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 1518081 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4GqX6G2Cgtz9sVw for ; Thu, 19 Aug 2021 01:35:33 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 27212388E818 for ; Wed, 18 Aug 2021 15:35:30 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id B099C3985471; Wed, 18 Aug 2021 15:34:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B099C3985471 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: YUg0wmSVEt6SsvTh97B6UpagQB5MQnzffOlnd/viHui/gquRhhO0xpyjwQ916/OXX/+WuNmu9r zWEBkQathss499W2Nia9IK6xuN/x8bK33T2I8WdGEWfTMn3t4hdh224WGGactAo2LiKZRdW3ly kuH467wa3AOMXWaoUBeSwZ7xV7c0CKottXbpoN5UeecRqp9vdq1wsZ+rSL1w4glqqPyAjplNu+ JKHE+pmqifF+HptuRuEfOs1PzqgMnXLPkHWYYSnels0V0+y5ita+DerLfDZLwBRvn5tVSIrM0x PmFbsZpzBUslo4+ioj/0oDjH X-IronPort-AV: E=Sophos;i="5.84,330,1620720000"; d="scan'208,223";a="64847594" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 18 Aug 2021 07:34:47 -0800 IronPort-SDR: lweaWoIyq5s85LQoR1nHi8RHGwvv13E4cnBoMAqNSOhB3KpIZyF8LQtG3EaFmepToZRRZ+JdBm tc8qoncn5TAuMS7dl8aFD2/wLtJElZ1MoC9P8dztavEvEN7sDYLNVApgxBoUADHBc9Ip7bYOzO NSMiFiKjjNAR/x3eN9w94g4uswpISiy3owz8N2txnWq1lI13cf3GFWKXGK2wxbrKMt4QKHhBKb cpL3y4o7Hun206kjW/hvISJD08wZVRXaRfesoTQEFo1YrdxUPdP9lF5tzOHmHPy8KA3zvLUhqF OfM= From: Thomas Schwinge To: David Edelsohn , Richard Biener , Subject: Make 'gcc/hash-map-tests.c:test_map_of_type_with_ctor_and_dtor_expand' work on 32-bit architectures [PR101959] In-Reply-To: References: <87r1f6qzmx.fsf@euler.schwinge.homeip.net> <87czqd7e4k.fsf@euler.schwinge.homeip.net> <55126f14-dda1-2040-0976-70b89582a60c@gmail.com> <874kbopoah.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Wed, 18 Aug 2021 17:34:28 +0200 Message-ID: <87r1eqojgb.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, 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: 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: , Cc: gcc@gcc.gnu.org, Jonathan Wakely Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" Hi! On 2021-08-18T09:35:25-0400, David Edelsohn wrote: > This causes a bootstrap failure for me. > > PR/101959 Sorry for that; "details". ;-| OK to push the attached "Make 'gcc/hash-map-tests.c:test_map_of_type_with_ctor_and_dtor_expand' work on 32-bit architectures [PR101959]", which does resolve the issue for a '-m32' i686-pc-linux-gnu build? Grüße Thomas > On Tue, Aug 17, 2021 at 5:00 AM Richard Biener via Gcc wrote: >> >> On Tue, Aug 17, 2021 at 8:40 AM Thomas Schwinge wrote: >> > >> > Hi! >> > >> > On 2021-08-16T14:10:00-0600, Martin Sebor wrote: >> > > On 8/16/21 6:44 AM, Thomas Schwinge wrote: >> > >> [...], to document the current behavior, I propose to >> > >> "Add more self-tests for 'hash_map' with Value type with non-trivial >> > >> constructor/destructor", see attached. OK to push to master branch? >> > >> (Also cherry-pick into release branches, eventually?) >> > >> > (Attached again, for easy reference.) >> > >> > > Adding more tests sounds like an excellent idea. I'm not sure about >> > > the idea of adding loopy selftests that iterate as many times as in >> > > the patch (looks like 1234 times two?) >> > >> > Correct, and I agree it's a sensible concern, generally. >> > >> > The current 1234 times two iterations is really arbitrary (should >> > document that in the test case), just so that we trigger a few hash table >> > expansions. >> >> You could lower N_init (the default init is just 13!), >> even with just 128 inserted elements you'll trigger >> expansions to 31, 61 and 127 elements. >> >> > For 'selftest-c', we've got originally: >> > >> > -fself-test: 74775 pass(es) in 0.309299 seconds >> > -fself-test: 74775 pass(es) in 0.366041 seconds >> > -fself-test: 74775 pass(es) in 0.356663 seconds >> > -fself-test: 74775 pass(es) in 0.355009 seconds >> > -fself-test: 74775 pass(es) in 0.367575 seconds >> > -fself-test: 74775 pass(es) in 0.320406 seconds >> > >> > ..., and with my changes we've got: >> > >> > -fself-test: 94519 pass(es) in 0.327755 seconds >> > -fself-test: 94519 pass(es) in 0.369522 seconds >> > -fself-test: 94519 pass(es) in 0.355531 seconds >> > -fself-test: 94519 pass(es) in 0.362179 seconds >> > -fself-test: 94519 pass(es) in 0.363176 seconds >> > -fself-test: 94519 pass(es) in 0.318930 seconds >> > >> > So it really seems to be all in the noise? >> >> Yes. I think the test is OK but it's also reasonable to lower >> the '1234' times and add a comment as to the count should >> trigger hashtable expansions "a few times". >> >> Richard. >> >> > Yet: >> > >> > > Selftests run each time GCC >> > > builds (i.e., even during day to day development). It seems to me >> > > that it might be better to run such selftests only as part of >> > > the bootstrap process. >> > >> > I'd rather have thought about a '--param self-test-expensive' (or >> > similar), and then invoke the selftests via a new >> > 'gcc/testsuite/selftests/expensive.exp' (or similar). >> > >> > Or, adapt 'gcc/testsuite/gcc.dg/plugin/expensive_selftests_plugin.c', >> > that is, invoke them via the GCC plugin mechanism, which also seems to be >> > easy enough? >> > >> > I don't have a strong opinion about where/when these tests get run, so >> > will happily take any suggestions. >> > >> > >> > Grüße >> > Thomas >> > >> > >> > ----------------- >> > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 From a6075945f392a93fa03eaf163cbe34fc5cfe8fe1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 18 Aug 2021 17:20:40 +0200 Subject: [PATCH] Make 'gcc/hash-map-tests.c:test_map_of_type_with_ctor_and_dtor_expand' work on 32-bit architectures [PR101959] Bug fix for recent commit e4f16e9f357a38ec702fb69a0ffab9d292a6af9b "Add more self-tests for 'hash_map' with Value type with non-trivial constructor/destructor". gcc/ PR bootstrap/101959 * hash-map-tests.c (test_map_of_type_with_ctor_and_dtor_expand): Use an 'int_hash'. --- gcc/hash-map-tests.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/gcc/hash-map-tests.c b/gcc/hash-map-tests.c index 257f2be0c26..6acc0d4337e 100644 --- a/gcc/hash-map-tests.c +++ b/gcc/hash-map-tests.c @@ -328,11 +328,22 @@ test_map_of_type_with_ctor_and_dtor_expand (bool remove_some_inline) size_t expand_c_expected = 4; size_t expand_c = 0; - void *a[N_elem]; + /* For stability of this testing, we need all Key values 'k' to produce + unique hash values 'Traits::hash (k)', as otherwise the dynamic + insert/remove behavior may diverge across different architectures. This + is, for example, a problem when using the standard 'pointer_hash::hash', + which is simply doing a 'k >> 3' operation, which is fine on 64-bit + architectures, but on 32-bit architectures produces the same hash value + for subsequent 'a[i] = &a[i]' array elements. Therefore, use an + 'int_hash'. */ + + int a[N_elem]; for (size_t i = 0; i < N_elem; ++i) - a[i] = &a[i]; + a[i] = i; - typedef hash_map Map; + const int EMPTY = -1; + const int DELETED = -2; + typedef hash_map, val_t> Map; /* Note that we are starting with a fresh 'Map'. Even if an existing one has been cleared out completely, there remain 'deleted' elements, and these -- 2.30.2