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 374143858D35 for ; Thu, 17 Aug 2023 19:37:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 374143858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692301078; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/r4q7kdX8NIBzLo/h9cHEwF+8sFXl0c0zcGPPdWtIvc=; b=as7yt3VkOt1Rp08dqyDojcEr8ZZWJrXUDIAbUubZKPZ3fy6qAAAZ3Eblp/W6RKVju2Y+Zc muALJ5O24f2sV+IWGUE4y8O+dKjvjbJib2uxBhy2nt3dqG2HlBvBFy2p+fEFNOGfXO9Qb8 y5t0Ltaq9Px06/HSWoaHg/MIXNryDhQ= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-413-5W_ozbqHMdKmDESi45RZIQ-1; Thu, 17 Aug 2023 15:37:57 -0400 X-MC-Unique: 5W_ozbqHMdKmDESi45RZIQ-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2bbad70ff67so1927341fa.2 for ; Thu, 17 Aug 2023 12:37:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692301076; x=1692905876; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/r4q7kdX8NIBzLo/h9cHEwF+8sFXl0c0zcGPPdWtIvc=; b=enaqWv5OrczMuUS+8ILNGpojbh9bVkzeB6FDvsgPwNtJPebzLy5PRJIWd9+ThRTeTl SAiTrzeclNrCyiVa6Ymz3z1eD+VlAU3WwjsYBx8/URqD6vi8sQpG0Hz0gSKo4nhaHYEt /FOmTy2KhlpJN9ysi97+qcByjNHR3y4WQma1q8EfU0kcJ9sjVpDBlNe/FPpZOIZ1J9KY upZ9DOqHA/y81GYFLdxG64B8lDZk4QFr1UUbcZeFVuQFZ+YUDh/sjbbq3KBpFZfo1jHW hM8gnXDw49AAXRt5mjo1j5GPaUvPLxb6NP6GoieoM9QEg2omGvNGujyJz/49Ht+t3tcX IIZQ== X-Gm-Message-State: AOJu0YyEinVx6wcS8sROurjDg6v3MMVafu9SpEWZhCg6yQYLjoiAfBgA td3c4pQfewyeHIIPrvY2EmVl7kpCVb9b3UCfY3PyK643eqPg3Z0gNmmSR0jdB0VGNgif6hl8F50 7Lg3ex3rXDTyjUQz43/AEivsy454vuPw= X-Received: by 2002:a2e:3a09:0:b0:2b4:6eb0:2a27 with SMTP id h9-20020a2e3a09000000b002b46eb02a27mr227258lja.17.1692301075967; Thu, 17 Aug 2023 12:37:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF7u5C/eKYAtTNXznM1to4Q9116qyjnnx6ELJly4qkZBefCfuAZPSp56ofSC8LM5/7R6fKEVXuFiPRD1yFtgKw= X-Received: by 2002:a2e:3a09:0:b0:2b4:6eb0:2a27 with SMTP id h9-20020a2e3a09000000b002b46eb02a27mr227250lja.17.1692301075590; Thu, 17 Aug 2023 12:37:55 -0700 (PDT) MIME-Version: 1.0 References: <1dc681f4-41b7-d171-02ac-b0194617bdee@gmail.com> <91dc6383-6bff-ce6c-b24d-81cd2ab2dce8@gmail.com> <698fb340-2457-585f-f375-709491faf43e@gmail.com> In-Reply-To: From: Jonathan Wakely Date: Thu, 17 Aug 2023 20:37:44 +0100 Message-ID: Subject: Re: [PATCH] sso-string@gnu-versioned-namespace [PR83077] To: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= Cc: Jonathan Wakely , "libstdc++" , 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.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 17 Aug 2023 at 19:59, Jonathan Wakely wrote: > > On Thu, 17 Aug 2023 at 18:40, Fran=C3=A7ois Dumont = wrote: > > > > > > On 17/08/2023 19:22, Jonathan Wakely wrote: > > > On Sun, 13 Aug 2023 at 14:27, Fran=C3=A7ois Dumont via Libstdc++ > > > wrote: > > >> Here is the fixed patch tested in all 3 modes: > > >> > > >> - _GLIBCXX_USE_DUAL_ABI > > >> > > >> - !_GLIBCXX_USE_DUAL_ABI && !_GLIBCXX_USE_CXX11_ABI > > >> > > >> - !_GLIBCXX_USE_DUAL_ABI && _GLIBCXX_USE_CXX11_ABI > > >> > > >> I don't know what you have in mind for the change below but I wanted= to > > >> let you know that I tried to put COW std::basic_string into a nested > > >> __cow namespace when _GLIBCXX_USE_CXX11_ABI. But it had more impact = on > > >> string-inst.cc so I preferred the macro substitution approach. > > > I was thinking of implementing the necessary special members function= s > > > of __cow_string directly, so they are ABI compatible with the COW > > > std::basic_string but don't actually reuse the code. That would mean > > > we don't need to compile and instantiate the whole COW string just to > > > use a few members from it. But that can be done later, the macro > > > approach seems OK for now. > > > > You'll see that when cow_string.h is included while > > _GLIBCXX_USE_CXX11_ABI =3D=3D 1 then I am hiding a big part of the > > basic_string definition. Initially it was to avoid to have to include > > basic_string.tcc but it is also a lot of useless code indeed. > > > > > > > > > >> There are some test failing when !_GLIBCXX_USE_CXX11_ABI that are > > >> unrelated with my changes. I'll propose fixes in coming days. > > > Which tests? I run the entire testsuite with > > > -D_GLIBCXX_USE_CXX11_ABI=3D0 several times per day and I'm not seeing > > > failures. > > > > > > I'll review the patch ASAP, thanks for working on it. > > > > > So far the only issue I found are in the mode !_GLIBCXX_USE_DUAL_ABI && > > !_GLIBCXX_USE_CXX11_ABI. They are: > > > > 23_containers/unordered_map/96088.cc > > 23_containers/unordered_multimap/96088.cc > > 23_containers/unordered_multiset/96088.cc > > 23_containers/unordered_set/96088.cc > > ext/debug_allocator/check_new.cc > > ext/malloc_allocator/check_new.cc > > ext/malloc_allocator/deallocate_local.cc > > ext/new_allocator/deallocate_local.cc > > ext/pool_allocator/allocate_chunk.cc > > ext/throw_allocator/deallocate_local.cc > > Ah yes, they fail for !USE_DUAL_ABI builds, I wonder why. > > /home/test/src/gcc/libstdc++-v3/testsuite/23_containers/unordered_map/960= 88. > cc:44: void test01(): Assertion '__gnu_test::counter::count() =3D=3D 3' f= ailed. > FAIL: 23_containers/unordered_map/96088.cc execution test It's due to this global object in src/c++20/tzdb.cc: 1081 const string tzdata_file =3D "/tzdata.zi"; When the library uses COW strings that requires an allocation before main, which uses the replacement operator new in the tests, which fails to allocate. For example, in 22_locale/locale/cons/12352.cc we have this function used by operator new: int times_to_fail =3D 0; void* allocate(std::size_t n) { if (!times_to_fail--) return 0; The counter is initially zero, so if we try to allocate before it gets set to a non-zero value in test01() then we fail. The test should not assume no allocations before main() begins. The simplest way to do that is with another global that says "we have started testing" e.g. --- a/libstdc++-v3/testsuite/22_locale/locale/cons/12352.cc +++ b/libstdc++-v3/testsuite/22_locale/locale/cons/12352.cc @@ -26,11 +26,12 @@ #include #include +bool tests_started =3D false; int times_to_fail =3D 0; void* allocate(std::size_t n) { - if (!times_to_fail--) + if (tests_started && !times_to_fail--) return 0; void* ret =3D std::malloc(n ? n : 1); @@ -106,6 +107,8 @@ void operator delete[](void* p, const std::nothrow_t&) throw() // libstdc++/12352 void test01(int iters) { + tests_started =3D true; + for (int j =3D 0; j < iters; ++j) { for (int i =3D 0; i < 100; ++i) This way the replacement operator new doesn't start intentionally failing until we ask it to do so.