public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: "François Dumont" <frs.dumont@gmail.com>
Cc: Jonathan Wakely <jwakely.gcc@gmail.com>,
	"libstdc++" <libstdc++@gcc.gnu.org>,
	 gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] sso-string@gnu-versioned-namespace [PR83077]
Date: Thu, 17 Aug 2023 20:44:48 +0100	[thread overview]
Message-ID: <CACb0b4n2+LTe09_BVcZa3QEkMoun3LopV2CqEmq_HCpx+jDHkA@mail.gmail.com> (raw)
In-Reply-To: <CACb0b4nzNAPYtAfK-6ZBNZc=r1W105SiD2ATnLFCRwO2a_0WpQ@mail.gmail.com>

On Thu, 17 Aug 2023 at 20:37, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Thu, 17 Aug 2023 at 19:59, Jonathan Wakely <jwakely@redhat.com> wrote:
> >
> > On Thu, 17 Aug 2023 at 18:40, François Dumont <frs.dumont@gmail.com> wrote:
> > >
> > >
> > > On 17/08/2023 19:22, Jonathan Wakely wrote:
> > > > On Sun, 13 Aug 2023 at 14:27, François Dumont via Libstdc++
> > > > <libstdc++@gcc.gnu.org> 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 functions
> > > > 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 == 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=0 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/96088.
> > cc:44: void test01(): Assertion '__gnu_test::counter::count() == 3' failed.
> > 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 = "/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 = 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 <cstring>
>  #include <testsuite_hooks.h>
>
> +bool tests_started = false;
>  int times_to_fail = 0;
>
>  void* allocate(std::size_t n)
>  {
> -  if (!times_to_fail--)
> +  if (tests_started && !times_to_fail--)
>      return 0;
>
>    void* ret = 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 = true;
> +
>    for (int j = 0; j < iters; ++j)
>      {
>        for (int i = 0; i < 100; ++i)
>
>
> This way the replacement operator new doesn't start intentionally
> failing until we ask it to do so.

I'll replace the global std::string objects with std::string_view
objects, so that they don't allocate even if the library only uses COW
strings.

We should still fix those tests though.


  reply	other threads:[~2023-08-17 19:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-10  5:13 François Dumont
2023-08-11  5:43 ` François Dumont
2023-08-11  7:51   ` Jonathan Wakely
2023-08-13 13:27     ` François Dumont
2023-08-13 19:51       ` François Dumont
2023-08-17 17:17         ` François Dumont
2023-08-24 17:33           ` François Dumont
2023-08-17 17:22       ` Jonathan Wakely
2023-08-17 17:40         ` François Dumont
2023-08-17 18:59           ` Jonathan Wakely
2023-08-17 19:37             ` Jonathan Wakely
2023-08-17 19:44               ` Jonathan Wakely [this message]
2023-08-17 23:31                 ` Jonathan Wakely
2023-08-19 19:44                 ` François Dumont
2023-10-07 12:25         ` François Dumont
2023-10-07 19:32           ` François Dumont
2023-10-09 14:42             ` Iain Sandoe
2023-10-09 16:27               ` Iain Sandoe
2023-10-09 17:38               ` François Dumont
2023-10-24  4:55             ` François Dumont
2024-02-28 18:37         ` François Dumont

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACb0b4n2+LTe09_BVcZa3QEkMoun3LopV2CqEmq_HCpx+jDHkA@mail.gmail.com \
    --to=jwakely@redhat.com \
    --cc=frs.dumont@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).